Re: [TLS] ALPN concerns

Mark Nottingham <mnot@mnot.net> Wed, 06 November 2013 21:23 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E81711E8143 for <tls@ietfa.amsl.com>; Wed, 6 Nov 2013 13:23:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.492
X-Spam-Level:
X-Spam-Status: No, score=-104.492 tagged_above=-999 required=5 tests=[AWL=-1.893, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2VJ1mH1mkOg7 for <tls@ietfa.amsl.com>; Wed, 6 Nov 2013 13:23:50 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 152EB11E8140 for <tls@ietf.org>; Wed, 6 Nov 2013 13:23:50 -0800 (PST)
Received: from dhcp-b71c.meeting.ietf.org (unknown [31.133.183.28]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 5B1E322E253; Wed, 6 Nov 2013 16:23:29 -0500 (EST)
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <E774C81546D66E429BF56B1474C7EBBA012CE328CB@SEAEMBX01.olympus.F5Net.com>
Date: Wed, 6 Nov 2013 13:23:27 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <A14A6849-71C9-42ED-98D2-E547DE264E7D@mnot.net>
References: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz> <E774C81546D66E429BF56B1474C7EBBA012CE328CB@SEAEMBX01.olympus.F5Net.com>
To: Xiaoyong Wu <X.Wu@F5.com>
X-Mailer: Apple Mail (2.1816)
Cc: "<tls@ietf.org>" <tls@ietf.org>, Peter Gutmann <p.gutmann@auckland.ac.nz>
Subject: Re: [TLS] ALPN concerns
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 06 Nov 2013 21:23:54 -0000

For whatever it’s worth — thank you (personally and F5) for being open about it. You may have just saved us a LOT of pain / gnashing of teeth.

Cheers,


On 6 Nov 2013, at 10:00 am, Xiaoyong Wu <X.Wu@F5.com> 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.
> 
> -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

--
Mark Nottingham   http://www.mnot.net/