Re: [TLS] Another ClientHello length intolerance bug?
"David A. Cooper" <david.cooper@nist.gov> Wed, 12 September 2018 17:07 UTC
Return-Path: <david.cooper@nist.gov>
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 C2462130E52 for <tls@ietfa.amsl.com>; Wed, 12 Sep 2018 10:07:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.488
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Udssb9SN1mx for <tls@ietfa.amsl.com>; Wed, 12 Sep 2018 10:07:56 -0700 (PDT)
Received: from wsget2.nist.gov (wsget2.nist.gov [IPv6:2610:20:6005:13::151]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1D191277BB for <tls@ietf.org>; Wed, 12 Sep 2018 10:07:55 -0700 (PDT)
Received: from WSGHUB1.xchange.nist.gov (129.6.42.34) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 12 Sep 2018 13:07:47 -0400
Received: from postmark.nist.gov (129.6.16.94) by mail-g.nist.gov (129.6.42.33) with Microsoft SMTP Server id 14.3.408.0; Wed, 12 Sep 2018 13:07:52 -0400
Received: from [129.6.105.183] (cooper-optiplex-9010.campus.nist.gov [129.6.105.183]) by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id w8CH7dZd013793; Wed, 12 Sep 2018 13:07:39 -0400
To: David Benjamin <davidben@chromium.org>
CC: "tls@ietf.org" <tls@ietf.org>
References: <43b796a4-156a-6f16-4426-07c3cece61ba@nist.gov> <CAF8qwaCqEFvJE03W9=UxBD3BJY=oWcz7qpxbBOnN==CkkWToow@mail.gmail.com>
From: "David A. Cooper" <david.cooper@nist.gov>
Message-ID: <f8e3dcdf-a2c0-06e2-cabd-ec54e463569f@nist.gov>
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: <CAF8qwaCqEFvJE03W9=UxBD3BJY=oWcz7qpxbBOnN==CkkWToow@mail.gmail.com>
Content-Type: text/html; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner-Information:
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/YE3y1CqpFI9RT_dKgEUu7PmQRd8>
Subject: Re: [TLS] Another ClientHello length intolerance bug?
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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, 12 Sep 2018 17:07:59 -0000
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).
David
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.
David
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 testssl.sh (https://github.com/drwetter/testssl.sh" target="_blank" rel="nofollow">https://github.com/drwetter/testssl.sh) -- run testssl.sh 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 (https://github.com/drwetter/testssl.sh/pull/1113" target="_blank" rel="nofollow">https://github.com/drwetter/testssl.sh/pull/1113).
Thanks,
David
TLS mailing list
TLS@ietf.org
https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=02%7C01%7Cdavid.cooper%40nist.gov%7Cf28ded1a91b04bb315fb08d618ce3858%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C636723671318863928&sdata=EmTVNFgZguAhrvuCn8coADMwrK8GBGBkD11daI2C0Zs%3D&reserved=0" rel="noreferrer nofollow" target="_blank">https://www.ietf.org/mailman/listinfo/tls
- [TLS] Another ClientHello length intolerance bug? David A. Cooper
- Re: [TLS] Another ClientHello length intolerance … David Benjamin
- Re: [TLS] Another ClientHello length intolerance … David A. Cooper