Client Hello too large ?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Client Hello too large ?

Alban Diquet
Hi all,

I've encountered a strange issue. It might not be related to OpenSSL itself, but maybe it is.
  
When sending a Client Hello message that's larger than 270 bytes (not sure what the exact limit is, 255 maybe?), lots of servers on the internet don't send back any Server Hello, but keep the connection open, so my client ends up returning a timeout.
It's really weird, has anyone seen that behavior ?
You can get to a 275 byte client hello for example by using OpenSSL 1.0.0.d with a TLS1 hello, all the cipher suites explicitly enabled 'ALL:NULL:@STRENGTH', and a non empty session ID field.
Then feel free to test it on Facebook.
Does anyone know what's going on there ?

Thanks,


Alban Diquet
Reply | Threaded
Open this post in threaded view
|

Re: Client Hello too large ?

Michael S. Zick-4
On Mon June 20 2011, Alban Diquet wrote:

> Hi all,
>
> I've encountered a strange issue. It might not be related to OpenSSL itself,
> but maybe it is.
>
> When sending a Client Hello message that's larger than 270 bytes (not sure
> what the exact limit is, 255 maybe?), lots of servers on the internet don't
> send back any Server Hello, but keep the connection open, so my client ends
> up returning a timeout.
> It's really weird, has anyone seen that behavior ?
> You can get to a 275 byte client hello for example by using OpenSSL 1.0.0.d
> with a TLS1 hello, all the cipher suites explicitly enabled
> 'ALL:NULL:@STRENGTH', and a non empty session ID field.
>

Is that session ID still valid on the server when this happens?
Is it a session ID that the server issued to your client?

Mike
> Then feel free to test it on Facebook.
> Does anyone know what's going on there ?
>
> Thanks,
>
>
> Alban Diquet
>


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Client Hello too large ?

Victor Duchovni
On Tue, Jun 21, 2011 at 05:43:57AM -0500, Michael S. Zick wrote:

> > I've encountered a strange issue. It might not be related to OpenSSL itself,
> > but maybe it is.
> >
> > When sending a Client Hello message that's larger than 270 bytes (not sure
> > what the exact limit is, 255 maybe?), lots of servers on the internet don't
> > send back any Server Hello, but keep the connection open, so my client ends
> > up returning a timeout.
> > It's really weird, has anyone seen that behavior ?
> > You can get to a 275 byte client hello for example by using OpenSSL 1.0.0.d
> > with a TLS1 hello, all the cipher suites explicitly enabled
> > 'ALL:NULL:@STRENGTH', and a non empty session ID field.
> >
>
> Is that session ID still valid on the server when this happens?
> Is it a session ID that the server issued to your client?

I can reproduce this problem, perhaps it is an issue with the load
balancers that terminate TLS at many large-scale HTTPS-enabled sites.

For facebook, try:

    $ openssl s_client -msg -cipher 'ALL:NULL:@STRENGTH' -tls1 -reconnect -connect 69.171.224.40:443

The above hangs on the reconnect client hello, while:

    $ openssl s_client -msg -cipher 'RC4-MD5:NULL:@STRENGTH' -tls1 -reconnect -connect 69.171.224.40:443

yields:

Reused, TLSv1/SSLv3, Cipher is RC4-MD5
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : RC4-MD5
    Session-ID: 197E266EAC6CDD1CA9BAFD0AFB6EDB9CB63407EC1046131A59F33766BF3BB5E9
    Session-ID-ctx:
    Master-Key: ...
    Key-Arg   : None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1308667111
    Timeout   : 7200 (sec)
    Verify return code: 20 (unable to get local issuer certificate)

So session re-use works, but not when the hello is:

>>> TLS 1.0 Handshake [length 0118], ClientHello
    01 00 01 14 03 01 4e 00 ad 60 11 e7 93 d1 b3 46
    8f be 77 1d 68 c5 dd c0 d2 94 60 f5 32 b3 e5 ee
    68 a6 e4 c5 0a da 20 19 7e 26 6e ac 6c a4 43 a9
    ba fd 0a fb 6e dd 9d da dd af f4 4c d9 d5 56 59
    f3 37 66 bf 3b b4 70 00 86 c0 14 c0 0a 00 39 00
    38 00 88 00 87 c0 19 00 3a 00 89 c0 0f c0 05 00
    35 00 84 c0 12 c0 08 00 16 00 13 c0 17 00 1b c0
    0d c0 03 00 0a c0 13 c0 09 00 33 00 32 00 9a 00
    99 00 45 00 44 c0 18 00 34 00 9b 00 46 c0 0e c0
    04 00 2f 00 96 00 41 00 07 c0 11 c0 07 c0 16 00
    18 c0 0c c0 02 00 05 00 04 00 15 00 12 00 1a 00
    09 00 14 00 11 00 19 00 08 00 06 00 17 00 03 c0
    10 c0 06 c0 15 c0 0b c0 01 00 02 00 01 00 ff 02
    01 00 00 44 00 0b 00 04 03 00 01 02 00 0a 00 34
    00 32 00 01 00 02 00 03 00 04 00 05 00 06 00 07
    00 08 00 09 00 0a 00 0b 00 0c 00 0d 00 0e 00 0f
    00 10 00 11 00 12 00 13 00 14 00 15 00 16 00 17
    00 18 00 19 00 23 00 00

as with 'ALL:NULL:@STRENGTH'.

--
        Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: Client Hello too large ?

Alban Diquet
Yes, strange isn't it ?
I guess it doesn't matter for 99% of the SSL clients, but for what I'm doing (a SSL scanner) it's kind of annoying.
Well it's probably not going to change anytime soon, but now I want to know what's going on.

Alban


2011/6/21 Victor Duchovni <[hidden email]>
On Tue, Jun 21, 2011 at 05:43:57AM -0500, Michael S. Zick wrote:

> > I've encountered a strange issue. It might not be related to OpenSSL itself,
> > but maybe it is.
> >
> > When sending a Client Hello message that's larger than 270 bytes (not sure
> > what the exact limit is, 255 maybe?), lots of servers on the internet don't
> > send back any Server Hello, but keep the connection open, so my client ends
> > up returning a timeout.
> > It's really weird, has anyone seen that behavior ?
> > You can get to a 275 byte client hello for example by using OpenSSL 1.0.0.d
> > with a TLS1 hello, all the cipher suites explicitly enabled
> > 'ALL:NULL:@STRENGTH', and a non empty session ID field.
> >
>
> Is that session ID still valid on the server when this happens?
> Is it a session ID that the server issued to your client?

I can reproduce this problem, perhaps it is an issue with the load
balancers that terminate TLS at many large-scale HTTPS-enabled sites.

For facebook, try:

   $ openssl s_client -msg -cipher 'ALL:NULL:@STRENGTH' -tls1 -reconnect -connect 69.171.224.40:443

The above hangs on the reconnect client hello, while:

   $ openssl s_client -msg -cipher 'RC4-MD5:NULL:@STRENGTH' -tls1 -reconnect -connect 69.171.224.40:443

yields:

Reused, TLSv1/SSLv3, Cipher is RC4-MD5
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
   Protocol  : TLSv1
   Cipher    : RC4-MD5
   Session-ID: 197E266EAC6CDD1CA9BAFD0AFB6EDB9CB63407EC1046131A59F33766BF3BB5E9
   Session-ID-ctx:
   Master-Key: ...
   Key-Arg   : None
   PSK identity: None
   PSK identity hint: None
   Start Time: 1308667111
   Timeout   : 7200 (sec)
   Verify return code: 20 (unable to get local issuer certificate)

So session re-use works, but not when the hello is:

>>> TLS 1.0 Handshake [length 0118], ClientHello
   01 00 01 14 03 01 4e 00 ad 60 11 e7 93 d1 b3 46
   8f be 77 1d 68 c5 dd c0 d2 94 60 f5 32 b3 e5 ee
   68 a6 e4 c5 0a da 20 19 7e 26 6e ac 6c a4 43 a9
   ba fd 0a fb 6e dd 9d da dd af f4 4c d9 d5 56 59
   f3 37 66 bf 3b b4 70 00 86 c0 14 c0 0a 00 39 00
   38 00 88 00 87 c0 19 00 3a 00 89 c0 0f c0 05 00
   35 00 84 c0 12 c0 08 00 16 00 13 c0 17 00 1b c0
   0d c0 03 00 0a c0 13 c0 09 00 33 00 32 00 9a 00
   99 00 45 00 44 c0 18 00 34 00 9b 00 46 c0 0e c0
   04 00 2f 00 96 00 41 00 07 c0 11 c0 07 c0 16 00
   18 c0 0c c0 02 00 05 00 04 00 15 00 12 00 1a 00
   09 00 14 00 11 00 19 00 08 00 06 00 17 00 03 c0
   10 c0 06 c0 15 c0 0b c0 01 00 02 00 01 00 ff 02
   01 00 00 44 00 0b 00 04 03 00 01 02 00 0a 00 34
   00 32 00 01 00 02 00 03 00 04 00 05 00 06 00 07
   00 08 00 09 00 0a 00 0b 00 0c 00 0d 00 0e 00 0f
   00 10 00 11 00 12 00 13 00 14 00 15 00 16 00 17
   00 18 00 19 00 23 00 00

as with 'ALL:NULL:@STRENGTH'.

--
       Viktor.
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Client Hello too large ?

Lutz Jänicke
Am 21.06.2011 20:38, schrieb Alban Diquet:
Yes, strange isn't it ?
I guess it doesn't matter for 99% of the SSL clients, but for what I'm doing (a SSL scanner) it's kind of annoying.
Well it's probably not going to change anytime soon, but now I want to know what's going on.

> > When sending a Client Hello message that's larger than 270 bytes (not sure
> > what the exact limit is, 255 maybe?), lots of servers on the internet don't
> > send back any Server Hello, but keep the connection open, so my client ends
> > up returning a timeout.
> > It's really weird, has anyone seen that behavior ?
> > You can get to a 275 byte client hello for example by using OpenSSL 1.0.0.d
> > with a TLS1 hello, all the cipher suites explicitly enabled
> > 'ALL:NULL:@STRENGTH', and a non empty session ID field.
> >
>
> Is that session ID still valid on the server when this happens?
> Is it a session ID that the server issued to your client?

I can reproduce this problem, perhaps it is an issue with the load
balancers that terminate TLS at many large-scale HTTPS-enabled sites.

For facebook, try:

   $ openssl s_client -msg -cipher 'ALL:NULL:@STRENGTH' -tls1 -reconnect -connect 69.171.224.40:443

The above hangs on the reconnect client hello, while:

   $ openssl s_client -msg -cipher 'RC4-MD5:NULL:@STRENGTH' -tls1 -reconnect -connect 69.171.224.40:443

yields:


It may actually be worth connecting the respective system administrator(s).

Finally you are not just wasting your system's rescources. You are also wasting theirs.
We don't know what kind of resources you are wasting. It will most likely only be a file descriptor
on the other side (hopefully for a service like facebook they have plenty of these :-).
If you are triggering more resource hungry effects (memory, CPU cycles) while you
see no response, you might have found a DoS on their side.

Best regards,
    Lutz