Re: [TLS] ALPN concerns

Xiaoyong Wu <X.Wu@F5.com> Thu, 07 November 2013 08:19 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 1A9AF21F9D98 for <tls@ietfa.amsl.com>; Thu, 7 Nov 2013 00:19:07 -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 jTspyD94l0kF for <tls@ietfa.amsl.com>; Thu, 7 Nov 2013 00:19:00 -0800 (PST)
Received: from mail.f5.com (mail.f5.com [208.85.209.139]) by ietfa.amsl.com (Postfix) with ESMTP id 1738821E80CD for <tls@ietf.org>; Thu, 7 Nov 2013 00:18:56 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.93,650,1378857600"; d="scan'208";a="86581871"
X-IPAS-Result: AqEEABhMe1LAqArr/2dsb2JhbABZhBK/DYE5dIIlAQEFOj8MBAIBCA0EBAEBAR4JBzIUCQgBAQQOBQjFXRePKAYrBwaDGoEQA55wjkyCKg
Received: from unknown (HELO exchmail.f5net.com) ([192.168.10.235]) by seamgw02.olympus.f5net.com with ESMTP; 07 Nov 2013 08:18:56 +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; Thu, 7 Nov 2013 00:18:55 -0800
From: Xiaoyong Wu <X.Wu@F5.com>
To: Wan-Teh Chang <wtc@google.com>
Thread-Topic: [TLS] ALPN concerns
Thread-Index: Ac7avMo2dskaCaL/Q4ufEA6jUw/n4gAWXiRAAC3mgwAAD0VRYA==
Date: Thu, 7 Nov 2013 08:18:54 +0000
Message-ID: <E774C81546D66E429BF56B1474C7EBBA012CE34992@SEAEMBX01.olympus.F5Net.com>
References: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz> <E774C81546D66E429BF56B1474C7EBBA012CE328CB@SEAEMBX01.olympus.F5Net.com> <CALTJjxH5ev6GmMymg9kxR6OGO6aYG20zn72qjwMkOMgDbnOPkg@mail.gmail.com>
In-Reply-To: <CALTJjxH5ev6GmMymg9kxR6OGO6aYG20zn72qjwMkOMgDbnOPkg@mail.gmail.com>
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
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: Thu, 07 Nov 2013 08:19:07 -0000

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:wtc@google.com]
> Sent: Wednesday, November 06, 2013 11:27 PM
> To: Xiaoyong Wu
> Cc: Peter Gutmann; <tls@ietf.org>
> Subject: Re: [TLS] ALPN concerns
> 
> On Wed, Nov 6, 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.
> 
> 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