Re: [TLS] ALPN concerns

John Mattsson <john.mattsson@ericsson.com> Wed, 06 November 2013 16:06 UTC

Return-Path: <john.mattsson@ericsson.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 F29AA21E8147 for <tls@ietfa.amsl.com>; Wed, 6 Nov 2013 08:06:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.343
X-Spam-Level:
X-Spam-Status: No, score=-6.343 tagged_above=-999 required=5 tests=[AWL=-0.094, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 5IuA9QKO8iyD for <tls@ietfa.amsl.com>; Wed, 6 Nov 2013 08:06:05 -0800 (PST)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 5E12C21E8140 for <tls@ietf.org>; Wed, 6 Nov 2013 08:06:05 -0800 (PST)
X-AuditID: c1b4fb30-b7eff8e000006d14-f2-527a68eb0508
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id BA.49.27924.BE86A725; Wed, 6 Nov 2013 17:06:04 +0100 (CET)
Received: from ESESSMB307.ericsson.se ([169.254.7.88]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0328.009; Wed, 6 Nov 2013 17:06:03 +0100
From: John Mattsson <john.mattsson@ericsson.com>
To: Peter Gutmann <p.gutmann@auckland.ac.nz>, "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] ALPN concerns
Thread-Index: Ac7avMo21sv4RcDkL02knsdaQq+3gQATLHMA
Date: Wed, 06 Nov 2013 16:06:03 +0000
Message-ID: <CAAB765F71FCD344B6BABC031C19EC490F2F73@ESESSMB307.ericsson.se>
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: [153.88.183.154]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyM+Jvje6bjKogg8k93BZrjj5ntvh0vovR gcnj9++HjB5LlvxkCmCK4rJJSc3JLEst0rdL4MqY/uE6Y0E3Z8X/a79ZGxg3sHcxcnJICJhI HNn/mQnCFpO4cG89G4gtJHCIUWJRo1sXIxeQvYhRoqfvJFiCTcBAYu6eBiCbg0NEwFdi9nVu EFNYQEHi7hsWkAoRAUWJO2+7WSFsI4nLZ7aAxVkEVCQeTzzKDlLOK+At8edPJcSmMImeP0vA hnMKhEusn9PEDGIzAl3z/dQasMuYBcQlbj2ZD3WlgMSSPeeZIWxRiZeP/7FC2EoSi25/hqrX kViw+xMbhK0tsWzha7B6XgFBiZMzn7BMYBSdhWTsLCQts5C0zELSsoCRZRUje25iZk56ufkm RmAUHNzy22AH46b7YocYpTlYlMR5P7x1DhISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAOH1/ zqrbmtv0T//XK2zOldi2pa9UWHBGhOz1SeLu+4+a9PJP/vbU5/llm5ibxf/ObXWpOlNQvChh codBDPtsTw6R3q4b+4JKF2Wf4NRPWa4msftJ9O6fmzc2fw644mvzRGTnKfHParaTq/yOdprp vmBXfLjswp/Mtf1FxYuD3oey2N7IZ7DfqcRSnJFoqMVcVJwIACFVxbRQAgAA
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 16:06:11 -0000

Isn't the most probable explanation that they use an unsigned 8-bit int to store the length of the ClientHello message?

Then they might check that the length actually fits (as your example code), get some overflow exception, or just succeeding in discarding the most significant bits in the length.

/John


-----Original Message-----
From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Peter Gutmann
Sent: den 6 november 2013 07:53
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