Re: [TLS] ALPN concerns

It is a little bit more calculation than that and related to some historic reasons, aka SSLv2.

For SSL records, the SSLv3 and TLS ClientHello headers are as follows:

| 22 | version major | version minor | length high bits | length low bits |

If this is interpreted as an SSLv2 header, it will be considered as a 3 byte header:
| v2 header b0 | v2 header b1 | v2 header b2 | message type | 

The value for Client Hello message type is SSLV2_MT_CLIENTHELLO which is 1.
When there is an SSLv3/TLS client-hello of length 256 - 511 bytes, this is ambiguous as "message type" is 1 or it is the "length high bits" to be 1.

Out implementation before the patch was to prefer SSLv2 and thus the issue.

As I am explaining this in detail, I would say that another work around on this would be making a client hello that exceeds 512 in length.

-Xiaoyong

> -----Original Message-----
> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Peter
> Gutmann
> Sent: Tuesday, November 05, 2013 10:53 PM
> To: <tls@ietf.org>
> Subject: Re: [TLS] ALPN concerns
> 
> Brian Smith <brian@briansmith.org> writes:
> 
> >I am very concerned about the issues that they've run into where many
> >web servers are failing to handshake when the ClientHello message is
> >larger than
> >255 bytes.
> 
> I'm curious as to how something like this could come about, is anyone familiar
> with the code base for something that does this?  Is there actually code out
> there that explicitly checks:
> 
>   if( sizeof( client_handshake ) > 255 )
>     return( -1 );
> 
> and if so, why?
> 
> Peter.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls