923696 - F5 BIG-IP devices < 10.2.4 hang the connection when NSS sends a large resumption ClientHello

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[Adam Langley]

Attachment: patch

Best we can tell, F5 BIG-IP devices with firmware < 10.2.4 hang the connection when a ClientHello record is received with version > 0x0301 and is longer than 255 bytes.

With TLS 1.2, we're hitting this size limit on resume connections with long hostnames. Since the servers negotiate TLS 1.2, NSS previously used 0x0303 as the ClientHello record version. This change causes NSS to always use at most 0x0301 as the ClientHello record version, even when we are resuming a session and know that the server supports TLS 1.2.

http://rt.openssl.org/Ticket/Display.html?id=2771#txn-33812
https://codereview.chromium.org/25868004

Comment 1

[Wan-Teh Chang]

Attachment: Patch v2, by Adam Langley

I reviewed the patch at https://codereview.chromium.org/25868004/.

Patch checked in: https://hg.mozilla.org/projects/nss/rev/fc6df0051709

Comment 2

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

Hi, did you do any measurements to see if this change will cause regressions for other products? For example, it is plausible, even likely, that we will encounter another product that works better with the old code than with the new code.

Did you compare this behavior to what OpenSSL and SChannel are doing when TLS 1.2 is enabled? I think the best way to ensure compatibility here is to get the major implementations doing exactly the same thing here.

Comment 3

[Adam Langley]

OpenSSL matches the behaviour of the new code, except for renegotiations:

»·······if (s->state == SSL3_ST_CW_CLNT_HELLO_B
»·······»·······»·······»·······&& !s->renegotiate
»·······»·······»·······»·······&& TLS1_get_version(s) > TLS1_VERSION)
»·······»·······*(p++) = 0x1;
»·······else
»·······»·······*(p++)=s->version&0xff;

I've not checked what SChannel is doing.

It is quite possible that something else will go wrong with this change, although historically, sending lower record version numbers has been less troublesome. We've only just landed this change on Chrome trunk so we don't have a good feeling for any side effects yet.

Comment 4

[Wan-Teh Chang]

Adam: with this patch applied to NSS, can we send a ClientHello larger than 255 bytes
to those servers? Or do we still need to keep ClientHello under 255 bytes?

Comment 5

[Adam Langley]

There are two F5 bugs:

1) Rejecting all ClientHello records where the record is > 255 bytes.
2) Rejecting ClientHello records where the record is > 255 and the record version is > 0x0301.

I think bug (1) happened first and was fixed, then TLS 1.1/1.2 support was added and it introduced bug (2).

The list of servers on https://www.imperialviolet.org/2013/10/07/f5update.html have bug (1). (I've a much longer list of URLs, those are just the top 200.) Since the list is so long, I think we have to continue to keep ClientHello records short for some time.

Thankfully these servers don't support SessionTickets.

We may wish to use tricks like not performing a resume if the SNI name is too etc. I plan on looking into tricks like that.

Comment 6

[Kai Engert (:KaiE:)]

changing target milestone to 3.15.4