Server Name Indication

From Wikipedia, the free encyclopedia

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.

Contents 1 TLS Background 2 The Flaw 2.1 Phishing Connection 3 The Fix 4 Action 5 Support 5.1 Browsers 5.2 Servers 5.3 Libraries 5.4 Unsupported Operating Systems and Browsers 5.4.1 Client-side 5.4.2 Server-side 6 References 7 External links

[edit] 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.

[edit] The Flaw

The design of SSL v2 follows classical public key infrastructure (PKI) expectations of one server, one service. Therefore, one certificate. This meant that the server could send, or commit to 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 committed the certificate, 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.

[edit] Phishing Connection

In practice, this means that each HTTP server can only serve one domain 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.

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

[edit] 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.^[2] The Firefox community convinced the remaining 2000 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.^[3] 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.^[4] 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.

[edit] Support

[edit] Browsers

Browsers with support for TLS server name indication:^[5]

• 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 3.2.1 Mac OS X 10.5.6

[edit] Servers

• Apache 2.2.12 or later using mod_ssl^[6][7][8] (or alternatively with experimental mod_gnutls^[9])
  • See doco at [1]
• Cherokee if compiled with TLS support
• New versions of lighttpd 1.4.x and 1.5.x ^[10]
• Nginx with an accompanying OpenSSL built with SNI support

[edit] Libraries

• Mozilla NSS
• 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

[edit] Unsupported Operating Systems and Browsers

The following combinations do not support SNI.

[edit] Client-side

• Windows XP and Internet Explorer
• Konqueror/KDE in any version

[edit] Server-side

• Microsoft Internet Information Server IIS (As of 2007^[update]).

[edit] References

[edit] External links

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

This article has not been added to any categories. Please help out by adding categories to it so that it can be listed with similar articles. (May 2009)