A ClientHello length intolerance bug

[dcooper16]

Just as some servers will fail if the length of the ClientHello is between 256 and 511 bytes (see RFC 7685), it seems that some servers (or a middlebox sitting in front of the servers) will fail if the length of the ClientHello is 522, 778, 1034, ... bytes (i.e., if length mod 256 = 10). I have also encountered one server that will also fail if the length of the ClientHello is 526, 782, 1038, ... bytes (i.e., if length mod 256 = 14).

In the case of that one server, the first ClientHello sent by run_pfs() was exactly 1038 bytes, and so run_pfs() was reporting that the server didn't support any PFS ciphers even though it did.

This PR addresses the problem in two ways. First, it modifies socksend_tls_clienthello() so that if the length of the ClientHello would be more than 511 bytes and length mod 256 would be 10 or 14, it adds a 5-byte padding extension in order to ensure that the final length of the ClientHello will not be a length that could trigger the bug.

Second, this PR adds a test to run_grease() to send ClientHello messages of the exact lengths that do trigger the bug so that users can be made aware that their servers have the problem.

[drwetter]

Has anybody else seen such an intolerance

@PeterMosmans @jurajsomorovsky?

[jurajsomorovsky]

@ic0ns recently spotted something similar in the wild. Is it true?

[ic0ns]

Not directly like this, but some server only allow a certain number of ciphersuites. Eg. if you propose more than 256 (512 Byte) ciphersuites the server won't answer you.

[dcooper16]

Not directly like this, but some server only allow a certain number of ciphersuites. Eg. if you propose more than 256 (512 Byte) ciphersuites the server won't answer you.

Yes, that's a different issue that we already knew about. testssl.sh already checks for that and generally sends 128 or fewer cipher suites in each ClientHello message.

[dcooper16]

I just submitted a few updates to this PR:

• I removed the changes to socksend_tls_clienthello() - these will be submitted as a separate PR.

• I added a test for a ClientHello message length of 266 bytes, but only if the server can generally handle messages with lengths between 256 and 511 bytes.

• I corrected the calculation of the length of the padding extension in cases in which a TLS 1 or TLS 1.1 ClientHello is being sent.

[drwetter]

Thanks!

[drwetter]

@tomato42 : does this incompatibility (ClientHello 522, 778, 1034 / 526, 782, 1038 -- see above) ring a bell?

[tomato42]

@drwetter it does, but very mildly - it might have been some kind of Cisco gear but I'm really not sure about it (one that would reject CH above 512B long)

but in general it looks like there are different implementations with bugs like this, see the size c#/ (count of ciphers in CH) and size c/ (size of the CH in bytes) lines in the last scan I did January 2017

if you have a machine like this on hand, what does the tls_prober say about it?

[drwetter]

@tomato42 : you mean Cisco ACE? yeah, that was the one with 512B restriction IIRC.

There are couple of servers @dcooper16 mentioned. Most often was 11.4 or 11.5 from F5's BigIP.
If that's true seems a different problem they have.

Shouldn't that cause hiccups elsewhere?

size c# | size c/ match: doesn't look like it but thanks

[tomato42]

no, the rejection of 256-511 byte CH was the BigIP, rejection of the 512B CH was something typically not used for serving web, not the ACE – might have been for email...

Shouldn't that cause hiccups elsewhere?

it could, but browsers are usually really careful with changes to their CH and running multiple tests before actually deploying them (even to alpha channels)

size c# | size c/ match: doesn't look like it but thanks

hmm, could be because those values were arrived at with binary search so something regular would require one of the probes hitting it exactly, also IIRC, those probes were run only if the server was intolerant to very big CH (like 130kB big), so if they handled that well, it wouldn't be detected

[PeterMosmans]

@drwetter I only know of the Cisco ACE issues with large Client Hellos..

[drwetter]

@tomato42 Yes, I remember very good the old problem. What I meant that it seems that maybe F5 has another padding problem

[drwetter]

FYI: It's in fact F5 BigIP. Kudos for @dcooper16 detecting this.

[saravananmk]

FYI: It's in fact F5 BigIP.

@drwetter @dcooper16 The ClientHello length intolerance on F5 BIGIP is due to https://support.f5.com/csp/article/K53322151

[tomato42]

@saravananmk you mean the F5 KB is incomplete? because I don't think the 522B Client Hello would be fragmented...

[drwetter]

I read that different, too

[saravananmk]

@saravananmk because I don't think the 522B Client Hello would be fragmented...

I observed the following (testssl.sh 3.0rc1)

ClientHello length is 266 bytes: TCP seg#1: 5 bytes, seg#2: 266 bytes.
ClientHello length is 522 bytes: TCP seg#1: 5 bytes, seg#2: 522 bytes.
ClientHello length is 778 bytes: TCP seg#1: 5 bytes, seg#2: 778 bytes.
ClientHello length is 1034 bytes: TCP seg#1: 5 bytes, seg#2: 1034 bytes.
ClientHello length is 1290 bytes: TCP seg#1: 5 bytes, seg#2: 1290 bytes.
ClientHello length is 1546 bytes: TCP seg#1: 5 bytes, seg#2: 1448 bytes, seg#3: 98 bytes.
ClientHello length is 1802 bytes: TCP seg#1: 5 bytes, seg#2: 1448 bytes, seg#3: 354 bytes.
ClientHello length is 2058 bytes: TCP seg#1: 5 bytes, seg#2: 1448 bytes, seg#3: 610 bytes.

So I still believe it is that F5 KB (K53322151).

[tomato42]

so the record layer header is sent in a separate TCP segment? that would seem like a bug in testssl.sh... But then if that split is constant it would make testssl.sh unable to scan any F5 hosts suffering from K53322151

[drwetter]

Isn't the TCP fragment size negotiated on a different (not TLS/SSL) layer?