Server Name Indication (SNI) is a feature that extends the SSL and TLS protocols to indicate what hostname the client is attempting to connect to at the start of the handshaking process. By doing so it allows a server to present multiple certificates on the same IP address and port number and hence allows multiple secure (HTTPS) websites to be served off the same IP address without requiring all those sites to use the same certificate.
Unfortunately to make use of SNI practical it is necessary that the vast majority of users are using web browsers that support it. Users whose browsers do not support SNI will be presented with a default certificate and hence are likely to receive certificate warnings. As of 2011 there are still many users of browsers that do not support SNI.
Contents |
When making a SSL/TLS connection the client requests a digital certificate from the server; once the server sends the certificate, the client examines it and compares the name it was trying to connect to with the name(s) included in the certificate. If a match is found the connection proceeds as normal. If a match is not found the user may be warned of the discrepancy and the connection may be aborted as the mismatch may indicate an attempted man-in-the-middle attack.
It is possible for one certificate to cover multiple names. The X.509 v3 specification introduced the so-called subjectAltName field which allows one certificate to specify more than one domain and it is possible to have wildcards in both the common name and subjectAltName fields. However it may be impractical to obtain a single certificate that covers all names a server will be responsible for. As such a server that is responsible for multiple hostnames is likely to need to present a different certificate for each name (or small group of names). Since 2005, CAcert has run experiments on different methods of using TLS on virtual servers.[1] Most of the experiments are unsatisfactory and impractical. For example, it is possible to use subjectAltName to contain multiple domains controlled by one person[2] in a single certificate. Such "unified communications certificates" are reissued every time the list of domains changes.
Name-based based virtual hosting allows multiple DNS hostnames to be hosted by a single server (usually a web server) on the same IP address. To achieve this the server uses a hostname presented by the client as part of the protocol (for HTTP the name is presented in the host header). However when using HTTPS the SSL/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.
In practice, this means that a HTTP server can only serve one domain (or small group of domains) per IP address for secured browsing. Assigning a separate IP address for each site increases the cost of hosting since requests for IP addresses must be justified to the regional internet registry and IPv4 addresses are now in short supply. The result is that many websites are effectively prevented from using secure communications.
An extension to TLS called Server Name Indication (SNI) addresses this issue by sending the name of the virtual domain as part of the TLS negotiation.[3] This enables the server to select the correct virtual domain early and present the browser with the certificate containing the correct name. Therefore with clients and servers that support SNI a single IP address can be used to serve a group of domain names for which it is impractical to get a common certificate.
In 2004, a patch for TLS/SNI into OpenSSL was created by the EdelKey project.[4] In 2006, this patch was then ported to the development branch of OpenSSL, and in 2007 it was back-ported to OpenSSL 0.9.8.
To support SNI the SSL/TLS library used by an application must support it and the application must pass the hostname to the SSL/TLS library. Further complicating matters the SSL/TLS library may be either shipped as part of the application or may be a component of the operating system. As a result of this some browsers support SNI on all operating systems while others only support it on a subset of operating systems. As of 2011 most web browsers and SSL libraries have implemented support for SNI but there are still a large number of users still using combinations of browser and operating system that do not support it.
ssl, urllib[2] and httplib modules) [19]The following combinations do not support SNI:
ssl, urllib[2] and httplib modules) [19]