Re: [TLS] ALPN concerns

Xiaoyong Wu <X.Wu@F5.com> Wed, 06 November 2013 18:00 UTC

Return-Path: <X.Wu@f5.com>
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 C7AE721F99F8 for <tls@ietfa.amsl.com>; Wed, 6 Nov 2013 10:00:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 tcRzw+oZQy4R for <tls@ietfa.amsl.com>; Wed, 6 Nov 2013 10:00:32 -0800 (PST)
Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 0976011E80F9 for <tls@ietf.org>; Wed, 6 Nov 2013 10:00:32 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.93,647,1378857600"; d="scan'208";a="86508893"
X-IPAS-Result: AqIEAHSDelLAqArr/2dsb2JhbABaDoMxU782gTt0giUBAQEBAwEBATc0FwQCAQgNAQMEAQEfCQcnCxQJCAEBBAESCIgGvwkTBI8oOAaDGoEQA55wjg0/gio
Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 06 Nov 2013 18:00:06 +0000
Received: from SEAEMBX01.olympus.F5Net.com ([fe80::3440:4256:38f6:d3a0]) by SEAECAS01.olympus.F5Net.com ([::1]) with mapi id 14.03.0158.001; Wed, 6 Nov 2013 10:00:05 -0800
From: Xiaoyong Wu <X.Wu@F5.com>
To: Peter Gutmann <p.gutmann@auckland.ac.nz>, "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] ALPN concerns
Thread-Index: Ac7avMo2dskaCaL/Q4ufEA6jUw/n4gAWXiRA
Date: Wed, 6 Nov 2013 18:00:05 +0000
Message-ID: <E774C81546D66E429BF56B1474C7EBBA012CE328CB@SEAEMBX01.olympus.F5Net.com>
References: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [192.168.16.250]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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 18:00:36 -0000

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