New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 760131 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Last visit > 30 days ago
Closed: Sep 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug



Sign in to add a comment

Site Can't Be Reached (ERR_SSL_VERSION_INTERFERENCE)

Reported by darrenhe...@gmail.com, Aug 29 2017

Issue description

Chrome Version       : 61.0.3163.59
OS Version: 10.0
URLs (if applicable) :  http://www.gmail.com
Other browsers tested:
  Add OK or FAIL after other browsers where you have tested this issue:
     Safari 5: n/a
  Firefox 4.x: OK
     IE 7/8/9: n/a

What steps will reproduce the problem?
1.
2.
3.

What is the expected result?


What happens instead of that?


Please provide any additional information below. Attach a screenshot if
possible.

UserAgentString: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.59 Safari/537.36



 

Comment 1 by mmenke@chromium.org, Aug 29 2017

Cc: svaldez@chromium.org
Components: Internals>Network>SSL
Status: Untriaged (was: Unconfirmed)
Cc: -svaldez@chromium.org davidben@chromium.org
Owner: svaldez@chromium.org
Status: Assigned (was: Untriaged)
Can you collect a net-internals trace?

https://dev.chromium.org/for-testers/providing-network-details

Also, do you know if you're running a proxy/firewall product on your network? Some products have known issues that interfere with newer version of TLS.

In addition to collecting a net-internals trace, can you go to chrome://flags/#tls13-variant and set it to "Enabled (Experiment)" and see whether that fixes your issue. If you have time, can you also try setting it to the other values of Enabled (RecordType, NoSessionID, Draft), and see which of those fix your issue.
Labels: Needs-Feedback
Attached is the .json with your request.

I am using Comcast Xfinity at home right now but also had this issue yesterday at my office.

The TLS13-variant that worked was "DRAFT" - not sure why.  

Thank you for helping to troubleshoot!
chrome-net-export-log.json
493 KB View Download
Huh. Did the Draft one work at your office or at home? Also, are you running some kind of antivirus product on your home machine?
Draft worked at our home (where I am working from today).  I tried each TLS drop down and the draft one was the winner.

I am currently running Mcafee and a bunch of other system protection software as this is a work computer. 
Do you know what the system protection software is?

Draft is the current iteration of TLS 1.3 which was undeployable due to bugs in this sort of networking middleware. We're trying out some variants which seem to do much much better than Draft and avoid a lot of these bugs, but it sounds like the software you are running has *different* bugs that now breaks! This leaves a bit of an annoying situation that we'll need to get to the bottom of. :-(
Cc: agl@chromium.org
+agl FYI. I'll see about setting up a trial of McAfee on a VM to test it, though we had another report that McAfee plus some other stuff was happy with Experiment and not Draft, so I suspect it's something else.
(No luck so far getting McAfee running. Though we have another bug that claims McAfee works fine with Experiment, so I don't think that's it.)

darrenherman: So, unfortunately, we will not be able to ship Draft because of compatibility issues with *other* buggy middleware. To avoid breaking future versions of Chrome for you, we will need to get to the bottom of the buggy middleware you've got. 

Could you please tell us what the other system protection software you've got is?

Additionally, we've set up some test servers which will hopefully narrow down the cause a little better. Could you do the following?

1. Set TLS 1.3 to "Experiment" and restart Chrome.
2. Go to chrome://net-export and start logging.
3. Load https://tls.ctf.network:9443/. This should not successfully load, but the way in which it does will be helpful to us.
4. Load https://tls.ctf.network:7443/ and wait for it to finish its test. Copy what it shows to this bug.
5. Stop logging in chrome://net-export and attach the log.

Thanks!
Here's a set of steps that should work better with firewalls blocking unusual ports:

1. Set TLS 1.3 to "Experiment" and restart Chrome.
2. Go to chrome://net-export and start logging.
3. Load https://experiment1.ctf.network/. This should fail to load, but the way in which it does will be helpful to us.
4. Load https://experiment2.ctf.network/ and wait for it to finish its test. Copy what it shows to this bug.
5. Stop logging in chrome://net-export and attach the log.
@ darrenherman: Could you respond to the questions in the past couple of comments?  We won't be able to make progress without your input.

We actually identified a problem thanks to a different bug report that ran those tests. Here's a new set of instructions:

If you can grab the latest Chrome Canary (63.0.3215.0 or later) from https://www.google.com/chrome/browser/canary.html and do the following steps, that would be helpful:

1) Set to TLS 1.3 to "Enabled (Experiment 2)" and restart Chrome.
2) Go to chrome://net-export and start logging.
3) Visit https://tls.ctf.network/version.php
4) Stop logging in chrome://net-export and attach the log.
5) Repeat the above steps for "Enabled (Experiment 3)".

Thanks!
Status: WontFix (was: Assigned)
Closing due to lack of feedback. We hope to run a new experiment with the newer variants that seem to resolve this in other instances.

Sign in to add a comment