Closed Bug 1483129 Opened Last year Closed Last year

Enable the TLS 1.3 final version number


(NSS :: Libraries, enhancement)

Not set


(Not tracked)



(Reporter: mt, Assigned: mt)



Now that RFC 8446 has happened, we should use the final version number.

We need to retain the ability to version DTLS, so that will need some care.

There are also reports of the downgrade protection in TLS 1.3 being fragile in some deployments.  We haven't tested that (we couldn't), so we'll probably need some sort of control on that so that we can either roll it out progressively, or back out that bit if necessary.
Duplicate of this bug: 1485866
When the downgrade protection is a problem even though we no longer fallback to lower versions anyway?
Looks like Chromium has support in place for Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.42 Safari/537.36 as that has hit neatly. Firefox nightly must be close.
I think that was my client. I'm using Chromium Beta patched with the latest boringssl and .

Sorry for the confusion :)
Looks like a clean web agent GET and no errors and that means it works. 
Nothing else has.
Closed: Last year
Resolution: --- → FIXED
Target Milestone: --- → 3.39
This is NOT resolved. The very latest nightly Mozilla/5.0 (X11; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0 Built from does not work.  Can NOT reach site which does run the actual TLS 1.3 protocol and has been checked with openssl s_client.
Dennis, this is not a Firefox bug.  The fix will be in Firefox when NSS is next integrated there.  Be patient.
Well things are working like a charm now with rev/b75561ff5ffec3164338952adfe58620e5e3bc1d
Depends on: 1487150
You need to log in before you can comment on or make changes to this bug.