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
- Re: [TLS] ALPN concerns Nico Williams
- [TLS] ALPN concerns Brian Smith
- Re: [TLS] ALPN concerns Yoav Nir
- Re: [TLS] ALPN concerns Martin Thomson
- Re: [TLS] ALPN concerns Yoav Nir
- Re: [TLS] ALPN concerns Geoffrey Keating
- Re: [TLS] ALPN concerns Yoav Nir
- Re: [TLS] ALPN concerns Peter Gutmann
- Re: [TLS] ALPN concerns John Mattsson
- Re: [TLS] ALPN concerns Yoav Nir
- Re: [TLS] ALPN concerns Xiaoyong Wu
- Re: [TLS] ALPN concerns Adam Langley
- Re: [TLS] ALPN concerns Yoav Nir
- Re: [TLS] ALPN concerns Dr Stephen Henson
- Re: [TLS] ALPN concerns Yutaka OIWA
- Re: [TLS] ALPN concerns Andrei Popov
- Re: [TLS] ALPN concerns Dr Stephen Henson
- Re: [TLS] ALPN concerns Adam Langley
- Re: [TLS] ALPN concerns Mark Nottingham
- Re: [TLS] ALPN concerns Wan-Teh Chang
- Re: [TLS] ALPN concerns Wan-Teh Chang
- Re: [TLS] ALPN concerns Xiaoyong Wu
- Re: [TLS] ALPN concerns Brian Smith
- Re: [TLS] ALPN concerns Andrei Popov
- Re: [TLS] ALPN concerns Brian Smith
- Re: [TLS] ALPN concerns Nikos Mavrogiannopoulos
- Re: [TLS] ALPN concerns Andrei Popov
- Re: [TLS] ALPN concerns Pascal Urien