Handling TLS negotiation for name based virtual hosting using SNI

Kalpana dwivedi,Assistant professor,ABESEC

Abstract

Virtualization or virtual hosting is an approach to host multiple domains on single server or pool of servers. This helps to share the resources among services hosted by different domain. This also allows to use same IP address by all domains hosted on same server and therefore avoiding the need of having separate IP for all domains. multiple web applications are hosted on single server using virtual hosting concept. It becomes less expensive as compare to having dedicated server to host individual web applications.

Virtual hosting can either be achieved by IP based hosting or name-based hosting. name based hosting saves the IP addresses. in name-based hosting the client is require presenting the hostname. name based hosting saves cost but brings a challenge when hosted domain are to be accessed using HTTPS protocol. HTTPS is an extension to HTTP and used for secure communication over network. when a web resources is accessed over HTTPS, handshaking takes places between server and client using SSL (also called as TLS) protocol, it means communication protocol HTTP is encrypted with TLS (Transport Layer Security) previously known as SSL (Secure Socket Layer) and therefore also been referred as HTTP over SSL or HTTP over TLS.

Objective behind evolution of HTTPS was to ascertain the authenticity of the server client is connecting to, ensure the privacy and integrity of the data transmitted over network. encryption of communication could be either unidirectional or bidirectional.

When making TLS/SSL connection client request the server the certificate. server send the digital certificate to client. client examines and compares the name(s) available in the certificate with the name it is trying to connect to. If match is not found, then user may be warned of discrepancy in connection which could have occurred probably due to man in the middle attack.

However, some applications allow user to ignore the warning and proceed with the connection but JVM in server to server communication does not allow to proceed with connection until TLS handshaking is successful.

As we saw that match of the name in certificate with the name client is trying to connect to is required for successful TLS connection. server is registered in the certificate and certificate used to be installed on server. when requested, server presents the certificate installed. likewise, other servers would have their own certificates installed in their setup.

Assigning a separate IP address for each site increases the cost of hosting, since requests for IP addresses must be justified to the regional registry and IPv4 addresses are now exhausted and therefore situation gets complicated when, through virtual hosting, more than one server are hosted on same IP or group of IPs sharing the infrastructure. In this situation when certificate is requested server could not identify which certificate to be returned to client.

This issue does not arise when communication happens over HTTP because from HTTP header, server can extract the hostname client is trying to access. The TLS handshake happens before the server sees any HTTP headers. Therefore, it is not possible for the server to use the information in the HTTP host header to decide which certificate to present and as such only names covered by the same certificate can be served from the same IP address.

Server Name Indication or SNI fixes this issue. SNI addresses this issue by having client to send the virtual hostname during TLS negotiation. This enables the server to choose appropriate certificate and return to client.

Security implications with SNI

Though SNI addresses the issue by resolving hostname during TLS handshaking yet there are some security implications associated with it. Desired hostname suppl