Re: [TLS] ALPN concerns

> 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 |

Hmm, if the message is 256-byte TLS 1.2 Handshake message,
the first five bytes will be 0x 22.03.03.01.00.
In SSLv2 context, it means a beginning of a handshake message
containing 0x2203 (8707) bytes with 0x03 (3) bytes of padding.

The V2-aware servers are just waiting for 8000+ more
bytes to arrive, describing why they seems to be silence...

2013/11/7 Xiaoyong Wu <X.Wu@f5.com>:
> 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
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

-- 
Yutaka OIWA, Ph.D.                 Leader, System Life-cycle Research Group
                               Research Institute for Secure Systems (RISEC)
     National Institute of Advanced Industrial Science and Technology (AIST)
                       Mail addresses: <y.oiwa@aist.go.jp>, <yutaka@oiwa.jp>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]