IETF Logo Mail Archive

Re: [TLS] ALPN concerns

Peter Gutmann <p.gutmann@auckland.ac.nz> Wed, 06 November 2013 06:53 UTC

Return-Path: <p.gutmann@auckland.ac.nz>
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 AF66F21E80AE for <tls@ietfa.amsl.com>; Tue, 5 Nov 2013 22:53:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 76mb-fbFPNy6 for <tls@ietfa.amsl.com>; Tue, 5 Nov 2013 22:52:57 -0800 (PST)
Received: from mx1.auckland.ac.nz (mx1.auckland.ac.nz [130.216.125.243]) by ietfa.amsl.com (Postfix) with ESMTP id 2335821E8063 for <tls@ietf.org>; Tue, 5 Nov 2013 22:52:56 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1383720777; x=1415256777; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=t7OHaFcgf6g0Ar5Jr4FK9rkMRJpY9HqGaGEdjFJKfKk=; b=T+Pf/kResERBvK7QnLYdXC53Fg21tjlnk+1c5OuahItuxdQr+UM8vDjY 2clWOlLONJuPPC1uHr80KsWYGmscspFwAsp7YItiwFfhup1WwPZIMdltD N5uz5GcQE43LzSCYK+C4cBaZZJ4ug+eVujqrmJb/DJVHMbV88Jc9uyMUo s=;
X-IronPort-AV: E=Sophos;i="4.93,644,1378814400"; d="scan'208";a="287017409"
X-Ironport-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx1-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 06 Nov 2013 19:52:43 +1300
Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.207]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0158.001; Wed, 6 Nov 2013 19:52:42 +1300
From: Peter Gutmann <p.gutmann@auckland.ac.nz>
To: "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] ALPN concerns
Thread-Index: Ac7avMo2dskaCaL/Q4ufEA6jUw/n4g==
Date: Wed, 06 Nov 2013 06:52:42 +0000
Message-ID: <9A043F3CF02CD34C8E74AC1594475C736540E268@uxcn10-tdc06.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 06 Nov 2013 08:00:32 -0800
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 06:54:12 -0000

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.

v2.27.8 | Report a Bug | By Email | System Status