On Sat, Mar 31, 2012, Kurt Roeckx wrote: > On Sat, Mar 31, 2012 at 08:12:54PM +0200, Andy Polyakov wrote: > > >>> 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... > > Yes, paypal seems to support TLS 1.2 (but not 1.1), which is why > I've put them in the second category. > > So you're saying you send a different ClientHello depending on the > size? If it's > 0xFF you send an SSL 2.0 ClientHello, but > announce 1.2 while otherwise you send a TLS 1.2 ClientHello? > It doesn't make sense to me, and that doesn't seem to happen here. >
Before OpenSSL 1.0.0 OpenSSL always sent an SSLv2 compatible client hello indicating support for the highest TLS version (which was 1.0 for that version) provided SSLv2 support was enabled in the library. An SSLv2 compatible client hello cannot indicate compression or extensions so it is rather limiting. OpenSSL 1.0 and later will use an *SSLv3* compatible client hello provided no SSLv2 ciphersuites are requested. The default cipherstring now excludes all SSLv2 ciphersuites so by default you wont get SSLv2 client hellos. If however you specify ALL as the cipherstring you will get SSLv2 ciphersuites present. If the library has been compiled with no-ssl2 this wont happen and you'll only ever get the SSLv3 compatible client hello. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
