4

I set up Apache2 with SSL and tried to request the default Apache2 web page ("It works!") using https://[IP_ADDRESS].

The Chrome developer tool shows that only one HTTP connection is established, however, from Wireshark's captured packets, there are three separate TCP streams.

The first two TCP stream finish the SSL routine, however without any application data exchanged. The last TCP stream has application data exchanged. Even more curiously, those TCP connections establish concurrently, not one by one.

The question is: Why are three separate SSL connections needed here?

Xander
  • 35,525
  • 27
  • 113
  • 141
PC Yin
  • 43
  • 1
  • 4

3 Answers3

2

When you connect to an HTTPS Web site which uses a "problematic certificate" (e.g. one which is not issued by a recognized CA, an expired certificate, or a certificate which does not contain the server name as it appears in the URL), the browser asks for confirmation from the user. This can happen only after the server certificate has been retrieved, as part of a SSL handshake. This accounts for at least one initial connection with handshake.

Keeping a SSL connection open uses up some resources on the server; so servers auto-close connections after some inactivity, and browsers try not to keep connections open for too long. Displaying the warning about the invalid certificate implies waiting for the human user to come to a decision (to click or not to click, that is the question). This will take some time; humans are slow. Therefore, the browser will first close its initial SSL connection, the one it used to obtain the server certificate -- not HTTP has occurred yet, though, only the SSL handshake. When the human user finally decides to connect despite the scary warning, the browser will open a new connection, with a new SSL handshake, and in that one there will be some HTTP (as "application data").

As for the other connection (the "initial connection" is actually two connections made in parallel): Chrome is known to open speculative connections so as to speed up subsequent requests; in general, a Web page includes images which will have to be downloaded promptly. Chrome appears to be overzealous at times. The plausible scenario is then:

  1. Chrome opens two connections with SSL handshakes.
  2. Chrome notices that the certificate is flaky, and requires human intervention. It closes the two connections without doing any HTTP within the SSL tunnels.
  3. When the user decides to open the page, Chrome opens a third connection, does a SSL handshake, and this time follows on with the HTTP dialog.
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
0

The first one is grabbing the certificate itself, the second is making a secure handshake, and the last is getting the actual data.

Eric Zhang
  • 117
  • 3
  • 1
    why not doing all this in a single connection? – PC Yin May 13 '13 at 15:34
  • 1
    Your browser has to check the certificate to make sure it's valid before allowing data to be transferred. – Eric Zhang May 13 '13 at 16:25
  • 3
    That's not three separate connections - the SSL handshake includes all three steps in a single connection. – bethlakshmi May 13 '13 at 20:29
  • Yeah, I had assumed that there would be only one connection, but the fact is that three separate connections are established. Is there any reference? – PC Yin May 14 '13 at 05:58
0

The "Predict network actions to improve page load performance" setting in Chrome has been known to create additional (initially idle) connections to the server as reported here:

https://code.google.com/p/chromium/issues/detail?id=116982

wj.
  • 23
  • 4