>>> I've done some more tests and it seems that the size of the client hello >>> message is significant: all the options that work reduce the size of >>> client hello. If you use the -debug option and check out the first >>> message bytes 4 and 5 it seems those servers hang if the length exceeds >>> 0xFF (using two bytes instead of one). >>> >> If you use the option "-servername <very long string>" you can precisely >> control the size of the client hello. If you use that to make client >> hello long enough you get the hang with OpenSSL 1.0.0h and earlier as well. > > So I'm getting more and more reports of sites that have a problem > since 1.0.1. They basicly fall in 2 categories: > - They don't tolerate versions higher than TLS 1.0 > - They don't like big packets. > > Of the 2nd case I have at least found people complain about those > sites: > - www.facebook.com > - www.paypal.com > - sourceforge.net
It seems to be combination. For example www.paypal.com actually can negotiate TLS 1.2, but doesn't tolerate long TLS 1.2 ClientHello. Most notably 'openssl s_client -connect www.paypal.com:443 -cipher DEFAULT:\!AES' results in 0xF8 bytes TLS 1.2 ClientHello and it manages to connect and negotiate 1.2! But test with -cipher ALL. This for some reason results in SSL *2.0* ClientHello which is 0x1B5[!] bytes long, but it does announce TLS 1.2 capability and final negotiated version is ... TLS 1.2! Once again, SSL 2.0 [and TLS 1.0] ClientHello *may* be >= 256 bytes, but not TLS 1.[12] ClientHello. But it doesn't seem to mean that server doesn't support 1.2... ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
