Example of ERR_SSL_VERSION_INTERFERENCE (tcpdumps available)
Reported by
jacob.ho...@gmail.com,
Nov 17
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Example URL: https://www.lovcour.com Steps to reproduce the problem: Note: the provided URL reproduced the problem as of November 16, but as of November 17 it no longer does. However, I've attached tcpdumps from when it reproduced. 1. Ensure TLS 1.3 is enabled at chrome://flags/#tls13-variant. 2. Visit https://www.lovcour.com What is the expected behavior? Page loads successfully. What went wrong? ERR_SSL_VERSION_INTERFERENCE is displayed, blocking the page load. Did this work before? N/A Chrome version: 70.0.3538.102 Channel: stable OS Version: Flash Version: The site's IP address, 101.200.61.149, is in China, which suggests this may be interference from the Great Firewall. I verified that enabling TLS 1.3 caused the issue to reliably reproduce from my US IP address. Disabling TLS 1.3 caused the issue to stop reproducing. There's a thread with the owner of www.lovcour.com at https://community.letsencrypt.org/t/error-ssl-error-no-cypher-overlap/77643. Firefox reported SSL_ERROR_NO_CYPHER_OVERLAP.
,
Nov 19
Thanks for filing the issue! This is likely due to a buggy antivirus, firewall, or proxy on your machine or network. Are you running Kaspersky anti-virus? If so, does it work if you disable it, specifically the "Scan encrypted connections" setting? It seems they recently shipped a bad update and broke stuff. Could you please help us to get a NetLog of what occurred if you can reproduce it, see details here: https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details. Note: With reference to the Issue: 895155 , CC'ing: davidben for further inputs on it. Thanks..!
,
Nov 19
visa.karala: It is unlikely at this point that any new issues have anything to do with Kaspersky or issue #895155 . Kaspersky already shipped the fix. Please have ask TE folks to stop referencing it. Requesting a NetLog is good practice, though. The pcap shows the server (or its network) is rejecting the connection with a handshake_failure alert, which means the immediate problem is on the server, or the network. The thread seems to suggest the latter and some problems with China's firewall? Can you ask the site owner to: a) Set up some test domain that continues to demonstrate the issue, so folks can debug it. b) Check what nginx's error log shows. That may pinpoint issues with the server vs. the network.
,
Nov 19
I'll ask the site owner to set up a test domain to try and repro again, and provide the nginx logs. Thanks!
,
Nov 19
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
,
Nov 19
Re-adding the Needs-Feedback label while waiting for a response from contacting the site owner to attempt a repro.
,
Dec 5
[jacob.hoffmanandrews]: Any luck getting a test site up? If that's not doable, we can't make progress here, and will have to close the bug.
,
Dec 5
Let's go ahead and close; I don't think we're likely to get the site owner to set up another repro site. Thanks!
,
Dec 5
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
,
Dec 5
Sounds good. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by krajshree@chromium.org
, Nov 18