18

It is my understanding that when Apache receives a request to one of the TCP ports it is listening on (e.g. 80, 443), it will decide which host is being requested by looking at the HTTP header Host. The server will then know which virtual host it should redirect the request to.

But how does it work for HTTP over SSL/TLS? Since the whole HTTP request is being encrypted (at least that's what I believe I have read somewhere), the header information can only be read after the server has decrypted the data. But in order to decrypt, it needs to know which key pair to use as you can have multiple SSL certificates installed on a web server.

So how does the server know which key it needs for decryption?

My guess:

I could imagine that the TLS handshake provides the necessary information.

Regarding the "possible duplicate" flag:

While I agree that the answers to both the linked question and my own are similar, I must say the question is different. It is out of question whether or how hosting multiple sites with independet SSL certificates is possible. Instead my question addresses the underlying technical aspect.

Community
  • 1
paolo
  • 387
  • 3
  • 14
  • Related: http://serverfault.com/questions/126072/ssl-certificate-selection-based-on-host-header-is-it-possible – Ilmari Karonen Dec 26 '16 at 14:10
  • Possible duplicate of [Multiple SSL domains on the same IP address and same port?](http://serverfault.com/questions/109800/multiple-ssl-domains-on-the-same-ip-address-and-same-port) – Bob Dec 26 '16 at 14:43
  • I agree that the *answers* are quite similar, however I believe the *questions* are quite different. – paolo Dec 26 '16 at 15:26

2 Answers2

29

Originally, the web server didn't know. This was the reason that you needed a separate IP address for every SSL vhost you wanted to host on the server. This way, the server knew that when a connection came in on IP X, he needed to use the configuration (including certificates) for the associated vhost.

This changed with Server Name Indication, a TLS extension that indeed allows a client to indicate the required hostname in the handshaking process. This extension is used in all modern OS, but old browsers or servers don't support it, so if you expect clients to still use IE 6 on WinXP, you would be out of luck.

chicks
  • 3,639
  • 10
  • 26
  • 36
Sven
  • 97,248
  • 13
  • 177
  • 225
  • 2
    If someone still uses XP, they don't deserve to visit my site anyway ;) – paolo Dec 26 '16 at 16:11
  • 2
    great care needs to be taken when limiting clients this way (browsers not people). Many, many businesses don't upgrade windows very well, and the same is tru with some android phone vendors, they usually don't upgrade their OS at all (or at least not much). Windows XP is at 8% and the pre 4.4 android market share seems huge. – coteyr Dec 26 '16 at 16:27
  • In case the server lacks SNI support it is possible to use a proxy with SNI support in front of a server without SNI support. – kasperd Dec 26 '16 at 19:42
  • 1
    @coteyr The vast majority of remaining XP users are in China. There's very little usage elsewhere, fortunately, at least on the Internet. – Michael Hampton Dec 26 '16 at 19:56
7

It seems you have some misconceptions about TLS/SSL. The HTTP request is not encrypted by server's public key. It is encrypted by a symmetric cipher using a key negotiated in previous handshake.

Brief description of TLS handshake: Server and client negotiate some ciphersuite, symmetric key(s) and some other details. In order to prevent MITM, server usually sends its certificate (chain) to the client and authenticates the handshake using the key in certificate. (There are also some other variants, e.g. client authentication or TLS-PSK, but they are not much used with HTTP.) Client can either validate the certificate (the usual way) or ignore it.

While SNI is important when using multiple TLS certificates at one IP, it is not essential for server being able to decrypt the request. Without SNI, server does not know which certificate chain should be sent, so server usually picks one (e.g. the first vhost), which could be of course a wrong one. If server picks wrong certificate chain, client should refuse it (so it does not continue with sending the HTTP request). However, if client ignores certificate (or if the invalid certificate is marked as trusted for this site), it can successfully continue. Since the symmetric key used for encryption does not depend on the certificate (TLS is designed to also work without certificates), the server can decrypt it.

Just a minor note why I am writing about TLS, while you asked about SSL: TLS is new version of SSL. All version of SSL are considered as insecure for general usage, so we are mostly using TLS (1.0, 1.1, 1.2) now.

v6ak
  • 226
  • 1
  • 5
  • "The HTTP request is not encrypted by server's public key. It is encrypted by a symmetric cipher using a key negotiated in previous handshake." Didn't know that, thanks for the heads-up! I do know, however, that TLS replaced SSL, yet we stuck with the conventional term "SSL certificate", hence my mentioning. – paolo Dec 26 '16 at 20:30
  • I know that terms like “SSL certificate” are quite often for TLS. I am trying to avoid them, but I was not sure if you (or others) know the term TLS. – v6ak Dec 26 '16 at 20:35