This means that some buggy networking software or device is interfering with an upcoming performance and security improvement to Chrome.

Do you know what firewall product is being used (and what version)? Depending on the product, there might be an update that your network administrators need to take.

If possible, can you get the latest Chrome Canary (61.0.3157.0) and do the following for both the "Enabled (Draft)" and "Enabled (Experiment)" settings:

1) Go to chrome://flags#tls13-variant and set "TLS 1.3" to the appropriate value.
2) Restart the browser.
3) Start a NetLog as per (https://dev.chromium.org/for-testers/providing-network-details).
4) Visit https://tls.ctf.network/version.php and record what version of TLS you are using.
5) Save the NetLog.

@reporter: Could you please update the thread as per C#2.

Thanks in advance!

Apologies, I'm not in touch with the networking team (large company), so I'm unable to identify the software/hardware used for our corporate firewall.

Your other recommended step results are below. Thanks!

Deleted: chrome-net-export-log-default.json 285 KB

chrome-net-export-log-default.json 285 KB View Download

Deleted: chrome-net-export-log-draft.json 420 KB

chrome-net-export-log-draft.json 420 KB View Download

Deleted: chrome-net-export-log-experiment.json 1.6 MB

chrome-net-export-log-experiment.json 1.6 MB View Download

Thank you for providing more feedback. Adding requester "ajha@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

Awesome. In the meantime, I've set the TLS 1.3 flag to "Disabled" in Canary to see if it alleviates the issue for now.

Did you perform the steps behind your corporate firewall? Which settings allowed you to successfully visit the version.php page, versus giving the SSL_VERSION_INTERFERENCE error?

All steps were behind the firewall. Note that, as mentioned in the first post above, that Gmail works fine for an indeterminate amount of time (roughly 30-60m) before failing.

The server at tls.ctf.network should theoretically trigger the failure immediately. The expected results if this is the bug we believe it to be are:

Default/Disabled: You are connecting with TLSv1.2.
Draft: ERR_SSL_VERSION_INTERFERENCE
Experiment: You are connecting with TLSv1.3 Experiment.

Were those the results you saw?

Apologies, that is correct. I must have roamed to another network during the testing from above. Good catch.

Thank you for the additional information, if you're able to find out the name of the firewall product that would be useful, but otherwise if you aren't experiencing connection errors when leaving the setting at "Enabled (Experiment)", that would be best long-term. Otherwise setting it to "Disabled" should also work, though prevent TLS 1.3 from being negotiated.

related to 733223?

Marking this closed as this is from our previous TLS 1.3 experiments, and the latest one has fixed many of the issues with the prior experiment, if you have issues again or are able to reproduce the issues by setting chrome://flags#tls13-variant to "Enabled (Experiment 2)", please reopen an issue with details about your firewalls/antivirus that may be causing issues, along with a net-internals log (https://dev.chromium.org/for-testers/providing-network-details).