We've been using a shipping API via our Unix server, specifically SCO Openserver 5.0.7, for a little over a year.
Our system generates XML files, sends them to the server using the lwp-request command, receives the response, interprets it, and processes it as needed by our system.
The exact command we use is:
lwp-request -m POST https://url.com < REQUESTFILE.XML > RESPONSEFILE.XML
The shipping company is upgrading all servers to require TLS 1.2, and now I get
500 SSL negotiation failed:
as a response when using this command.
I'm not sure how to go about making our system compatible.
Do I need to update Perl? (Current version is v5.8.8 built for i586-pc-sco3.2v5.0). If so, what is the minimum version to use TLS 1.2?
Do I need to update LWP? I believe my LWP version is 5.805 (got this using perl -MLWP -le "print(LWP->VERSION)")
Do I need to go into the lwp-request script and manually modify it?
Or is there perhaps another command that does an equivalent job using TLS 1.2?
Given your very old version of Perl (5.8.8, where 5.8.9 was release 2008) and LWP (5.805, 5.806 was released 2007) on a very old OS (SCO OpenServer 5.0.7, last update around 2009) it is likely that you are also running a very old version of OpenSSL. TLS 1.2 was only specified in 2008 and got available in OpenSSL only with 1.0.1 which was released 03/2012, i.e. several years after any software updates to your system.
You can check it it with openssl version and my guess is that it says something about version 0.9.8, i.e. way too old.
To make TLS 1.2 work on this old system you would need to compile a newer version of OpenSSL (at least the latest 1.0.1) and rebuild the Perl modules interfacing with OpenSSL so that they use this new version. Depending on your setup this might be Crypt::SSLeay or Net::SSLeay. And given how old your system is it is not unlikely that you run in various problems with compiling simply because most don't expect that somebody tries to compile newer software on outdated systems. Thus it might just be easier to upgrade everything to a recent and supported OS instead of trying to fight with an old system.
Related
In Live server we have perl version 5.6.1,recently we have enabled TLS 1.2 which resulted in a error "500 SSL Negotiation failed". Earlier we have TLS 1.0 we don't have any issues. Enabling TLS 1.2 is unavoidable which is mandatory. How to resolve this issue?
I have searched & found that SOAP-LITE module has to be installed in order to resolve the above issue but the version 5.6.1 does not support SOAP-LITE module. It is available in active perl 5.8 and above version. Is it adviseable to upgrade to 5.8 version inorder to install soap::Lite?
I have used the modules MSSQL::DBLIB and MSSQL::SQLLIB in this project, Will upgrade supports this module?
Given how old your version of Perl is it is very likely that your version of OpenSSL (which is used at the end for SSL connectivity in Perl) is as old too. Support for TLS 1.2 was added with OpenSSL 1.0.1 which was released 2012. Perl 5.6.1 was released in 2000 while in 2012 we already had Perl 5.14.
And it is not unlikely that the rest of your software is similar outdated and unsupported and likely insecure too.
How to resolve this issue?
Finally upgrade your long unsupported software stack. You can try to only update openssl and rebuild Crypt::SSLeay (likely no Net::SSLeay is used yet) to keep changes minimal but I'm not sure that this will work or even compile.
I am a perl developer and have been working on a ServiceNow API to create change tickets. It has been working well until this past Friday when ServiceNow depreciated support for TLS 1.0 and 1.1. My version of Perl is 5.8 so it's quite old. Are there any quick Perl 5.8 fixes?
Here are the perl modules I'm using.
use MIME::Base64;
use HTTP::Proxy;
use JSON;
use REST::Client;
the new errors;
Response: 500 SSL negotiation failed:
Response status: 500 Header: Content-Type=text/plain Header: Client-Date=Fri, 10 Jan 2020 23:06:10 GMT Header: Client-Warning=Internal response 500 SSL negotiation failed:
If you have any say in this you should really, really, really, really, really update your Perl. I mean, really. 5.8 is ancient.
If you cannot do that, you must at least update the piece of code that handles the TLS to a version >= 1.2 (Good luck!). Rest::Client uses LWP::UserAgent which in turn uses either Net::SSL or IO::Socket::SSL (I think) for the SSL stuff. If both are present Net::SSL will be used.
So you must investigate which one(s) you have and update one of them. Net::SSL is probably your best bet, since it is just a wrapper around the c library openssl (apt!). The other one probably has a rats tail of dependencies, but I didn't look.
Perl 5.8.0 is from July 2002. Perl 5.8.8 (which is what I suspect you are actually using) is from January 2006. Both of these are ancient versions and I highly recommend not using them.
I realise that you're using a specific version of an operating system (I'd guess RHEL5) and that upgrading your OS is a project that your company aren't going to want to undertake. But this is why we don't use the system installed version of Perl.
You have a few options.
Install another version of Perl alongside the system Perl. Put it in /opt/perl or somewhere like that. Make it a recent version and install a completely new library of modules for it. perlbrew is one nice way to achieve this.
Use a virtual machine or, better, a Docker container to host your API. That can be a newer OS, running a newer version of Perl with a newer version of the system libraries (which you're probably going to need - as your older version of openssl probably doesn't support TLS 1.2).
Stop using legacy hardware to host your project and move it into a cloud provider like AWS.
You either need to be more agile about updating your OS (which very few companies are very good at) or you need to separate your application's runtime environment from the underlying OS. That second route is what switched-on projects have been doing for several years now.
I am running a web server based on CentOS 5.8 and I need to upgrade my version of bind to make it PCI compliant. I'm currently running bind 9.3.6 and I need to have bind 9.9.8 or higher. I've tried yum update bind but apparently I already have the latest version according to yum. I did some Googling and I found an RPM file bind-9.10.2-1.el5.i686.rpm which looks like it would work but i don't know if it should try installing it or not. I think I would need bind-devel and bind-libs which I can get from the same site. Am I better off compiling from source? I know CentOS 5 is old but I'm trying to avoid reinstalling the whole server.
Installing binary rpm's from later versions of CentOS is unlikely to work: there are many changes since CentOS5.
Rebuilding a src.rpm locally is one way to see what issues there are.
Meanwhile, upgrading to CentOS6 (at least: CentOS7 uses systemd which takes some study) is often not a whole lot more effort than retrofitting something like bind, and will have other efficiencies. YMMV, everyone's does.
I am working on developing an software.
I have installed the v1.0 on my machine running solaris 10,
and I want to upgrade to version 1.1 tha has some new function.
I do not want to uninstall version 1.0 but upgrade to version 1.1.
How do I make a patch?
Writing a script or using some patch tools?
If you are asking about Solaris patches, i.e. those appling to SVR4 packages, I guess only Solaris engineering is able to build and deliver them as there is no standard/documented format I'm aware of. The new version of Solaris (11) is going to abandon this patching method anyway to the new pkg mechanism.
If you want a new version not to replace the older one, I guess the simplest way would be to have them to install in different directories. eg: /opt/zhangli/v1.0 and /opt/zhangli/v1.1. Any packaging format would support that.
I'm currently accessing an Oracle database version 9i (9.2.0.8.0) using perl modules DBI (1.613) and DBD::Oracle (1.26). The current scope of the project now requires that I access a version 8i (8.1.7.4.0 ) Oracle database and, according to the DBD::Oracle project, I can only access this second database with a DBD::Oracle version 1.20 or below.
I know I could possibly use the DBD version 1.20 to access both databases, but I was wondering if its possible to have installed the two versions of the DBD module and use the acceptable version for each database (less prone to errors).
I don't believe that the server version has any bearing on the DBD::Oracle version you can use, only the version of the client libraries that you install. The 9.2, 10.1, and 10.2 versions of the Oracle client libraries support connecting to Oracle server 8.1.7.4, and the latest version of DBD::Oracle remains compatible with all client libraries from 9.2 up, so I don't think that you will actually have any problem at all. However, if you install the version 11 client, you will lose the ability to connect to server versions below 9.2.0.
Install the different versions of DBI/DBD::Oracle into two different places, see INSTALL_BASE/--install_base. Access them seperately by setting PERL5LIB appropriately.
local::lib helps you automate this whole affair.
If you want to access the two database versions from the same program run you can do as follows:
install both versions in your system using local::lib
run a DBD::Proxy server with #LIB configured to load one version of DBD::Oracle
run your script with #LIB configured to load the other version of DBD::Oracle
in your script connect to one database using DBD::Oracle as usual and to the other one through the proxy.