I understand the main problem is the server not responding clients supporting TLS 1.2 that uses longer ClientHello. And unfortunately, we pull data by python not curl so we don't have the fancy to pass openssl parameters for connections and such. It uses the protocols whatever version of openssl it was compiled with.
I am definitely going to complain about this issue to the service provider but I don't have much hope for them to take this seriously. So I wonder if next versions of openssl should care about workarounds for these painful servers? cheers. Roy On Wed, Jul 24, 2013 at 11:02 PM, Dave Thompson <dthomp...@prinpay.com>wrote: > >From: owner-openssl-us...@openssl.org On Behalf Of Rajesh Malepati > >Sent: Wednesday, 24 July, 2013 13:03 > > >On Wed, Jul 24, 2013 at 9:30 PM, kirpit <kir...@gmail.com> wrote: > >>... requests to one of our API provider > >>... works fine with 0.9.8o but 1.0.1e. > > >The server doesn't seem to care to respond to clients supporting TLS 1.2 > >ok: openssl s_client -tls1 -connect emea.webservices.travelport.com:443 > >no reply: openssl s_client -tls1_2 -connect > emea.webservices.travelport.com:443 > > More exactly, it appears to be one of the several servers that > fail for the longer ClientHello used in TLS1.2 by default: > -ssl3 or -tls1 uses a shorter hello and works. > -no_tls1_2 ditto and works negotiating 1.0. > -tls1_1 ditto gets 1.0 response which s_client rejects. > -tls1_2 -cipher (shortlist) ditto ditto. > (default) -cipher (shortlist) ditto gets 1.0 response and works. > > >such servers should be beaten to pulp. > > Agreed, but in the meantime, according to curl.haxx.se, > curl has options to specify TLS1(.0?), SSL3, and/or cipherlist, > which should allow a workaround. -1 or -3 looks easier > than figuring out a good cipherlist for the (each?) host. > > > ______________________________________________________________________ > OpenSSL Project http://www.openssl.org > User Support Mailing List openssl-users@openssl.org > Automated List Manager majord...@openssl.org >
