Subject: [TLS] Another ClientHello length intolerance bug?

From: "David A. Cooper" <[email-masked]>
Date: Wed, 12 Sep 2018 12:23:56 -0400

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) -- 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).

Thanks,

David

---

From: David Benjamin <[email-masked]>
Date: Wed, 12 Sep 2018 11:38:28 -0500

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

On Wed, Sep 12, 2018 at 9:24 AM David A. Cooper <[email-masked]>
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
> 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) -- 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).
>
> Thanks,
>
> David
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 12 Sep 2018 13:07:39 -0400

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).

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

On Wed, Sep 12, 2018 at 9:24 AM David A.
Cooper <[email-masked]>
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 testssl.sh (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).

Thanks,

David

TLS mailing list

[email-masked]