iOS bug : https://bugs.chromium.org/p/chromium/issues/detail?id=602673

jainabhishek: First, some notes for the future ConOps triage here:

It's unlikely that the issues with facebook.com, accounts.google.com, and www.amazon.com are the same as the cited URL. For each of those, please file *separate* bug reports and ask the users for net-internals per https://dev.chromium.org/for-testers/providing-network-details. Please leave deduplicating network issues to us and assume that errors are distinct unless there is information otherwise.

Likewise, the iOS bug is all but guaranteed to be unrelated. Chrome for iOS uses a completely different net stack.


I'm going to use this bug for https://edx.standardandpoors.com/mailbox since I can reproduce this one. At a glance, apparently we can't parse some server extension? I don't recall tightening something, but perhaps we messed something up. I will look into it tomorrow. Thanks for fishing that out!

Can you please link to the original report for edx.standardandpoors.com? Does it say this was a recent regression? I don't think this changed recently.

The server is misbehaving and sending a server_name extension of 0000 rather than empty, per the spec:

   A server that receives a client hello containing the "server_name"
   extension MAY use the information contained in the extension to guide
   its selection of an appropriate certificate to return to the client,
   and/or other aspects of security policy.  In this event, the server
   SHALL include an extension of type "server_name" in the (extended)
   server hello.  The "extension_data" field of this extension SHALL be
   empty.

Strangely, when talking to Firefox, it doesn't send a server_name extension at all. I'll have to poke at this server some more. We'll certainly need to report a bug in the server software, but why it's only sending the extension some of the time is odd. (Though NSS also ignores the contents of the extension.)

Ah, no, I think the empty extension with Firefox is just because of resumption. It's just that whatever software this is running got the spec wrong. We can certainly not bother parsing the contents if we need to, though we've had this behavior since Chrome 46, and this is the first I've heard of a server messing this one up. At minimum, we'll want to find out what software this is.

Using Chromium 49.0.2623.110 on Windows.
I get a 404 error when trying to access that domain (even in HTTP mode) so it may be a server/domain issue rather than one for Chromium.

No issues with accessing FaceBook/Amazon/Google sites.

totallyfresh01: Nah, a 404 is unrelated. Although it is an issue with the server. What's going on with it is already known. See existing comments. (Any issues, or lack thereof, with Facebook/Amazon/Google sites are unrelated. The reports from ConOps were mis-triaged.)

jainabhishek: Can you link to the original report for edx.standardandpoors.com as davidben requested? Thanks!

I tried to repro issue but site opens perfectly now.
I can no longer replicate this issue anymore.

Closing this bug. Will raise another in case we have better logs next time.