New issue
Advanced search Search tips

Issue 880104 link

Starred by 1 user
Status: Fixed
Owner:
davidben@chromium.org
Closed: Sep 5
Components:
EstimatedDays: ----
NextAction: 2018-09-10
OS: Windows
Pri: 2
Type: Bug-Regression



Sign in to add a comment

ERR_SSL_VERSION_INTERFERENCE for https://cdn.optimizely.com/

Reported by komm...@googlemail.com, Sep 3 
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3541.0 Safari/537.36

Example URL:
https://cdn.optimizely.com/

Steps to reproduce the problem:
1. Visit https://cdn.optimizely.com/
2. Get ERR_SSL_VERSION_INTERFERENCE

What is the expected behavior?
A TLS 1.3 connection should be established.

What went wrong?
I don't know. I'm in my private environment with no middle boxes that fiddle around in the TLS handshake.

Did this work before? Yes 68.0.3440.106

Chrome version: 71.0.3541.0  Channel: canary
OS Version: 10.0
Flash Version:

Comment 1 by davidben@chromium.org, Sep 3

Components: -Internals>Network Internals>Network>SSL
Labels: Needs-Feedback
Ugh. Thanks for the report! I can confirm this. This server appears to have implemented TLS 1.3 incorrectly. It is a draft-23 TLS 1.3 server, but it treats the RFC's version code, 0304, as draft-23, which is incorrect. This needs to be fixed or it will stop working in future versions of Chrome, Firefox, and other browsers as they deploy TLS 1.3.

Do you have a contact at Optimizely? Do you know what TLS stack they are running? Can you point them at this bug?

Comment 2 by komm...@googlemail.com, Sep 3 

No, I don't know anybody there and don't know anything about their infrastructure.
I just work for a company that loads content from this host on our site.
Project Member

Comment 3 by sheriffbot@chromium.org, Sep 3

Cc: davidben@chromium.org
Labels: -Needs-Feedback
Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Comment 4 by davidben@chromium.org, Sep 3

Cc: -davidben@chromium.org
Owner: davidben@chromium.org
Status: ExternalDependency (was: Unconfirmed)
Looks like that site is hosted by Akamai. Mozilla ran into this with another Akamai-hosted site. It sounds like the issue is that older versions of OpenSSL had a bug in their draft versions.

I'll reach out to them too, but my understanding is they be updating their OpenSSL.

Comment 5 by davidben@chromium.org, Sep 4

NextAction: 2018-09-10
Akamai tells me TLS 1.3 will be disabled over their network starting 9/4 through 9/7.

Snoozing this for next week: we should check the issue's been resolved by then and, if not, follow up with them.

Comment 6 by davidben@chromium.org, Sep 5

Status: Fixed (was: ExternalDependency)
This appears to be resolved now.

Comment 7 by komm...@googlemail.com, Sep 5 

Yes, it is (for now). They have disabled TLS 1.3 on their end. Hopefully this won't break again when they decide to reactivate TLS 1.3.
Capture.PNG
6.5 KB View Download

Comment 8 by monor...@bugs.chromium.org, Sep 10 

The NextAction date has arrived: 2018-09-10
►

Sign in to add a comment