Re: [TLS] ALPN concerns

Yutaka OIWA <y.oiwa@aist.go.jp> Wed, 06 November 2013 20:50 UTC

Return-Path: <y.oiwa@aist.go.jp>
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 6A0E511E80E2 for <tls@ietfa.amsl.com>; Wed, 6 Nov 2013 12:50:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.483
X-Spam-Level:
X-Spam-Status: No, score=-5.483 tagged_above=-999 required=5 tests=[AWL=0.494, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4]
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 9DJhsKLxaRFD for <tls@ietfa.amsl.com>; Wed, 6 Nov 2013 12:50:46 -0800 (PST)
Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) by ietfa.amsl.com (Postfix) with ESMTP id 807BB11E8119 for <tls@ietf.org>; Wed, 6 Nov 2013 12:50:42 -0800 (PST)
Received: from mail-ve0-f169.google.com ([209.85.128.169]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKUnqropb00b4eGw+AePrTm7KTsLzPyfr0@postini.com; Wed, 06 Nov 2013 12:50:42 PST
Received: by mail-ve0-f169.google.com with SMTP id jy13so41517veb.0 for <tls@ietf.org>; Wed, 06 Nov 2013 12:50:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=lWp2l2oW4PDruVI+uOECfXVK8/HJHy/BVU2f8wa4o4s=; b=fuoQRMp65aTICSjsluzZq5OCL7rL3Av9mk4n/v83pb+jkiiWSxLa2ywHTtwD7MI8WU HZQlDQF0irRUm3tqlOCrUvCf3r/8gAPczP/u1dXx0UUu0Km9Z+xVIVgfAYD1GrTJnPf5 CallEnORdmFAgwFtf4TVtIECC6iypKgqCsl4o=
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:from:date :message-id:subject:to:cc:content-type; bh=lWp2l2oW4PDruVI+uOECfXVK8/HJHy/BVU2f8wa4o4s=; b=PrUj+sLQce7JYoKdsQmyY9FH+hjiFBydq+QPebMharaQqBguMxf//vEC/RUs5NMNTW q0WYqV0OcTFdnNlfxLnN9CSlespa22O9lzrYchkqv3v4ERX3o6vw8642jXGCVZlhsger bxKuQJsoNsxqx4gbHDSuJKDrKnEqQbghOZvjtrqgwdTgryh8LbX6VIHb0Aw1uOxuX9h9 aAoDsIQqVV/gHQqlNkYLkD7lVxGniiBNSi4RGEiGXNeH42wBkCjvOrxo6bRvWfqlcbcP cNtH1Q26q2pLq4lnYk6JhhkVs7p6fH7IIf8rioJkuzJZ+9CvLjScHEB0Zky5jlb0v7Gb pb2A==
X-Gm-Message-State: ALoCoQmxDjHqVKoCjDGUKotZM/3jwJO3lW++dfILAgCuwBaUF43nOQEiqFA3jno35Sn/n7ttufkC3vkqrlkHUItrXY7PVIBIWE8JbpvdE5kQy5Z7y804A+8dFv8/LjmyaJ2/AUB/Xp/ffojYjorADw4HxiiBC+7KaQ==
X-Received: by 10.58.108.196 with SMTP id hm4mr3922462veb.28.1383771041466; Wed, 06 Nov 2013 12:50:41 -0800 (PST)
X-Received: by 10.58.108.196 with SMTP id hm4mr3922457veb.28.1383771041315; Wed, 06 Nov 2013 12:50:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.58.100.145 with HTTP; Wed, 6 Nov 2013 12:50:21 -0800 (PST)
In-Reply-To: <E774C81546D66E429BF56B1474C7EBBA012CE328CB@SEAEMBX01.olympus.F5Net.com>
References: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz> <E774C81546D66E429BF56B1474C7EBBA012CE328CB@SEAEMBX01.olympus.F5Net.com>
From: Yutaka OIWA <y.oiwa@aist.go.jp>
Date: Thu, 7 Nov 2013 05:50:21 +0900
Message-ID: <CAMeZVwuKKsx+8xphBqxqHFfShmPZXAP_ZbpWeqJ4+LwGpRLHkA@mail.gmail.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: Wed, 06 Nov 2013 20:50:50 -0000

> 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>om>:
> 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>jp>, <yutaka@oiwa.jp>
OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D  3139 8677 9BD2 4405 46B5]