Closed Bug 923696 Opened 11 years ago Closed 11 years ago

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


(NSS :: Libraries, defect, P1)



(Not tracked)



(Reporter: agl, Assigned: agl)



(1 file, 1 obsolete file)

Attached patch patch (obsolete) — Splinter Review
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.
Assignee: nobody → agl
OS: Linux → All
Priority: -- → P1
Hardware: x86_64 → All
Target Milestone: --- → 3.15.3
Attachment #813778 - Attachment is patch: true
Attachment #813778 - Attachment mime type: text/x-patch → text/plain
Attachment #813778 - Flags: review?(wtc)
I reviewed the patch at

Patch checked in:
Attachment #813778 - Attachment is obsolete: true
Attachment #813778 - Flags: review?(wtc)
Attachment #814226 - Flags: review+
Attachment #814226 - Flags: checked-in+
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.
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;

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.
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?
Closed: 11 years ago
Resolution: --- → FIXED
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 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.
changing target milestone to 3.15.4
Target Milestone: 3.15.3 → 3.15.4
You need to log in before you can comment on or make changes to this bug.