Server Name Indication

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Andrewgprout (talk | contribs) at 01:47, 16 May 2019 (gr add the). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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.

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 is 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 can be served from the same IP address.

In practice, this means that an HTTPS server can 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. The result is that many websites are effectively constrained from using secure communications over IPv4. IPv6 address space is not exhausted, so websites served using IPv6 are unaffected by this issue.

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

The desired hostname is not encrypted, so an eavesdropper can see which site is being requested. This helps security companies provide a filtering feature[5][6][7] and governments implement censorship.[8] While domain fronting was used as a workaround,[9] now both Google and AWS have taken action to disallow this - and it's therefore becoming less of an alternative.[10]

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


In 2004, a patch for adding TLS/SNI into OpenSSL was created by the EdelKey project.[15] 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[16]).

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.


Software Type Supported Notes Supported since
Internet Explorer Web browser Yes Since version 7 on Vista (not supported on XP) 2006
Edge Web browser Yes All versions
Mozilla Firefox Web browser Yes Since version 2.0 2006
cURL Command-line tool and library Yes Since version 7.18.1 2008
Safari Web browser Yes Not supported on Windows XP
Google Chrome Web browser Yes Since 6.0[17] 2010
BlackBerry 10 Web browser Yes Supported in all BB10 releases 2013
BlackBerry OS Web browser No Not supported in 7.1 or earlier
elinks Web browser No Not supported in 0.12pre6 or earlier
Windows Mobile Web browser Yes Some time after 6.5
Android default browser Web browser Yes Honeycomb (3.x) for tablets and Ice Cream Sandwich (4.x) for phones 2011
Firefox for Android Web browser Partial Supported for browsing. Sync and other services don't support SNI[18][19]
wget Command-line tool Yes Since version 1.14 2012
Nokia Browser for Symbian Web browser No
Opera Mobile for Symbian Web browser No Not supported on Series60
Dillo Web browser Yes Since version 3.1 2016
IBM HTTP Server Web server Yes Since version 9.0.0[20][21]
Apache Tomcat Web server Yes Not supported before 8.5 (backport from 9)
Apache HTTP Server Web server Yes Since version 2.2.12 2009
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
Qt Library Yes Since version 4.8 2011
Mozilla NSS server side Library No [22]
4th Dimension Library No Not supported in 15.2 or earlier
Java Library Yes Since version 1.7 2011
ColdFusion / Lucee Library Yes ColdFusion since Version 10 Update 18, 11 Update 7, Lucee since Version, Version 2015
Erlang Library Yes Since version r17 2013
Go Library Yes Since version 1.4 2011
Perl Library Yes Since Net::SSLeay version 1.50 and IO::Socket::SSL version 1.56 2012
PHP Library Yes Since version 5.3 2014
Python Library Yes Supported in 2.x from 2.7.9 and 3.x from 3.2 (in ssl, urllib[2] and httplib modules) 2011 for Python 3.x and 2014 for Python 2.x
Ruby Library Yes Since version 2.0 (in net/http) 2011
Hiawatha Web server Yes Since version 8.6 2012


  1. ^ Blake-Wilson, Simon; Nystrom, Magnus; Hopwood, David; Mikkelsen, Jan; Wright, Tim (June 2003). "Server Name Indication". Transport Layer Security (TLS) Extensions. IETF. p. 8. sec. 3.1. doi:10.17487/RFC3546. ISSN 2070-1721. RFC 3546.
  2. ^ "CAcert VHostTaskForce". CAcert Wiki.
  3. ^ "What is a Multiple Domain (UCC) SSL Certificate?". GoDaddy.
  4. ^ "TLS Server Name Indication". Paul's Journal.
  5. ^ "Web Filter: SNI extension feature and HTTPS blocking". Retrieved 20 February 2019.
  6. ^ "Sophos UTM: Understanding Sophos Web Filtering". 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": 990–995. doi:10.1109/INM.2015.7140423. {{cite journal}}: Cite journal requires |journal= (help)
  8. ^ "South Korea is Censoring the Internet by Snooping on SNI Traffic". BleepingComputer. Retrieved 18 February 2019.
  9. ^ "Encrypted chat app Signal circumvents government censorship". Engadget. Retrieved 4 January 2017.
  10. ^ "Amazon threatens to suspend Signal's AWS account over censorship circumvention". Signal. Retrieved 2 May 2018.
  11. ^
  12. ^ "ESNI: A Privacy-Protecting Upgrade to HTTPS". EFF DeepLinks Blog.
  13. ^ Claburn, Thomas (17 July 2018). "Don't panic about domain fronting, an SNI fix is getting hacked out". The Register. Retrieved 10 October 2018.
  14. ^ "Encrypt it or lose it: how encrypted SNI works". The Cloudflare Blog. 24 September 2018. Retrieved 13 May 2019.
  15. ^ "EdelKey Project". Retrieved 20 February 2019. {{cite web}}: Cite has empty unknown parameter: |dead-url= (help)
  16. ^ "OpenSSL CHANGES". Archived from the original on 20 April 2016. {{cite web}}: Unknown parameter |deadurl= ignored (|url-status= suggested) (help)
  17. ^ "IIS 8 and IIS 8.5 SNI Browser Support". DigiCert. Retrieved 31 December 2015.
  18. ^ "Bug 765064 — HttpClient in use by Sync and other services doesn't support SNI". Bugzilla@Mozilla. 29 October 2017. Retrieved 9 November 2017.
  19. ^ "Bug 1412650 — Switch services.* code to use HttpsURLConnection". Bugzilla@Mozilla. 29 October 2017. Retrieved 9 November 2017.
  20. ^ "IBM HTTP Server SSL Questions and Answers". IBM. Retrieved 8 March 2011.
  21. ^ "IHS 8 powered by Apache 2.2.x ?". IBM. 17 October 2013. Archived from the original on 26 December 2015. Retrieved 9 November 2017. {{cite web}}: Unknown parameter |deadurl= ignored (|url-status= suggested) (help)
  22. ^ "Bug 360421 — Implement TLS Server Name Indication for servers". Bugzilla@Mozilla. 11 November 2006. Retrieved 30 October 2012.

External links

  • RFC 6066 (obsoletes RFC 4366, which obsoleted RFC 3546)