Issue metadata
Sign in to add a comment
|
Chrome opening Two TCP Connections when Self-Signed Certificate is Presented
Reported by
utkarsh....@gmail.com,
Jun 29 2016
|
||||||||||||||||||||||
Issue description
Chrome Version : 51.0.2704.84
URLs (if applicable) : An https URL with self-signed certificate.
Other browsers tested:
Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
Safari: Version 9.1.1 (11601.6.17) OK
Firefox: Version 47.0.1 OK
IE: N/A (Tested on OSX only)
What steps will reproduce the problem?
(1) Setup a virtual host with a self-signed certificate on Apache Web server. The virtual host should be HTTP/2 enabled, otherwise if the virtual host is HTTP/1.1 enabled, Chrome will open 6 TCP connections. Therefore, to reproduce the bug, open an HTTP/2 enabled URL.
(2) Open Chrome browser and load the URL pertaining to the virtual host created in Step 1.
(3) Add security exception in Chrome due to self-signed certificate.
(4) Run wireshark to capture TCP SYN packets and to notice the TCP handshake happening two times.
(5) Repeat step 2, after completely closing the browser. At this point, when opening the URL the second time, Chrome should not ask for security exception and should take you directly to the requested webpage.
What is the expected result?
One should expect the browser to establish only one TCP connection with the server.
What happens instead?
The browser opens the first TCP connection and identifies that the certificate presented is invalid (or self-signed). Instead of reusing the same connection (given that the user has already added an exception), Chrome establishes another TCP connection. Next, only second TCP connection is used for exchanging payloads between the client and the server.
Please provide any additional information below. Attach a screenshot if
possible.
Screenshot of TCPDump is attached.
,
Jun 29 2016
This is expected and is how we implement the click-throughs. The extra connection when the user first clicks through I don't expect will ever go away. We have to handle the case where the user takes too long to make a decision, so it's simpler to always start anew. I'm going to merge it into issue #423251 because we are a little bit wasteful about it in places, which would require non-trivial reworking of how the click-throughs are implemented. Ultimately, however, this is not a use case that is really worth optimizing. If a site is intended to be accessed publicly, it should deploy a real publicly trusted certificate. If a site does not need to be accessed publicly and is used for testing, the correct answer is to configure a locally-trusted root.
,
Jun 29 2016
Hi David, Thanks for looking into this. Just a quick note. I observed Chrome opening two connections even when the user has already added a security exception in the past. In such a case, there is no waiting for user click through and the browser takes the user directly to the requested webpage. Is two TCP connections also expected by Chrome in this case? If so, I am curious to learn the reason. Thanks Utkarsh
,
Jun 29 2016
Yes, the case when the user has already clicked through is what I'm referring to as a bit wasteful. That one is worth keeping open as something to fix, so I've merged it to the other bug. The initial one I don't think foresee ever changing. But, again, I don't see this as very high priority to fix and will probably only happen along the way to other changes. (Notably there's other problems with the click-through logic relating to the socket pools that do need to get fixed at some point. I expect that one consequence of fixing that will be to also fix this issue. Though no one is currently working on that either.) Ultimately, any site that requires used clicking through that prompt is misconfigured. The historical legacy of browsers before us means we must have such a prompt, but as only misconfigured sites will ever see it, it's not very high priority to make it work particularly well. I recommend fixing your site to not need this. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by eroman@chromium.org
, Jun 29 2016Labels: Needs-Feedback