Closed
Bug 1487150
Opened 6 years ago
Closed 6 years ago
Akamai edge chooses TLS 1.3 draft-23 (symantec.com, ibm.com, and others affected)
Categories
(NSS :: Libraries, defect)
NSS
Libraries
Tracking
(geckoview62 unaffected, firefox-esr52 unaffected, firefox-esr60 unaffected, firefox61 unaffected, firefox62 unaffected, firefox63+ fixed)
RESOLVED
WORKSFORME
3.39
Tracking | Status | |
---|---|---|
geckoview62 | --- | unaffected |
firefox-esr52 | --- | unaffected |
firefox-esr60 | --- | unaffected |
firefox61 | --- | unaffected |
firefox62 | --- | unaffected |
firefox63 | + | fixed |
People
(Reporter: cpeterson, Unassigned)
References
Details
(Keywords: regression, Whiteboard: [sitewait])
[Tracking Requested - why for this release]: Kai, I bisected this regression to NSS bug 1470914. When loading https://www.symantec.com/ in today's Firefox 63 Nightly, I get the follow network error page: Secure Connection Failed An error occurred during a connection to www.symantec.com. SSL received a malformed Server Hello handshake message. Error code: SSL_ERROR_RX_MALFORMED_SERVER_HELLO I assume this network error is related to distrusting Symantec certs, but I would then expect to see the cert error page with the yellow warning border like https://www.paypal.com: Warning: Potential Security Risk Ahead. Error code: MOZILLA_PKIX_ERROR_ADDITIONAL_POLICY_CONSTRAINT_FAILED
Flags: needinfo?(kaie)
Comment 1•6 years ago
|
||
Works on nightly 2018-08-27, broken on 2018-08-29. It's in the NSS_3_39_BETA2 uplift, https://hg.mozilla.org/mozilla-central/rev/4a4b97e9087c
Comment 2•6 years ago
|
||
Looks like this belongs in NSS, as it happened between 5bc69334e84f and 0776cf816a6d in NSS. Most of those patches are yours, mt, can you take a look?
Assignee: nobody → nobody
Component: Security: PSM → Libraries
Flags: needinfo?(martin.thomson)
Product: Core → NSS
Target Milestone: --- → 3.39
Version: Trunk → trunk
Comment 3•6 years ago
|
||
This is a bug in the TLS 1.3 implementation on the server. Gotta say, I didn't expect this one. We send them a supported_versions extension (in my testing: 002b 0009 08 0304 0303 0302 0301, indicating TLS 1.0 to 1.3 inclusive). They send one back with 0x7f17. That's TLS 1.3 draft-23. I suspect that what is happening is that they see TLS 1.3 and map that to the final version number internally, losing the distinction between draft and final. So they assume that they understand the advertised version. Then they write out the draft version. (Separately, I realize that I have some work to do on downgrade, which was the first thought that both ekr and I had here.)
Flags: needinfo?(martin.thomson)
Updated•6 years ago
|
Comment 4•6 years ago
|
||
Let's try outreach with Symantec.
Flags: needinfo?(miket)
Whiteboard: [needscontact]
Comment 5•6 years ago
|
||
(In reply to Mike Taylor [:miketaylr] (62 Regression Engineering Owner) from comment #4) > Let's try outreach with Symantec. I've sent an email to our partner list -- will update here.
Flags: needinfo?(miket)
Updated•6 years ago
|
Whiteboard: [needscontact] → [sitewait]
Comment 6•6 years ago
|
||
Oops, working in parallel. I reached out to someone at Symantec who tells me that they traced the issue to Akamai who have escalated the issue.
Updated•6 years ago
|
Summary: symantec.com Server Hello handshake Error code: SSL_ERROR_RX_MALFORMED_SERVER_HELLO → Akamai edge chooses TLS 1.3 draft-23 (symantec.com, ibm.com, and others affected)
Comment 7•6 years ago
|
||
Update after talking to Akamai: they have confirmed that OpenSSL appears to have a bug. They are working on it.
Updated•6 years ago
|
Flags: needinfo?(kaie)
Akamai is disabling the TLS 1.3 beta this week, until we update to the official 1.1.1 OpenSSL release.
Updated•6 years ago
|
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
Comment 10•6 years ago
|
||
Nightly 63.0 and as of last night 64.0 is working just fine and handles https://www.tls13.net/ perfectly.
Updated•6 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•