Could you please provide a net-internals log of this happening?  Instructions: https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details

Attached is the log. Thanks for taking a look!

Deleted: net-internals-log.json 267 KB

net-internals-log.json 267 KB View Download

Looks like an SSL handshake error. Over to the SSL component.

Looks like our ClientHello is getting rejected about 300-400ms later for some reason. That's long enough that I'm guessing the middlebox is unhappy at the server response, rather than the ClientHello. Does this happen with non-Google HTTPS sites, or just Google ones? Since this is a cafe and I gather doesn't happen at home, that suggests this is not an SSL-terminating MITM.

Supposing it is just Google sites, that suggests the middlebox is unhappy about something non-Google servers, Safari, and cURL don't implement. That could be:
- TLS 1.3 (We had to back that out temporarily, so probably not. Also that ClientHello is a bit on the small side for TLS 1.3.)
- Channel ID extension
- CHACHA20_POLY1305 ciphers
- Extended Master Secret
- X25519
- RSA-PSS signature algorithms

Does it work in Firefox? Some of these options also exist in Firefox, so that would help narrow things down a bit.


I'm actually on the east coast, so +nharper, do you feel like taking a field trip? :-)

(Though I see CapitalOne Cafe also has a Cambridge location and they're even open late. I suppose I could also take a field trip, supposing they have a similar network in all their locations...)

Okay, I'm in one of their Cambridge locations and it seems fine. Perhaps their SFO location has a different network setup?

Could you provide a hexdump or pcap of the ClientHello sent by Chrome? (Or a net-internals dump with a byte-level capture enabled.)

Which SSID were you connected to - CapitalOneCafe or 360-Cafe?

When connected to the 360-Cafe wifi network, I was able to reproduce issues with Chrome 57.0.2987.110 (on macOS 10.12.3).

When connecting (from Chrome or boringssl) to google from another network, the cipher suite negotiated is ECDHE-ECDSA-AES128-GCM-SHA256. From the 360-Cafe network, if I disable that cipher suite before connecting to google, the server chooses a chacha20 cipher suite, and the connection works fine. With that cipher suite enabled (which it is by default), my client never receives a ServerHello.

I discovered some interesting behavior when I spun up another server to test against (running "./bssl server -accept 443 -max-version tls1.2" as the server command): when I connect to it on the 360-Cafe network (using "bssl client -connect tls13.nharper.org:443 -server-name localhost -grease -ocsp-stapling -max-version tls1.2 -alpn-protos h2,http/1.1") I get a self-signed cert that did not come from my test server. The subject/issuer is C = "  ", ST = Some-State, O = Blue Coat SG300 Series, OU = 1911162020. (If I run the same thing, but on port 3000 instead of 443, the client connects to my test server directly with the expected cipher suite of ECDHE-ECDSA-AES128-GCM-SHA256.)

I don't know if this is a bug in the particular Blue Coat SG300 appliance that is in use, or if it is an issue with the configuration of said device.

This isn't an issue with Chrome - it is either an issue with the software on that Blue Coat device or with the configuration of said device.