apache browser certificate cryptography firefox https linux neat security server sni ssl sysadmin tls virtualhosts web webbrowser

My tags:

From Wikipedia, the free encyclopedia

Server Name Indication is a feature that fixes a flaw in the SSL v2 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 host 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 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 somebody types "https" in their browser.

Web servers do not follow that assumption, and instead serve many websites. 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 host part of the URI (domain name) 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, the standard feature of HTTP servers, each server provides many hosts 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 GET 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 host as part of the TLS negotiation.^[1] This enables the server to "switch" to the correct virtual host 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 badgered 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 altSubjectName 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. The initial development by EdelKey also included a patch for Apache and curl, but as yet, no webserver is released with support for TLS/SNI.

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

[edit] Servers

• Apache with experimental mod_gnutls^[6] or mod_ssl^[7]
• Cherokee if compiled with TLS support
• New versions of lighttpd 1.4.x and 1.5.x ^[8]
• Nginx with an accompanying OpenSSL built with SNI support

[edit] Libraries

• Mozilla NSS
• OpenSSL
  • 0.9.8f - not compiled in by default, can be compiled in with config option '--enable-tlsext'.
  • 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.

• Windows XP and Internet Explorer
• Konqueror/KDE in any version
• Apache with mod_ssl: there is a patch under review by httpd team for inclusion in future releases, after 2.2.11. See doco at [1]
• 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)