The `ssldump` log will look something like the following.  Note that Firefox does not have the pointless "#5" connection, and goes straight to the real connection.  As such, Firefox is much faster (up to 2x faster) than Chrome for loading HTTPS urls when latency is the primary concern.

New TCP connection #5: [...](58281) <-> [...](11000)
5 1  0.0006 (0.0006)  C>S  Handshake      ClientHello
5 2  0.0008 (0.0002)  S>C  Handshake      ServerHello
5 3  0.0008 (0.0000)  S>C  ChangeCipherSpec
5 4  0.0008 (0.0000)  S>C  Handshake
5 5  0.0012 (0.0003)  C>S  ChangeCipherSpec
5 6  0.0012 (0.0000)  C>S  Handshake
5    0.0013 (0.0001)  C>S  TCP FIN
New TCP connection #6: [...](58282) <-> [...](11000)
6 1  0.0037 (0.0037)  C>S  Handshake      ClientHello
5    1.0029 (1.0015)  S>C  TCP FIN
6 2  0.9975 (0.9937)  S>C  Handshake      ServerHello
6 3  0.9975 (0.0000)  S>C  ChangeCipherSpec
6 4  0.9975 (0.0000)  S>C  Handshake
6 5  0.9980 (0.0004)  C>S  ChangeCipherSpec
6 6  0.9980 (0.0000)  C>S  Handshake
6 7  0.9985 (0.0004)  C>S  application_data
6 8  0.9990 (0.0005)  S>C  application_data
6 9  0.9992 (0.0001)  S>C  application_data
6 10 0.9992 (0.0000)  S>C  application_data
6 11 0.9992 (0.0000)  S>C  application_data
6 12 0.9992 (0.0000)  S>C  application_data
6 13 0.9992 (0.0000)  S>C  application_data
6 14 0.9993 (0.0000)  S>C  application_data
6    0.9993 (0.0000)  S>C  TCP FIN
6    1.0005 (0.0011)  C>S  TCP FIN

I found an old comment https://bugs.chromium.org/p/chromium/issues/detail?id=39402#c12 indicating that maybe this bug is due to the "Predict network actions to improve page load performance" setting. However that setting has apparently been renamed or deleted since that comment was made.  The ticket this bug was mentioned in was about an unrelated bug, so the HTTPS socket bug apparently fell through the cracks.

http://stackoverflow.com/a/5734486 also seems to reference this bug. The first comment is 2011, and there are updated comments in 2015. This also seems to indicate the bug is not a regression, but is rather old.

Can you provide a chrome://net-internals log as described at https://dev.chromium.org/for-testers/providing-network-details

Thank you

That contains a lot of information that I'm reluctant to post publicly. It does show 2 back-to-back connections though, where the first shows no HTTP, and the second has a '"type": 143' section where the HTTP request is shown. The "source_address" shows the port from the pointless connection and the port from the real connection are as expected.

If you're not able to reproduce the bug, please provide some private google/Chrome method for posting that file.

You can send it to my email (rsleevi@chromium.org)

Could this be the predictor?
https://cs.chromium.org/chromium/src/chrome/browser/net/predictor.cc?rcl=1465485429&l=935

That will be turned on if the setting "Use a prediction service to load pages more quickly" is enabled.

"Use a prediction service to load pages more quickly" is disabled already in the above logs.

It's not preconnect, it's the SSL error handling, which is WAI.

In this case, it makes a connection, sees that the certificate is invalid, aborts the socket and signals to the higher layer there was an error, and then the higher layer is choosing to ignore the error, causing a reconnect.

The difference in behaviour is that Firefox keeps the initial socket open while presenting the UI and attempts to resume the original handshake ignoring the error, and then, if that fails, establishes a new socket and ignores the error.

It's an intentional design decision we've made not to do what Firefox does. That path lies a whole different set of edge cases and code complexity (many servers have TLS handshake timers, so if the user doesn't respond to the UI in a timely manner, they'll shut down the socket, which then requires all sorts of heuristics to determine if the socket was shut down for taking too long or shut down because of error).

You're saying this bug only occurs with certificates that have been marked trusted in Chrome, but lack a root-trust chain?

You can see in the NetLog events that the first request is aborted because the certificate authority is invalid. This is then surfaced to the URLRequest, which restarts the request (saying "Ignore this error X"), and the second connection is made.

So yes, this only appears with certificate errors.