I don’t use Fedora and track its versions, but assuming those are recent
RedHat including Fedora recently enabled ECC in its openssl packages after years of excluding it over concerns about Certicom’s patent. That increases the number of cipher suites in the Client Hello message and also adds two extensions (although fairly small for RH) which makes the Hello message bigger, and some servers are known to hang or otherwise fail when the Hello message is bigger than used to be “normal” a decade ago. Apparently api.tab.com.au:443 is such; tested with s_client > 255 hangs. (In a 404 it claims to be “WebLogic Server”, which I don’t know about.) I also observe this server does not implement 5746 (secure renegotiation) and will negotiate only TLSv1(.0) and 4 akRSA suites (RC4, 3DES, both AES) suggesting it is rather old. If you can’t get the server operator(s) to fix their server, you need to get openssl as used by perl to send a shorter ClientHello. The most straightforward way is to reduce the set of suites offered, especially since the server implements only 4. According to perldoc for the best perl I have (5.6.1 ActivePerl for Windows) but not tested, LWP::UserAgent can take a hash ssl_opts which apparently are passed (eventually) to openssl. Just making SSL_cipher_list DEFAULT:!ECDH should reduce the cipher list enough, although you might want even more restrictive settings for other reasons, like in general you should always prohibit “export” and “LOW” ciphers which have been broken for years. Alternatively it looks like you can set SSL_version to exclude TLSv12 or just force TLSv1; that excludes a bunch of ciphers and also the sigalgs extension, which should make Hello short enough. From: owner-openssl-us...@openssl.org [mailto:owner-openssl-us...@openssl.org] On Behalf Of Peter Abbott Sent: Thursday, December 19, 2013 17:29 To: openssl-users@openssl.org Subject: *** Spam *** Upgrade Breakage of Perl Script Hi, I have a simple perl script which supplies a username and account password to a server. The server in turn returns a password token for further operations. The script does not specifically use openssl but the perl modules LWP::UserAgent and or HTTP::Request must do. The script worked perfectly up to openssl version 1.0.1e-4.fc19.x86_64. Further upgrades to 1.0.1e-28.fc19 and 1.0.1e30.fc19 just hang somewhere at the handshake stage. I am only a novice and have a limited understanding of what is going on. Part of the script is as follows: #!/usr/bin/perl -w use strict; use LWP::UserAgent; use HTTP::Request; my $message = '<?xml version="1.0" encoding="utf-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; xmlns:ser="http://service.thirdparty.api.neo.tabcorp.com.au/";> <soapenv:Header/> <soapenv:Body> <ser:authenticateAccount> <apiMeta> <deviceId>1000011</deviceId> <jurisdictionId>2</jurisdictionId> <requestChannel>1</requestChannel> <usernamePasswordToken></usernamePasswordToken> </apiMeta> <authRequest> <accountId>xxxxxx</accountId> <accountPassword>yyyyyyyy</accountPassword> </authRequest> </ser:authenticateAccount> </soapenv:Body> </soapenv:Envelope>'; my $keyn; my $userAgent = LWP::UserAgent->new(); my $request = HTTP::Request->new(POST => 'https://api.tab.com.au/tabapi/services/thirdPartyAuthenticate'); $request->header(SOAPAction => '"http://service.thirdparty.api.neo.tabcorp.com.au/";'); $request->content($message); $request->content_type("text/xml; charset=utf-8"); my $response = $userAgent->request($request); if($response->code == 200) { print $response->as_string; } else { print "zs" } Can anyone shed some light on what is happening here or what I can do to remedy the problem? Thanks, Peter.
