Re: [TLS] ALPN concerns

[Xiaoyong Wu <[e-mail]>]

The work around I proposed should work in either cases. 

Some of our earlier releases do not support TLS 1.1 and 1.2. During the development of the patch, we mistakenly only fixed the issue explicitly for SSL 3.0/TLS 1.0 (aka, preferring these 2 versions instead of SSLv2 and not the others) on these releases. This is the reason why using SSL 3.0/TLS 1.0 helped some times.

-Xiaoyong

> -----Original Message-----
> From: Wan-Teh Chang [mailto:[e-mail]]
> Sent: Wednesday, November 06, 2013 11:27 PM
> To: Xiaoyong Wu
> Cc: Peter Gutmann; <[e-mail]>
> Subject: Re: [TLS] ALPN concerns
> 
> On Wed, Nov 6, 2013 at 10:00 AM, Xiaoyong Wu <[e-mail]> wrote:
> > 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.
> 
> Hi Xiaoyong,
> 
> Thank you very much for explaining the bug and suggesting a workaround.
> 
> Could you also explain a related bug in F5 BIG-IP? This bug is described in
> the OpenSSL ChangeLog as follows:
> 
>    *) Workarounds for some broken servers that "hang" if a client hello
>      record length exceeds 255 bytes.
> 
>      1. Do not use record version number > TLS 1.0 in initial client
>         hello: some (but not all) hanging servers will now work.
>      ...
>      [Steve Henson]
> 
> To work around this F5 BIG-IP bug, the third byte in a TLS ClientHello record
> (which is the protocol minor version) needs to be 0 or 1 and cannot be 2 or 3.
> Is this bug also caused by interpreting the record as an SSLv2 ClientHello? In
> SSLv2 if the first byte of a record is 22 (0x16), then the third byte is
> PADDING.
> 
> Thanks,
> Wan-Teh