Server Name Indication

From Server Knowledge Base
Revision as of 22:07, 5 February 2013 by Rootadminacc (talk | contribs) (Created page with "Server Name Indication (RFC 6066; obsoleted RFC 4366, RFC 3546) is an extension to Transport Layer Security which allows the client to tell the server the name of the host it ...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search

Server Name Indication (RFC 6066; obsoleted RFC 4366, RFC 3546) is an extension to Transport Layer Security which allows the client to tell the server the name of the host it is trying to reach.

SNI is compatible with TLS 1.0 and higher according to spec, but implementations may vary (see below). It cannot be used with SSL, so a connection must negotiate TLS (see RFC 4346 appendix E) for SNI to be used. This generally happens automatically with supported software.

Why is SNI needed?

In a normal HTTP connection, the browser informs the server of the hostname of the server it is trying to reach using the Host: header. This allows for a web server on a single IP address to serve content for multiple hostnames, which is commonly known as name-based virtual hosting.

The alternative is to assign unique IP addresses for each web hostname to be served. This was commonly done in the very early days of the web, before it was widely known that IP addresses would run out and conservation measures began, and is still done this way for SSL virtual hosts (not using SNI).

Because this method of transmitting the host name requires the connection to be already established, it does not work with SSL/TLS connections. By the time the secure connection is set up, the web server must already know which hostname it is going to serve to the client, because the web server itself is setting up the secure connection.

SNI solves this problem by having the client transmit the hostname as part of the TLS negotiation, so that the server is already aware of which virtual host should be used to service the connection. The server can then use the certificate and configuration for the correct virtual host.

Why not use different IP addresses?

The HTTP Host: header was defined to allow more than one Web host to be served from a single IP address due to the shortage of IPv4 addresses, recognized as a problem as early as the mid-1990s. In shared web hosting environments, hundreds of unique, unrelated Web sites can be served using a single IP address this way, conserving address space.

Shared hosting environments then found that the largest consumer of IP address space was the need for secure web sites to have unique IP addresses, creating the need for SNI as a stop-gap measure on the way to IPv6. Today it is sometimes difficult to obtain as few as 5 IP addresses (/29) without significant justification, often resulting in deployment delays.

With the advent of IPv6, such address conservation techniques are no longer necessary, since a single host can have more IPv6 addresses assigned to it than the entire Internet contains today, but the techniques will probably still be used far into the future to service legacy IPv4 connections.

Caveats

Some operating system/browser combinations do not support SNI (see below), so using SNI is not appropriate for all situations. Sites targeting such system/browser combinations would have to forgo SNI and continue to use unique IP addresses for each virtual host.

Of particular note, no version of Internet Explorer on Windows XP supports SNI. As this combination still represents a significant (but steadily decreasing; about 16% of Internet traffic in December 2012 according to NetMarketShare) portion of Internet traffic, SNI would be inappropriate for a site targeting these user populations.

Support

Many, but not all, commonly used software packages support SNI.

(Omission from this list doesn't necessarily mean lack of support; it means there was a limit to how much I could type, or I couldn't quickly find the information in a search. If your software package isn't listed, searching for its name plus sni should reveal if support exists and how to set it up.)

Library Support

Most packages depend on an external library to provide SSL/TLS support.

  • GNU TLS
  • JSSE (Oracle Java) 7 or higher, only as a client
  • libcurl 7.18.1 or higher
  • NSS 3.1.1 or higher
  • OpenSSL 0.9.8j or higher
  • OpenSSL 0.9.8f or higher, with configure flags
  • Qt 4.8 or higher

Server Support

Most current versions of popular server software support SNI. Setup instructions are available for most of these:

  • Apache 2.2.12 or higher
  • Apache Traffic Server 3.2.0 or higher
  • Cherokee
  • IIS 8.0 or higher
  • lighttpd 1.4.24 or higher
  • LiteSpeed 4.1 or higher
  • nginx 0.5.32 or higher

Client Support

Most current web browsers and command line user agents support SNI.

Desktop

  • Chrome 5 or higher
  • Chrome 6 or higher on Windows XP
  • Firefox 2 or higher
  • Internet Explorer 7 or higher, running on Windows Vista/Server 2008 or higher
  • Internet Explorer on Windows XP does not support SNI regardless of IE version
  • Konqueror 4.7 or higher
  • Opera 8 or higher (may require TLS 1.1 enabled to function)

Mobile

  • Android Browser on 3.0 Honeycomb or higher
  • iOS Safari on iOS 4 or higher
  • Windows Phone 7 or higher

Command Line

  • cURL 7.18.1 or higher
  • wget 1.14 or higher (Distributions may have backported a patch for SNI support)

No Support

  • BlackBerry Browser
  • Internet Explorer (any version) on Windows XP
Retrieved from "http://serverkb.co.uk/index.php?title=Server_Name_Indication&oldid=246"