Server Name Indication

Server Name Indication is a feature that improves the SSL and TLS protocol. It permits the client to request the domain name, before the certificate is committed to by the server. This is essential for using TLS in virtual hosting mode.

TLS background

One of the most common methods of encrypting a stream-oriented communication session is the Transport Layer Security (TLS) protocol. It is used, for example, when a user types "https" in a browser's URL field.

In order to confirm that the site to which the user wants to connect is actually the site to which the browser connected, TLS uses a digitally-signed certificate that includes the domain name of the site. Client-side software (browsers) generally accepts the certificate as "trusted" because it is signed by a certification authority listed in its internal "root list".

In the TLS startup phase, the client software compares the user-entered domain part of the URI with the domain name found in the server's certificate (CN or subjectAltName). Should the comparison fail, the browser will warn the user that there is something wrong with the certificate of the site.

The flaw

The design of SSL v2 follows classical public key infrastructure (PKI) expectations of one server, one service, and therefore, one certificate. This meant that the server could select and send the certificate in the early stages of the startup because it knew what domain it was serving.

With virtual hosting, a common feature of HTTP servers, each server provides many domains through the same address. The server examines each request to determine which domain is being served. This information is found for example in the HTTP request headers. Unfortunately, when setting up TLS encryption, the server has already selected and sent the certificate based on the destination IP address, and thus the domain being served, before it reads the domain name in the HTTP request.

Therefore, the simple approach to secure virtual hosting results in the wrong certificate (a default) being used, which causes the browser to warn the user.

Phishing connection

In practice, this means that each HTTP server can only serve one domain per IP address and port for secured browsing. As the de facto server situation is for many domains to be served by each webserver, the result is that the remaining web servers are effectively stopped from using secure communications, leaving much of the web unsecured. Additionally, lack of secure browsing also means that the browser is unable to authenticate the server, meaning it is unable to verify that the site really belongs to the person or entity it claims to belong to. This is an important factor in phishing schemes, which seek to obtain information from users by posing as another site. With an SSL or TLS secured connection, your browser can attempt to authenticate the site based on its certificate. The phisher's site will fail to authenticate as the site it is spoofing, and your browser can alert you to the security risk. Without secure HTTP, however, there is no standard way to authenticate the server, making such schemes much more feasible.

The fix

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. This enables the server to "switch" to the correct virtual domain early and present the browser with the certificate containing the correct CN.

Action

In 2005, it was realised that there was no easy upgrade path from SSL v2 to TLS, and the websites had to upgrade their software. To push them along, Mozilla signalled the complete dropping of support for SSL v2. The Firefox community convinced the remaining 2000Template:Which? sites to upgrade their servers to SSL v3 or TLS v1.

Since 2005, CAcert has run experiments on different methods of using TLS on virtual servers. Most of the experiments are unsatisfactory and impractical. For example, it is possible to use subjectAltName to contain multiple domains in a single certificate, but as this is one certificate, this means all the domains must be owned and controlled by one person, and the certificate has to be re-issued every time the list of domains changes.

In 2004, a patch for TLS/SNI into OpenSSL was created by the EdelKey project. In 2006, this patch was then ported to the development branch of OpenSSL, and in 2007, it was backported to OpenSSL 0.9.8 which is the current release version.

Support

Browsers

Browsers with support for TLS server name indication:

• Mozilla Firefox 2.0 or later
• Opera 8.0 or later (the TLS 1.1 protocol must be enabled)
• Internet Explorer 7 (Vista, not XP) or later
• Google Chrome (Vista, not XP)
• Safari Safari 3.2.1 and newer on Mac OS X 10.5.6 and Windows Vista, not XP

Servers

• Apache 2.2.12 or later using mod_ssl (or alternatively with experimental mod_gnutls)
  • See doc at [1]
• Cherokee if compiled with TLS support
• Versions of lighttpd 1.4.x and 1.5.x with patch , or 1.4.24+ without patch
• Nginx with an accompanying OpenSSL built with SNI support
• acWEB with OpenSSL 0.9.8j and later (on Windows)

Libraries

• Mozilla NSS 3.11.1 client side only
• OpenSSL
  • 0.9.8f (released 11 Oct 2007) - not compiled in by default, can be compiled in with config option '--enable-tlsext'.
  • 0.9.8j (released 07 Jan 2009) - now compiled in by default
  • Unreleased 0.9.9 is likely to include SNI compiled in by default.
• GNU TLS

Unsupported operating systems, browsers and libraries

The following combinations do not support SNI:

Client-side

• Windows XP and Internet Explorer, Google Chrome, or Apple's Safari browsers
• Konqueror/KDE in any version

Server-side

• Microsoft Internet Information Server IIS (As of 2009).

Libraries

• Qt Client Side
• Mozilla NSS server side
• Python

External links

• "SNI :: Why not". http://www.sigil.us/?p=60. 
• RFC4366 (obsoletes RFC3546)