Why we need to use IPs more judiciously?

While thinking or arguing about depletion of IPv4 addresses and how to use them more efficiently get a little bit complex when you see an approach of the Internet community which is aggressively pursuing a massive convergence of secure communication over IP. There is no doubt switching to IPv6 is inevitable, as the technical and economic consequences for the growth of the Internet are potentially important.

The idea of rapid adoption of IPv6 to replace and save IPv4 stock led by the major players on the Net, Google, Facebook and Yahoo are some of the names, an initiative of “World IPv6 Day” also led by these giants to sensitize stakeholders and operators around the world to accelerate the inevitable transition to IPv6. Just remember that it is urgent that CIOs anticipate with the help of their suppliers, a shortage situation. Though IPv6 will provide access to an almost infinite numbers, but just imagine if IPv6 also gets exhausted, then what will you do?

Prevention is better than the cure!

So how to stop the wastage of IP addresses? Now, it’s a time to jump in to our main subject “using multiple SSL on the same IP with SNI”, which contributes its part to save IPv4 and probably will avoid the future shortage scenario as well.

When the going gets tough, the tough get going!

Having separate SSL certificates for each website traditionally required the separate dedicated IP addresses. But now the process has been streamlined through the use of SNI (i.e. Server Name Indication) that drives a website visitor the certificate which matches the requested server name. To be safe, better just order a dedicated IP is no longer a case due to the SNI support.

So how exactly SNI works to setup multiple SSL on different sites with a single IP address? Here is the answer!

1. The HTTPS headers aren’t available to the server during SSL handshake when the client sends a HTTPs request. Once the process gets completed the client will able to encrypt the headers and can send the encrypted HTTP request to the server. As a result, until the request isn’t encrypted the server cannot access the HTTP headers or content. Hence, the problem smiles at our face :).

2. The IP address and the Port number is the only info available to the server in advance to decrypt the request. And this is open through the TCP headers as only the HTTP headers are encrypted. But this is a limitation as only a single certificate can be guaranteed to the combination of <IPAddress> :< Port >.

3. To address this limitation, SNI comes in the picture – the client sends the name of the virtual domain as of the TLS negotiation. This enables the server to select the exact virtual domain promptly and present the browser with the certificate containing the correct name. Hence, with clients and servers that implement SNI, a server with a single IP address can serve a group of domain name for which it is impractical to get a common certificate.

Legacy

Here is the process of SSL handshake between client and IIS 7.x and in the earlier version:

1. Through TCP handshake the client and the server starts a TCP connection, then the client sends a “Client Hello” to the server. Again, IP address and the Port number is the only available info to the server from Client Hello. As a part of the Client Hello the client sends a particular version of protocol and the supported cipher suites list.

2. To find a certificate the sever check hash/thumbprint matching to the combination of IP: Port. The server then checks the following key to find the combination:

HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\SslBindingInfo

3. Once it discovers a match key, the crypto API’s called to retrieve the server certificate based on the thumbprint from certificate store. This is then incorporated to the server Hello and sent to the client.

4. Yet again, the HTTP headers aren’t sent until the handshake is complete, as a result the server never knows which site or application the request relates to till the handshake completes.

So how SSL handshake process functions amid an SNI compliant browser and SNI compliant server?

1. To understand the process functionality we are taking IIS 8 here rather an earlier version, as SSL binding is configured in this version to use SNI.

2. Here also Client Hello sent by the client to the server, but the packet includes the particular version of protocol and the list of supported cipher suites together with the hostname. The packet includes TCP/IP headers also contains Port number and IP address.

3. To find a certificate hash/thumbprint matching to the combination of <IP> : <Port>, server checks the registry (legacy bindings).

4. If a server doesn’t find legacy binding for the specific IP: Port, then it uses the available information of Client Hello and check the registry to search a certificate hash/thumbprint matching to the combination of <hostname> : <port>. To find the combination, server check for the following key:

 HKLM\SYSTEM\CurrentControlSet\Services\HTTP\Parameters\SslSniBindingInfo

5. In case of the failure of above step, then the server may use the IP address available to search a legacy SSL binding for that IP and Port. And if this is even absent then the SSL handshake would fail.

6. And if the server discovers a match key, the crypto API’s called to retrieve the server certificate based on the thumbprint/certificate hash from the certificate store. The retrieved certificate is then added to Server Hell and sent to the client.

Note: The SNI is supported in cPanel/WHM from 11.38 and above versions.
CloudLinux and RHEL 6 also support SNI.

Conclusion

It’s not only important to consider this privilege as a service provider, but it is equally essential for you because many Hosting Companies don’t even accept SSL as a valid justification for a dedicated IP request, if they supports SNI. It saves the cost and save the wastage of IP addresses.