Issue metadata
Sign in to add a comment
|
ERR_SSL_VERSION_INTERFERENCE visiting inbox.google.com
Reported by
christia...@gmail.com,
Jun 23 2017
|
||||||||||||||||||||||||
Issue descriptionChrome Version : 61.0.3138.0 OS Version: OS X 10.12.5 URLs (if applicable) : https://inbox.google.com Other browsers tested: Add OK or FAIL after other browsers where you have tested this issue: Safari 5: OK Firefox 4.x: OK IE 7/8/9: What steps will reproduce the problem? 1. Visit https://inbox.google.com 2. 3. What is the expected result? Page loads. What happens instead of that? Presented with ERR_SSL_VERSION_INTERFERENCE. Please provide any additional information below. Attach a screenshot if possible. UserAgentString: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3138.0 Safari/537.36
,
Jun 23 2017
This means some buggy networking software or device is interfering with an upcoming performance and security improvement to Chrome. To help diagnose this, could you attach a NetLog per these instructions? Thanks! https://dev.chromium.org/for-testers/providing-network-details Also, what kind of network is this (home? work?). Do you have any antivirus, firewall, proxy, or other networking middleware products configured? If so, do you know which they are?
,
Jun 23 2017
This is a work network. Unfortunately, I can no longer launch Chrome Canary. I attempted an update that I noticed was available immediately after submitting this report, and the update causes Chrome Canary to crash instantly (browser is never rendered.)
,
Jun 23 2017
Thank you for providing more feedback. Adding requester "davidben@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 23 2017
Yeah, that's a separate problem and should hopefully be fixed in the next nightly build. Sorry about that. :-( Do you mind checking again in a day or two? When you do, you'll also want to go to chrome://flags and set "Maximum TLS version enabled" to "TLS 1.3" and "Experimental QUIC protocol" to disabled, to make sure you're in the right experiment group. Meanwhile, if you could find out what kinds of firewalls and proxies your work network has, that would be very helpful! Thanks!
,
Jun 26 2017
I am waiting on my IT team to respond with network details here at the office, but until then I was able to capture a net-export session on https://inbox.google.com which is attached. I also noticed the issue on https://www.cockroachlabs.com/
,
Jun 26 2017
Thank you for providing more feedback. Adding requester "davidben@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 26 2017
IT was able to share with me that "currently we are using [TLS] 1.0 1.1 1.2" and that we use watchguard for the firewall.
,
Jun 26 2017
Alright, yeah, this is a bug in Watchguard. Merging into our other Watchguard bugs. As a workaround, you should ask your administrators to disable the "Allow only SSL compliant traffic" setting. It doesn't actually do much useful without content inspection on and is buggy. http://www.watchguard.com/help/docs/fireware/11/en-US/Content/en-US/proxies/https/https_general_settings_c.html |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by rdsmith@chromium.org
, Jun 23 2017