Thanks for the report! This means something on your network or machine (firewall, antivirus, proxy, etc.) has a bug that's conflicting deployment of TLS 1.3, the next version of TLS. A couple requests to help us diagnose this:

1. Could you attach a NetLog to the bug of the error? See this link for instructions.
https://dev.chromium.org/for-testers/providing-network-details

2. Is this your home network or a work one? Do you have an antivirus installed? If so, which? Do you know of any other firewall or proxy that you might be behind?

Thanks!

Hello,

I can reproduce this behavior as well on https://inbox.google.com/, https://gmail.com/, https://mail.google.com/, and https://www.apkmirror.com/, to name a few.

Browser and system info:

Google Chrome	60.0.3112.24 (Official Build) beta (64-bit)

Revision	16a564bd7c034b8f6e008d0887fc46c7aae48488-refs/branch-heads/3112@{#242}

OS	Mac OS X (10.13 Beta)

JavaScript	V8 6.0.286.11

Flash	26.0.0.126 /Users/4cm4k1/Library/Application Support/Google/Chrome/PepperFlash/26.0.0.126/PepperFlashPlayer.plugin

User Agent	Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.24 Safari/537.36

Command Line	/Applications/Google Chrome.app/Contents/MacOS/Google Chrome -psn_0_364633 --flag-switches-begin --enable-google-branded-context-menu --enable-md-feedback --enable-md-policy-page --secondary-ui-md --enable-features=MaterialDesignBookmarks,MaterialDesignExtensions,MediaRemoting,NewOmniboxAnswerTypes,NoStatePrefetch,OmniboxEntitySuggestions,SpeculativeResourcePrefetching,ZeroSuggestRedirectToChrome,password-import-export --disable-features=MaterialDesignSettings --flag-switches-end

Executable Path	/Applications/Google Chrome.app/Contents/MacOS/Google Chrome

Profile Path	/Users/4cm4k1/Library/Application Support/Google/Chrome/Default

I have also attached a NetLog dump that I recorded. Thanks!

Deleted: ssl.json 2.0 MB

ssl.json 2.0 MB View Download

This is my work computer. I don't know all the details of our network hardware/software.

I tried to make a NetLog but the problem mysteriously cleared up. I've been experiencing it intermittently for at least a week though, so the next time it happens I'll try again. 

This is due to an experiment deploying a newer and more secure version of TLS. Unfortunately some Firewall/Anti-virus products have had issues with the protocol in the past. Restarting probably caused you to fall off the experiment group.

If you're able to figure out what firewall/AV product is used, we can let you know whether its one that has already been fixed (many just require an update to a newer version), or if its another company that we need to reach out to so they can fix their product.

Please do give us the firewall/AV information whether or not it comes back. You get re-rolled into different experiment groups on browser restart.

You may be able to more reliably reproduce by disabling "Experimental QUIC protocol" and setting "Maximum TLS version enabled." to TLS 1.3 in chrome://flags.

The issue has come back (this is without enabling the flags you mentioned.)

NetLog attached. I'll see if I can find out about the firewall.

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

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

Also, my workstation antivirus is Windows Defender.

Are you behind a Watchguard product, by any chance? That net-internals log looks like a bug we've seen on their end before.

Update: Watchguard M300. We use deep packet inspection and unbundle ssl at the router and re bundle. Hope this helps.

I just checked with the person who set up my workplace's LAN. They're using Watchguard as well.

Alright, let's use this bug as the tracking bug for Watchguard. We'd previously gotten in touch with them but they did not gave any timeline for fixing this issue. Watchguard misunderstood how the TLS protocol is intended to evolve and effectively whitelisted the parameters that are known at the time. We've pinged them again.

As a workaround, if you have content inspection disabled, you should also disable the "Allow only SSL compliant traffic" setting.
http://www.watchguard.com/help/docs/fireware/11/en-US/Content/en-US/proxies/https/https_general_settings_c.html

 Issue 733373  has been merged into this issue.

 Issue 733379  has been merged into this issue.

I believe that all feedback being waited for has been received, so removing Needs-Feedback.  Also changing state to Assigned, since the bug has an owner. 
 Steven/David, please correct me if either of those changes was in error.

The following revision refers to this bug:
  https://boringssl.googlesource.com/boringssl/+/5aaaa98f8c32071d20f6e2538881c364b87b81c2

commit 5aaaa98f8c32071d20f6e2538881c364b87b81c2
Author: David Benjamin <davidben@google.com>
Date: Thu Jun 22 19:49:23 2017

Detect WatchGuard's TLS 1.3 interference failure mode.

WatchGuard's bug is very distinctive. Report a dedicated error code out
of BoringSSL so we can better track this.

Bug:  chromium:733223 
Change-Id: Ia42abd8654e7987b1d43c63a4f454f35f6aa873b
Reviewed-on: https://boringssl-review.googlesource.com/17328
Commit-Queue: Adam Langley <agl@google.com>
Reviewed-by: Adam Langley <agl@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>

[modify] https://crrev.com/5aaaa98f8c32071d20f6e2538881c364b87b81c2/ssl/test/runner/runner.go
[modify] https://crrev.com/5aaaa98f8c32071d20f6e2538881c364b87b81c2/ssl/s3_pkt.c
[modify] https://crrev.com/5aaaa98f8c32071d20f6e2538881c364b87b81c2/crypto/err/ssl.errordata
[modify] https://crrev.com/5aaaa98f8c32071d20f6e2538881c364b87b81c2/include/openssl/ssl.h

 Issue 736349  has been merged into this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e34d74248235b57ce7c4a9ba05956f5f3f12d8c3

commit e34d74248235b57ce7c4a9ba05956f5f3f12d8c3
Author: David Benjamin <davidben@chromium.org>
Date: Thu Jun 29 20:35:16 2017

Histogram TLS 1.3 interference causes and fix TLS13 experiment set.

This histograms a number of TLS 1.3 interference failure modes known to
be associated with buggy middleboxes. These metrics are gathered to
classify the causes of TLS version interference and better understand
the situation. Since each individual report, particularly against closed
or reset connections, is indistinguishable from transient network
failures, only gather metrics for the TLS 1.3 experiment set of servers.
The noise will still be there, but we won't be contending with noise
from connections to TLS 1.2 servers.

Also fix the TLS 1.3 experiment set. The original list diverged slightly
from what was deployed.

Bug: 694593,  676969 ,  733223 , 658863
Change-Id: I9e78804a4c62318edd8b6fbb170b03afacd86e86
Reviewed-on: https://chromium-review.googlesource.com/550279
Commit-Queue: David Benjamin <davidben@chromium.org>
Reviewed-by: Steven Valdez <svaldez@chromium.org>
Reviewed-by: Alexei Svitkine <asvitkine@chromium.org>
Cr-Commit-Position: refs/heads/master@{#483473}
[modify] https://crrev.com/e34d74248235b57ce7c4a9ba05956f5f3f12d8c3/net/socket/ssl_client_socket.cc
[modify] https://crrev.com/e34d74248235b57ce7c4a9ba05956f5f3f12d8c3/net/socket/ssl_client_socket.h
[modify] https://crrev.com/e34d74248235b57ce7c4a9ba05956f5f3f12d8c3/net/socket/ssl_client_socket_impl.cc
[modify] https://crrev.com/e34d74248235b57ce7c4a9ba05956f5f3f12d8c3/net/socket/ssl_client_socket_impl.h
[modify] https://crrev.com/e34d74248235b57ce7c4a9ba05956f5f3f12d8c3/net/socket/ssl_client_socket_pool.cc
[modify] https://crrev.com/e34d74248235b57ce7c4a9ba05956f5f3f12d8c3/net/socket/ssl_client_socket_pool.h
[modify] https://crrev.com/e34d74248235b57ce7c4a9ba05956f5f3f12d8c3/tools/metrics/histograms/enums.xml
[modify] https://crrev.com/e34d74248235b57ce7c4a9ba05956f5f3f12d8c3/tools/metrics/histograms/histograms.xml

WatchGuard have a Knowledge Base article describing the issue with a workaround on their end:
https://watchguardsupport.secure.force.com/publicKB?type=KBKnownIssues&SFDCID=kA42A000000HASBSA4&lang=en_US

 Issue 734545  has been merged into this issue.

merge 764652?

Is the commit deployed/released?

How do I track the refs/heads/master@{#483473} to the deployment channel (canary/dev/beta/stable)?

larrylaca818: Are you affected by one of these broken middleboxes? Could you please post more details?

Closing due to lack of feedback. TLS 1.3 has now been deployed in Chrome 65. If you are still running into issues, please feel free to file a new bug, but also contact Watchguard support to resolve any remaining protocol compliance issues in their TLS implementation.