Created attachment 813778 [details] [diff] [review] 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
Created attachment 814226 [details] [diff] [review] 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
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; »·······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.
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?
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.
changing target milestone to 3.15.4