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 1.3.

Can you set chrome://flags/#tls13-variant to "Enabled (Experiment)" and see whether your connection works again, that should work around the issues with the Fortinet software, while still allowing more secure forms of TLS to be negotiated.

Before you do that, could you also attach a NetLog per these instructions? Thanks!
https://dev.chromium.org/for-testers/providing-network-details

Hi there, here's a NetLog produced when my TLS flag is set to default.

Deleted: chrome-net-export-log.json 820 KB

chrome-net-export-log.json 820 KB View Download

Okay, that's fascinating! You are already on the more compatible variant. Hrm.

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?

It's a work network, here's a description of the environment from one of our network engineers:

Managed network, local subnets through a 4510+E core switch, access out through a cisco PIX then onsite bluecoat for browsing. Upstream is a second bluecoat virtualised appliance as part of our ISP/security provider's clean pipe environment.

Does that help?

That's good to know. Its possible that updating your Bluecoat boxes to the latest version will fix the issue (SSLV 4.0 or newer), but otherwise can you try the various 'Enabled' options in the chrome://flags#tls13-variant setting and see which of them fix your issues? We're trying to find a mitigation on our end to work around middlebox issues we've seen in other intermediary appliances.

Only Enabled Draft gave me both Inbox and Gmail access so I'll leave it set there for now. Thanks for your help.

That's good to know, thanks. If you can find out the version of Bluecoat, that would be useful to know so we can see about finding a way to reproduce this. Otherwise leaving it at Enabled Draft should be fine for now.

Hi there, we're on Bluecoat V6.6.4.2

ryan: 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 fail to 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!

Hi there, log attached. The URL in step 4 didn't load, this was the message:
tls.ctf.network took too long to respond.

If this isn't expected, I assume we don't have port 7443 open on our firewall. I could request it's opened for my static IP, let me know if that'd be helpful to try.

Deleted: chrome-net-export-log.json 3.7 MB

chrome-net-export-log.json 3.7 MB View Download

Ugh, I guess that's what we get for hosting those on funny ports. :-/ I think both tests are just hitting your firewall, yeah. If you could get 7443, 8443, and 9443 open and try again, that'd be really helpful.

Otherwise, I'll see about spinning those up somewhere else instead.

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.

Thanks for spinning up without funky ports, makes things easier on this side! Here's the results:

Running experiment...
Fetching iteration 1
  Result: 404
Fetching iteration 2
  Result: Error: request failed
Fetching iteration 3
  Result: Error: request failed
Fetching iteration 4
  Result: 404
Fetching iteration 5
  Result: Error: request failed
Fetching iteration 6
  Result: Error: request failed
Fetching iteration 7
  Result: Error: request failed
Fetching iteration 8
  Result: 404
Fetching iteration 9
  Result: 404
Fetching iteration 10
  Result: 404
Fetching iteration 11
  Result: 404
Fetching iteration 12
  Result: 404
Fetching iteration 13
  Result: 404
Fetching iteration 14
  Result: 404
Fetching iteration 15
  Result: Error: request failed
Fetching iteration 16
  Result: Error: request failed
Fetching iteration 17
  Result: 404
Fetching iteration 18
  Result: 404
Fetching iteration 19
  Result: Error: request failed
Fetching iteration 20
  Result: 404
FAILED

Deleted: chrome-net-export-log.json 4.9 MB

chrome-net-export-log.json 4.9 MB View Download

Thanks! Alas, that told us both our theories were wrong. Good news is we've since managed to reproduce the issue and we think we know what the problem was.

Hopefully in a few weeks, we'll have Experiment2 and Experiment3 variants on canary (no relation to the hostnames of those test servers) that will work in your deployment and not break the folks who had troubles with Draft.

Glad it was useful! I'm happy to run the tests again in Canary once they're ready.

If you can grab the latest Chrome Canary (63.0.3215.0 or later) and can do the following steps, that would be incredibly 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 (It should succeed if we have the right fix).
4) Stop logging in chrome://net-export and attach the log.
5) Repeat the above steps for "Enabled (Experiment 3)".

Sweet as, helpful that Google now allows side-by-side Chrome version installs on Mac!

Here's the log for "Enabled (Experiment 2)"

Deleted: chrome-net-export-log.json 1019 KB

chrome-net-export-log.json 1019 KB View Download

And here's the log for "Enabled (Experiment 3)". Both were successful.

Deleted: chrome-net-export-log.json 1.5 MB

chrome-net-export-log.json 1.5 MB View Download

Currently Mac only allows side-by-side installation of Canary with a different version of Chrome, I think work is being done to allow side-by-side installation of all the branches (Dev/Beta/Canary/Stable), though that still hasn't finished.

Cool, thanks, since Experiment 2 and 3 seem to be working for users with issues with other TLS 1.3 variants, we'll probably start a field trial as part of the next Chrome release to use that variant of TLS 1.3 to work around middlebox issues. Leaving TLS 1.3 set to Disabled or Draft should probably work for you until we cut a release with the new variants.

Ah I see, I use Beta but would be nice to also have Stable to troubleshoot customer issues.

Thanks, will you update this thread when the new release is launched so I know to change the setting back to default? That's be most appreciated if possible.

Yeah, I'll make sure to ping this bug once we've launched the experiment onto Beta.

The new experiment is now on Beta.

Thanks - unfortunately our IT team upgraded Bluecoat to TLS1.3 and I can't connect to certain HTTPS URLs on Chrome or Firefox again. Gmail.com works, but apple.com doesn't for example.

IE and Edge connect fine however.

apple.com does not deploy TLS 1.3, so that sounds unrelated. Are you also getting ERR_SSL_VERSION_INTEREFERENCE there?

If it's also breaking Firefox, I would suggest you file a ticket with Blue Coat. Their product can be, alas, a little finicky.

We've gotten some reports of a Blue Coat bug with connections from Chrome and Firefox to Akamai-hosted servers, which is probably what you're hitting there? Reportedly, the workaround is to disable protocol_detection for the affected domains, they have a fix ready, but not yet released.