IETF Logo Mail Archive

Re: [TLS] ALPN concerns

Wan-Teh Chang <wtc@google.com> Thu, 07 November 2013 07:27 UTC

Return-Path: <wtc@google.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 B749D21F9E12 for <tls@ietfa.amsl.com>; Wed, 6 Nov 2013 23:27:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
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 a-huJr5IwJkT for <tls@ietfa.amsl.com>; Wed, 6 Nov 2013 23:27:31 -0800 (PST)
Received: from mail-ve0-x232.google.com (mail-ve0-x232.google.com [IPv6:2607:f8b0:400c:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBB921E8063 for <tls@ietf.org>; Wed, 6 Nov 2013 23:27:27 -0800 (PST)
Received: by mail-ve0-f178.google.com with SMTP id db12so108960veb.9 for <tls@ietf.org>; Wed, 06 Nov 2013 23:27:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=VSVu4IyzWQa4cemtzIVv6v7wK83shBlpkuf+2DOxxtk=; b=aHUS6owaNusimwp78VINRvv5geSuanH0JzqQ96eGHBkcjsVsKOMU1a0IR2LIJg+cv2 6xX3771l68129bPd16ckFVPULi32nUfx5DtM/bPkZ/AJ/Lra26cC+1A5cGIPsQX2+3b/ QAapMhFcNJ+WeYvmlicvY6R3p1wQByEgScDA4zX9x/7HXmcaLbOpg+KIdkNckNZpUdov 1MbAUODVmd4HdQyPwLHR6m+ED52WBRQYepN7JYx3p/PXam5QPrqwfVGGQ88uJHvB9n0x qVlZoUN16+qOHYJg3YVxMJN3Mvv7riHXafwMYKaxp5/2Il0Fm3jbnxKcTWNAkcIxzJZw uIZw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=VSVu4IyzWQa4cemtzIVv6v7wK83shBlpkuf+2DOxxtk=; b=IVt4JLTbBZ1TDH42d6YG+cnnLaOqqkZsx+WA0xlsd40+zKE17WVJBH5FBAh1FZQAMb 1P0espwWSoDBHRwRdfU3k7I4OCt5EViK2AIAQk30wnmjq146/V/X3IT4Sc/8GJ/aQ9Pu Wa36u67mwYe1RaXbY/cyLxF2t16JIduR2DRIYUqIoOYJRPb6twLIcdRfq555m2zU9wIp XlY0+iBKU4J61R6Qu7zWb8keRoXbtkg8arHhld4xsCkI2Qp4SXOFLja/otbXcvoNZKhu rbTbZfyxP2FAr7p79ULsUmtaShw7Q3zVOZbiNT1Tn0sU2rd/dzAmbKOOyPTGa6DzOK3H /m9Q==
X-Gm-Message-State: ALoCoQnnbaLNLhWItLHxiBk13idbvsQJVFEg7NmjYLQ39dunECA5KbKk/rVdF09aXU/C3cXWplTBisnjdXri5VTiLjMOM5UCPDBnJZT3GsyMkc7x66u5mQgUtotOOVowqOlQaugRNMxbyd0KsTbBGviirjxvGNVNZEg8osSf3w+blvuliMCuC/X6z9N3bsBK337BCw/ppldz
MIME-Version: 1.0
X-Received: by 10.220.244.132 with SMTP id lq4mr130917vcb.31.1383809246880; Wed, 06 Nov 2013 23:27:26 -0800 (PST)
Received: by 10.52.167.10 with HTTP; Wed, 6 Nov 2013 23:27:26 -0800 (PST)
In-Reply-To: <E774C81546D66E429BF56B1474C7EBBA012CE328CB@SEAEMBX01.olympus.F5Net.com>
References: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz> <E774C81546D66E429BF56B1474C7EBBA012CE328CB@SEAEMBX01.olympus.F5Net.com>
Date: Wed, 06 Nov 2013 23:27:26 -0800
Message-ID: <CALTJjxH5ev6GmMymg9kxR6OGO6aYG20zn72qjwMkOMgDbnOPkg@mail.gmail.com>
From: Wan-Teh Chang <wtc@google.com>
To: Xiaoyong Wu <X.Wu@f5.com>
Content-Type: text/plain; charset="ISO-8859-1"
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 07:27:32 -0000

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

v2.23.0 | Report a Bug | By Email