Server Name Indication


Server Name Indication is an extension to the Transport Layer Security computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. This allows a server to present multiple certificates on the same IP address and TCP port number and hence allows multiple secure websites to be served by the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. The desired hostname is not encrypted in the original SNI extension, so an eavesdropper can see which site is being requested.

Background of the problem

When making a TLS connection, the client requests a digital certificate from the web server. Once the server sends the certificate, the client examines it and compares the name it was trying to connect to with the name included in the certificate. If a match occurs, the connection proceeds as normal. If a match is not found, the user may be warned of the discrepancy and the connection may abort as the mismatch may indicate an attempted man-in-the-middle attack. However, some applications allow the user to bypass the warning to proceed with the connection, with the user taking on the responsibility of trusting the certificate and, by extension, the connection.
However it may be difficult — or even impossible, due to lack of a full list of all names in advance — to obtain a single certificate that covers all names a server will be responsible for. A server that is responsible for multiple hostnames is likely to need to present a different certificate for each name. 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 controlled by one person in a single certificate. Such "unified communications certificates" must be reissued every time the list of domains changes.
Name-based virtual hosting allows multiple DNS hostnames to be hosted by a single server on the same IP address. To achieve this, the server uses a hostname presented by the client as part of the protocol. However, when using HTTPS, the TLS handshake happens before the server sees any HTTP headers. Therefore, it was 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 could be served from the same IP address.
In practice, this meant that an HTTPS server could only serve one domain per IP address for secured and efficient 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 exhausted. For IPv6, it increases the administrative overhead by having multiple IPs on a single machine, even though the address space is not exhausted. The result was that many websites were effectively constrained from using secure communications.

Technical principles

SNI addresses this issue by having the client send the name of the virtual domain as part of the TLS negotiation's ClientHello message. 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 implement SNI, a server with a single IP address can serve a group of domain names for which it is impractical to get a common certificate.
SNI was added to the IETF's Internet RFCs in June 2003 through RFC 3546, Transport Layer Security Extensions. The latest version of the standard is RFC 6066.

Security implications

Server Name Indication payload is not encrypted, thus the hostname of the server the client tries to connect to is visible to a passive eavesdropper. This protocol weakness was exploited by security software for network filtering and monitoring and governments implement censorship. Presently, there are multiple technologies attempting to encrypt Server Name Indication.

Domain fronting

Domain fronting is a technique of replacing the desired host name in SNI with another one hosted by the same serves or, more frequently, network of servers known as Content Delivery Network. When client uses domain fronting, it replaces the server domain in SNI, but leaves it in the HTTP host header so that server can serve the right content. Domain fronting violates the standard defining SNI itself, so its compatibility is limited. While domain fronting was used in the past, its popularity dwindled because major cloud providers explicitly prohibit it in their TOS and have technical restrictions against it.

Encrypted Client Hello

Encrypted Client Hello is a TLS protocol extension that enables encryption of the whole Client Hello message, which is sent during early stage of TLS negotiation. ECH encrypts the payload with a public key that the relying party needs to know in advance, which means ECH is most effective with large CDNs known to browser vendors in advance.
The initial 2018 version of this extension was called Encrypted SNI and its implementations rolled out in an "experimental" fashion to address this risk of domain eavesdropping. In contrast to ECH, Encrypted SNI encrypted just the SNI rather than the whole Client Hello. Opt-in support for this version was incorporated into Firefox in October 2018 and required enabling DNS-over-HTTPS. It was reworked into the current extension in March 2020.
The short name was ECHO in March 2020 and changed to ECH in May 2020.

Implementation

In 2004, a patch for adding 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 back-ported to OpenSSL 0.9.8.
For an application program to implement SNI, the TLS library it uses must implement it and the application must pass the hostname to the TLS library. Further complicating matters, the TLS library may either be included in the application program or be a component of the underlying operating system. Because of this, some browsers implement SNI when running on any operating system, while others implement it only when running on certain operating systems.

Support

SoftwareTypeSupportedNotesSupported since
Alpine IMAP email clientSince version 2.222019-02-18
Internet ExplorerWeb browserSince version 7 on Vista 2006
EdgeWeb browserAll versions
Mozilla FirefoxWeb browserSince version 2.02006
cURLCommand-line tool and librarySince version 7.18.12008
SafariWeb browserNot supported on Windows XP
Google ChromeWeb browser2010
BlackBerry 10Web browserSupported in all BB10 releases2013
BlackBerry OSWeb browserNot supported in 7.1 or earlier
Windows MobileWeb browserSome time after 6.5
Android default browserWeb browserHoneycomb for tablets and Ice Cream Sandwich for phones2011
Firefox for AndroidWeb browserSupported for browsing. Sync and other services don't support SNI
wgetCommand-line toolSince version 1.142012
Nokia Browser for SymbianWeb browser
Opera Mobile for SymbianWeb browserNot supported on Series60
DilloWeb browserSince version 3.12016
IBM HTTP ServerWeb serverSince version 9.0.0
Apache TomcatWeb serverNot supported before 8.5
Apache HTTP ServerWeb serverSince version 2.2.122009
Microsoft IISWeb serverSince version 82012
nginxWeb serverSince version 0.5.232007
JettyWeb serverSince version 9.3.02015
HCL DominoWeb serverSince version 11.0.12020
QtLibrarySince version 4.82011
Mozilla NSS server sideLibrary
4th DimensionLibraryNot supported in 15.2 or earlier
JavaLibrarySince version 1.72011
ColdFusion / LuceeLibraryColdFusion since Version 10 Update 18, 11 Update 7, Lucee since Version 4.5.1.019, Version 5.0.0.502015
ErlangLibrarySince version r172013
GoLibrarySince version 1.42011
PerlLibrarySince Net::SSLeay version 1.50 and IO::Socket::SSL version 1.562012
PHPLibrarySince version 5.32014
PythonLibrarySupported in 2.x from 2.7.9 and 3.x from 3.2 2011 for Python 3.x and 2014 for Python 2.x
RubyLibrarySince version 2.0 2011
HiawathaWeb serverSince version 8.62012