Server Name Indication

Server Name Indication (SNI) is an extension to the Transport Layer Security (TLS) computer networking
protocol by which a client indicates which hostname it is attempting to connect to at the start of the
handshaking process.[1] This allows a server to present multiple certificates on the same IP address and TCP
port number and hence allows multiple secure (HTTPS) websites (or any other service over TLS) 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.

Contents
Background of the problem
How SNI fixes the problem
Security implications
Domain fronting
Encrypted SNI (ESNI)
Encrypted Client Hello
Implementation
Support
References
External links

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(s) 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 (or small group of
names). Since 2005, CAcert has run experiments on different methods of using TLS on virtual servers.[2]
Most of the experiments are unsatisfactory and impractical. For example, it is possible to use
subjectAltName to contain multiple domains controlled by one person[3] 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 (usually a web
server) on the same IP address. To achieve this, the server uses a hostname presented by the client as part of
the protocol (for HTTP the name is presented in the host header). 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 (or small group of domains) 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.

How SNI fixes the problem

SNI addresses this issue by having the client send the name of the virtual domain as part of the TLS
negotiation's ClientHello message.[4] 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
(TLS) 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[5][6][7] and governments implement censorship.[8] 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 (unencrypted), but leaves it in the HTTP host header
(which is encrypted by TLS) so that server can serve the right content. Domain fronting violates the standard
defining SNI itself, so its compatibility is limited (many services check that SNI host matches the HTTP
header host and reject connections with domain-fronted SNI as invalid). While domain fronting was used in
the past,[9] its popularity dwindled because major cloud providers (Google, Amazon's AWS and
CloudFront) explicitly prohibit it in their TOS and have technical restrictions against it.[10]

Encrypted SNI (ESNI)

As of mid 2018, an extension to TLS 1.3 called Encrypted SNI (ESNI)[11] is being rolled out in an
"experimental phase" to address this risk of domain eavesdropping.[12][13][14]

Support for ESNI was incorporated into Firefox Nightly in October 2018.[15] While the mainline Firefox
browser supports ESNI, it requires using DNS-over-HTTPS to be enabled.[16]

In first half of 2020, ESNI specification was reworked into Encrypted Client Hello specification. In contrast
to ESNI, Encrypted Client Hello encrypts the whole Client Hello and not just the SNI.
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. It is based on earlier experimental technology
called Encrypted SNI. Both ESNI and ECH work by encrypting the payload with a key that the relying party
(a web browser) needs to know in advance, which means ESNI and ECH are most effective with large
CDNs known to browser vendors in advance.

In March 2020, ESNI specification was renamed Encrypted Client Hello (ECHO for short) and reworked to
encrypt the entire Client Hello (not just Server Name Indication).[17] In May 2020, the short name changed
from ECHO to ECH.[18]

Implementation
In 2004, a patch for adding TLS/SNI into OpenSSL was created by the EdelKey project.[19] 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 (first released in 0.9.8f[20]).

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
 Support for SNI[2]
Software Type Supported Notes Supported since
Alpine IMAP email
Yes Since version 2.22[21] 2019-02-18
(email client) client
Internet
Web browser Yes Since version 7 on Vista (not supported on XP) 2006
Explorer
Edge Web browser Yes All versions
Mozilla
Web browser Yes Since version 2.0 2006
Firefox
Command-
cURL line tool and Yes Since version 7.18.1 2008
library
Safari Web browser Yes Not supported on Windows XP
Google
Web browser Yes 2010
Chrome
BlackBerry
Web browser Yes Supported in all BB10 releases 2013
10
BlackBerry
Web browser Not supported in 7.1 or earlier
OS
Windows
Web browser Some time after 6.5
Mobile
Android
Honeycomb (3.x) for tablets and Ice Cream
default Web browser Yes 2011
Sandwich (4.x) for phones
browser

Firefox for Supported for browsing. Sync and other

Web browser Partial
Android services don't support SNI[22][23]
Command-
wget Yes Since version 1.14 2012
line tool
Nokia
Browser for Web browser No
Symbian
Opera
Mobile for Web browser No Not supported on Series60
Symbian
Dillo Web browser Yes Since version 3.1 2016
IBM HTTP
Web server Yes Since version 9.0.0[24][25]
Server
Apache
Web server Yes Not supported before 8.5 (backport from 9)
Tomcat
Apache
HTTP Web server Yes Since version 2.2.12 2009
Server
Microsoft IIS Web server Yes Since version 8 2012
nginx Web server Yes Since version 0.5.23 2007
Jetty Web server Yes Since version 9.3.0 2015
HCL
Web server Yes Since version 11.0.1 2020
Domino
Qt Library Yes Since version 4.8 2011
Mozilla NSS [26]
Library No
server side
4th
Library No Not supported in 15.2 or earlier
Dimension
Java Library Yes Since version 1.7 2011
ColdFusion since Version 10 Update 18, 11
ColdFusion /
Library Yes Update 7, Lucee since Version 4.5.1.019, 2015
Lucee
Version 5.0.0.50
Erlang Library Yes Since version r17 2013
Go Library Yes Since version 1.4 2011
Since Net::SSLeay version 1.50 and
Perl Library Yes 2012
IO::Socket::SSL version 1.56

PHP Library Yes Since version 5.3 2014

2011 for Python 3.x
Supported in 2.x from 2.7.9 and 3.x from 3.2 (in
Python Library Yes and 2014 for
ssl, urllib[2] and httplib modules)
Python 2.x
Ruby Library Yes Since version 2.0 (in net/http) 2011

Hiawatha Web server Yes Since version 8.6 2012

References
1. Blake-Wilson, Simon; Nystrom, Magnus; Hopwood, David; Mikkelsen, Jan; Wright, Tim (June
2003). "Server Name Indication" (https://tools.ietf.org/html/rfc3546#section-3.1). Transport
Layer Security (TLS) Extensions (https://tools.ietf.org/html/rfc3546). IETF. p. 8. sec. 3.1.
doi:10.17487/RFC3546 (https://doi.org/10.17487%2FRFC3546). ISSN 2070-1721 (https://ww
w.worldcat.org/issn/2070-1721). RFC 3546 (https://tools.ietf.org/html/rfc3546).
2. "CAcert VHostTaskForce" (https://web.archive.org/web/20090822082355/http://wiki.cacert.org/
wiki/VhostTaskForce). CAcert Wiki. Archived from the original (http://wiki.cacert.org/wiki/VhostT
askForce) on 22 August 2009. Retrieved 27 October 2008.
3. "What is a Multiple Domain (UCC) SSL Certificate?" (https://support.godaddy.com/help/article/
3908/what-is-a-multiple-domain-ucc-ssl-certificate?locale=en). GoDaddy.
4. "TLS Server Name Indication" (http://journal.paul.querna.org/articles/2005/04/24/tls-server-na
me-indication/). Paul's Journal.
5. "Web Filter: SNI extension feature and HTTPS blocking" (https://www3.trustwave.com/softwar
e/8e6/hlp/r3000/files/1system_filter.html). www3.trustwave.com. Retrieved 20 February 2019.
6. "Sophos UTM: Understanding Sophos Web Filtering" (https://community.sophos.com/kb/en-us/
115865). Sophos Community. Retrieved 20 February 2019.
7. Chrisment, Isabelle; Goichot, Antoine; Cholez, Thibault; Shbair, Wazen M. (11 May 2015).
"Efficiently Bypassing SNI-based HTTPS Filtering" (https://hal.inria.fr/hal-01202712/document):
990–995. doi:10.1109/INM.2015.7140423 (https://doi.org/10.1109%2FINM.2015.7140423).
8. "South Korea is Censoring the Internet by Snooping on SNI Traffic" (https://www.bleepingcomp
uter.com/news/security/south-korea-is-censoring-the-internet-by-snooping-on-sni-traffic/).
BleepingComputer. Retrieved 18 February 2019.
9. "Encrypted chat app Signal circumvents government censorship" (https://www.engadget.com/2
016/12/21/signal-egypt-uae-censorship-block-domain-fronting/). Engadget. Retrieved
4 January 2017.
10. "Amazon threatens to suspend Signal's AWS account over censorship circumvention" (https://s
ignal.org/blog/looking-back-on-the-front/). Signal. Retrieved 2 May 2018.
11. https://tools.ietf.org/html/draft-ietf-tls-esni
12. "ESNI: A Privacy-Protecting Upgrade to HTTPS" (https://www.eff.org/deeplinks/2018/09/esni-p
rivacy-protecting-upgrade-https). EFF DeepLinks Blog.
13. Claburn, Thomas (17 July 2018). "Don't panic about domain fronting, an SNI fix is getting
hacked out" (https://www.theregister.co.uk/2018/07/17/encrypted_server_names/). The
Register. Retrieved 10 October 2018.
14. "Encrypt it or lose it: how encrypted SNI works" (https://blog.cloudflare.com/encrypted-sni/).
The Cloudflare Blog. 24 September 2018. Retrieved 13 May 2019.
15. Eric, Rescorla. "Encrypted SNI Comes to Firefox Nightly" (https://blog.mozilla.org/security/201
8/10/18/encrypted-sni-comes-to-firefox-nightly/). Mozilla Security Blog. Retrieved 15 June
2020.
16. Daniel, Stenberg. "curl-library mailing list archive" (https://curl.haxx.se/mail/lib-2019-03/0000.ht
ml). curl.haxx.se. Retrieved 15 June 2020.
17. "ESNI -> ECHO · tlswg/draft-ietf-tls-esni" (https://github.com/tlswg/draft-ietf-tls-esni/pull/207).
18. "s/ECHO/ECH · tlswg/draft-ietf-tls-esni" (https://github.com/tlswg/draft-ietf-tls-esni/pull/236).
19. "EdelKey Project" (http://www.edelweb.fr/EdelKey/files/). www.edelweb.fr. Retrieved
20 February 2019.
20. "OpenSSL CHANGES" (https://web.archive.org/web/20160420213610/https://www.openssl.or
g/news/cl098.txt). Archived from the original (https://www.openssl.org/news/cl098.txt) on 20
April 2016.
21. https://repo.or.cz/alpine.git/commit/08fcd1b86979b422eb586e56459d6fe15333e500
22. "Bug 765064 — HttpClient in use by Sync and other services doesn't support SNI" (https://bug
zilla.mozilla.org/show_bug.cgi?id=765064). Bugzilla@Mozilla. 29 October 2017. Retrieved
9 November 2017.
23. "Bug 1412650 — Switch services.* code to use HttpsURLConnection" (https://bugzilla.mozilla.
org/show_bug.cgi?id=1412650). Bugzilla@Mozilla. 29 October 2017. Retrieved 9 November
2017.
24. "IBM HTTP Server SSL Questions and Answers" (http://publib.boulder.ibm.com/httpserv/ihsdia
g/ssl_questions.html#SNI). IBM. Retrieved 8 March 2011.
25. "IHS 8 powered by Apache 2.2.x ?" (https://web.archive.org/web/20151226083713/https://ww
w.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-0000
14769679). IBM. 17 October 2013. Archived from the original (http://www.ibm.com/developerw
orks/forums/thread.jspa?threadID=412433&tstart=0) on 26 December 2015. Retrieved
9 November 2017.
26. "Bug 360421 — Implement TLS Server Name Indication for servers" (https://bugzilla.mozilla.or
g/show_bug.cgi?id=360421). Bugzilla@Mozilla. 11 November 2006. Retrieved 30 October
2012.

External links
RFC 6066 (obsoletes RFC 4366, which obsoleted RFC 3546)

Retrieved from "https://en.wikipedia.org/w/index.php?title=Server_Name_Indication&oldid=965865328"

This page was last edited on 3 July 2020, at 21:26 (UTC).

Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. By using this
site, you agree to the Terms of Use and Privacy Policy. Wikipedia® is a registered trademark of the Wikimedia
Foundation, Inc., a non-profit organization.