How it worked prior to SNI implementation
SNI stands for Server Name Indication and is an extension of the TLS protocol. It indicates which hostname is being contacted by the browser at the beginning of the handshake process. This technology allows a server to connect multiple SSL Certificates to one IP address and gate.
How it worked prior to SNI implementation
When someone visits your website, their web browser/client connects with the web server and sends it the name and domain name of the webpage. When making an SSL/TLS connection, the process becomes a little more complicated. The browser will require a digital certificate from the server, before it even knows what page the browser wishes to access. Then it will compare the name on the certificate from the server with the name of the page it is trying to make a connection with.
If the names match, the connection will be made in an ordinary way.
When the names do not match, the visitor will not see your website but a warning message, possibly followed by a disconnect from the website, as the failed connection could indicate a man-in-the-middle attack.
To prevent this, websites that use SSLs are required to have their own IP addresses. This allows the web server to use the IP address to check which website the visitor wants to connect to and send the right certificate to the browser or client.
SNI as a solution
As the number of IP addresses is limited, requiring every website to have its own IP address may cause problems in the long term. Server Name Indication (SNI) is the solution to this problem. Browsers that support SNI will immediately communicate the name of the website the visitor wants to connect to, during the initialization of the secured connection, so that the server knows which certificate to send back. This allows browsers/clients and servers supporting SNI to connect multiple certificates for multiple domains to one IP address. So, your website visitor will not notice any differences.
SNI technology is quite new. Its implementation was taking place from 2004 to 2007.
In order to implement this technology, TLS library of the application must include SNI and this application should pass the hostname to the TLS library.
Moreover, the TLS library may either be included in the application program or be a component of the operating system in question. Because of this issue, some browsers implement SNI when running on any operating system, while others implement it only when running on certain operating systems.
If you want the full technical details on SNI, you can read the relevant RFC.
Applications that support SNI
Web-browsers
- Internet Explorer 7 or later, on Windows Vista or higher.
- Mozilla Firefox 2.0 or later
- Opera 8.0 (2005) or later (the TLS 1.1 protocol must be enabled)
- Opera Mobile, at least version 10.1 beta on Android
- Google Chrome (Vista or higher. XP on Chrome 6 or newer OS X 10.5.7 or higher on Chrome 5.0.342.1 or newer)
- Safari 3.0 or later (Mac OS X 10.5.6 or higher and Windows Vista or higher)
- Konqueror/KDE 4.7 or later
- MobileSafari in Apple iOS 4.0 or later
- Android default browser on Honeycomb (v3.x) or newer
- BlackBerry 10 and BlackBerry Tablet OS default browser
- Windows Phone 7 or later
- MicroB on Maemo
- Odyssey on MorphOS
Servers
- Apache 2.2.12 or later using mod_ssl, or alternatively with mod_gnutls
- Microsoft Internet Information Server IIS 8 or later.
- Nginx with an accompanying OpenSSL built with SNI capability
- Apache Traffic Server 3.2.0 or later.
- Radware Alteon ADC
- A10 Networks Thunder ADC 2.7.2 or later
- Cherokee if compiled with TLS capability
- Versions of lighttpd 1.4.x and 1.5.x with patch, or 1.4.24+ without patch
- F5 Networks Local Traffic Manager running version 11.1 or later
- Ping Access 3.0 or later
- Hiawatha (web server) 8.6 or later
- LiteSpeed 4.1 or later
- Pound 2.6 or later
- PageKite tunneling reverse proxy
- Saetta Web Server via OpenSSL
- LBL®LoadBalancer 9.1 or later
- Citrix NetScaler 9.2 or later (9.3 Enhanced)
- Radware Alteon ADC running AlteonOS 28.1 or later
- HAProxy 1.5 or later
- EVO Mail Server
- Fortinet FortiWeb WAF 5.3 or later
- Parallels Plesk Panel (SNI is switched on when Panel is installed on the following operating systems:
- OpenSuSE Linux 11.3 or later
- Ubuntu Linux 10.4 or later
- Debian Linux 6.0 or later
- RedHat Linux 6.0 or later
- CentOS 5.0 or later (only with Apache, PHP, and OpenSSL supplied with Panel))
Libraries
- Mozilla NSS 3.11.1 client-side only
- 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) through 1.0.0 (released 29 March 2010) – compiled in by default
- GnuTLS
- wolfSSL (previously CyaSSL) – not compiled in by default, can be compiled in with config option ‘–enable-sni’ or ‘–enable-tlsx’.
- mbed TLS (previously PolarSSL) since 1.2.0 – compiled in by default
- libcurl / cURL since 7.18.1 (released 30 Mar 2008) when compiled against an SSL/TLS toolkit with SNI
- Python 2.7.9, 3.2 and above (ssl, urllib[2] and httplib modules)
- Qt 4.8
- Oracle Java 7 JSSE
- Apache HttpComponents 4.3.2
- wget 1.14
- Android 2.3 (Gingerbread) has partial support if application uses HttpsURLConnection class.
- Android 4.2 (Jellybean MR1) exposes SNI support on raw sockets via its SSLCertificateSocketFactory class.
- IO::Socket::SSL (Perl/CPAN module, client support since version 1.56,[42] server support since 1.83)
- Pike 7.9.5 (SSL module)
- MatrixSSL (client and server)
- stunnel (client and server)
- Go (client and server)
How to configure SNI
For Tomcat, SNI is not supported on the server side until Java 8. The minimum Java version that Tomcat 8 has to support is Java 7, so at the moment there is no SNI support in Tomcat. It may be possible to optionally support SNI if Tomcat is running on Java 8 or later but that would need code changes that are not planned yet.
The details how to support non-SNI capable Clients with Web Application Proxy and AD FS 2012 R2 can be found here.