Re: [TLS] Another ClientHello length intolerance bug?

"David A. Cooper" <> Wed, 12 September 2018 17:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C2462130E52 for <>; Wed, 12 Sep 2018 10:07:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.488
X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9Udssb9SN1mx for <>; Wed, 12 Sep 2018 10:07:56 -0700 (PDT)
Received: from ( [IPv6:2610:20:6005:13::151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C1D191277BB for <>; Wed, 12 Sep 2018 10:07:55 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 12 Sep 2018 13:07:47 -0400
Received: from ( by ( with Microsoft SMTP Server id 14.3.408.0; Wed, 12 Sep 2018 13:07:52 -0400
Received: from [] ( []) by (8.13.8/8.13.1) with ESMTP id w8CH7dZd013793; Wed, 12 Sep 2018 13:07:39 -0400
To: David Benjamin <>
CC: "" <>
References: <> <>
From: "David A. Cooper" <>
Message-ID: <>
Date: Wed, 12 Sep 2018 13:07:39 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/html; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [TLS] Another ClientHello length intolerance bug?
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 12 Sep 2018 17:07:59 -0000

It would be unlikely to hit this bug in practice. I just tried a test with Chromium 65. In the default configuration, with a 9-byte server name, the TLSCiphertext.length was 192 bytes. So, in order to hit the bug it would seem that the server's DNS name would have to be exactly 83 bytes. When I changed the configuration to enable TLS 1.3 the ClientHello included a rather long padding extension to make TLSCiphertext.length exactly 512 bytes.

I just happened to hit this since I was sending a ClientHello message with several public keys in the key_share extension (including ffdhe keys).


On 09/12/2018 12:38 PM, David Benjamin wrote:
Wow! That's a bizarre one. I don't think we've run into this one before, but, from your description, any given implementation would only have a 1/256 chance of hitting it on every ClientHello change.

10 is a newline, so perhaps some implementation is doing a terrible job detecting TLS vs. some plaintext protocol. No idea about 14. (This kind of broken and unsound protocol-guessing behavior appears to be sadly common. Some buggy middlebox started misidentifying our ClientHellos as SIP when we removed the pre-standard ChaCha20 cipher suites!)

Do you have an example server? It would be good to get the problematic implementation fixed.


On Wed, Sep 12, 2018 at 9:24 AM David A. Cooper <> wrote:
According to RFC 7685 there was at least one TLS implementation that would hang the connection if it received a ClientHello record with a TLSCiphertext.length between 256 and 511 bytes.

During some recent testing I believe that I have come across a similar length intolerance bug. A number of servers seem to hang or close the connection if sent a ClientHello record with a TLSCiphertext.length of 266, 522, 778, ... (i.e., if TLSCiphertext.length mod 256 = 10). I have also encountered one server that will also hang the connection if sent a ClientHello record with a TLSCiphertext.length of 270, 526, 782 ... (i.e., if TLSCiphertext.length mod 256 = 14).

A test for this was just added to the development branch of (" target="_blank" rel="nofollow"> -- run with the "--grease" option.

As the server banner being returned by the servers that seem to have this problem are not all the same it is my guess that it is actually some middlebox that the is the source of the problem.

Has anyone else encountered this problem? We are trying to validate that this is a real bug (" target="_blank" rel="nofollow">



TLS mailing list" rel="noreferrer nofollow" target="_blank">