What is SNI?

What is SNI?

SNI stands for Server Name Indication, which is an extension of the TLS protocol. It is used to mark key client information during the TLS handshake. HTTPS often uses SNI to mark the request domain or hostname, allowing the webserver to quickly identify the request address, thereby implementing important features such as CDN, WAF, HTTP proxy, etc. (SNI is an extension of the TLS protocol, not only applicable to HTTP services but also can be used in non-HTTP services with TCP+TLS to achieve some specific functions.).

How does SNI Work?

Once upon a time, when there was no SNI or the basic library did not support SNI, suppose we wanted to develop a web proxy, a basic function of the CDN or WAF system.

How to distinguish multiple users?

Each user system is connected to the web proxy system. Due to the lack of SNI support, for the proxy system to distinguish between multiple users, we naturally think of the following solutions:

1. Assign a unique IP to each user;
2. Multiple users share an IP, distinguished by using ports, for example, http://ip:port/index;
3. Multiple users share one IP, assign a unique subdomain (or hostname) to each user, use a DNS alias (CNAME) to the subdomain, and the web proxy identifies the request based on the hostname tag carried by the HTTP header Host.

Though the public network IP is limited, the first solution is not practical.

The second solution offers a poor user experience as the gateway where the HTTP client resides only opens ports 80/443, resulting in an inaccessible web.

The third solution is capable of executing some HTTP proxy functions and is a commonly used HTTP proxy solution. However, it struggles to implement some new features based on HTTPS.

Core Functions of CDN or WAF Systems

Typically, CDN or WAF systems are not simply HTTP proxies, they also include the following basic features:

1. Able to parse HTTPS, and each user uses their certificate (the user uploads the certificate to the proxy system);
2. Need to perform security checks on the content of each HTTPS request;
3. Compression, caching, back-to-source, and other functions;

To implement the features above, when the web proxy receives an HTTP request, it must first determine the appropriate certificate to use for the handshake with the client. The successful completion of the handshake allows the HTTP content to be decrypted from TLS. This lies at the heart of the issue.

Because HTTPS is transmitted through TCP+TLS, the HTTP content received by the web proxy is encrypted data, and it is impossible to determine who sent the TCP connection. The web proxy has many user certificates, but which one should be used for the TLS handshake? What if every certificate is tried once? This is too inefficient! However, we found that although the content of TLS transmission is encrypted, the header of its message is plaintext (Hello message) during the handshake phase of establishing a session. If the client can place an ID that marks its own identity in the TLS handshake message, the problem will become very simple.

To solve scenarios like the above, a TLS extension has been implemented.

Server Name Indication（SNI）

Web applications often use SNI to carry domain names or hostnames. In addition to the above-mentioned certificate loading, other functions can also be implemented. For example, when the user's SSL certificate cannot be obtained, the gateway only needs to scan TLS and SNI to implement domain name security checks, domain backup checks, etc. In addition, the Internet of Things can also use SNI to mark device IDs to implement two-way authentication of TLS.

What Happens If a User's Browser Does Not Support SNI?

 In this rare case, the user may not be able to access certain websites, and the user's browser will return an error message such as "Your connection lacks security privacy."

The vast majority of browsers and operating systems support SNI. Only very old versions of Internet Explorer, old versions of the BlackBerry operating system, and other outdated software versions do not support SNI.

SNI Compatibility

Currently, most browsers, HTTP servers, and their dependent encryption libraries support SNI. The following SNI support information comes from the Internet and is for reference only:

Desktop browsers

• Chrome 5 and above, Chrome 6 and above (Windows XP)
• Firefox 2 and above
• IE 7 and above (running on Windows Vista/Server 2008 and above, any version of IE browser in XP system does not support SNI)
• Konqueror 4.7 and above
• Opera 8 and above
• Safari 3.0 on Windows Vista/Server 2008 and above, or Mac OS X 10.5.6 and above

Mobile browsers

• Android Browser on 3.0 Honeycomb and above
• iOS Safari on iOS 4 and above
• Windows Phone 7 and above

Servers

• Apache 2.2.12 and above
• Apache Traffic Server 3.2.0 and above
• Cherokee
• HAProxy 1.5 and above
• IIS 8.0 and above
• lighttpd 1.4.24 and above
• LiteSpeed 4.1 and above
• nginx 0.5.32 and above

Command Line

• cURL 7.18.1 and above
• wget 1.14 and above

Common Libraries

• GNU TLS
• JSSE (Oracle Java) 7 and above, only as a client
• libcurl 7.18.1 and above
• NSS 3.1.1 and above
• OpenSSL 0.9.8j and above
• OpenSSL 0.9.8f and above, need to configure the flag
• Qt 4.8 and above

In Conclusion

SNI is an extension of the SSL/TLS protocols, aimed at resolving the problem of decreasing IPv4 address availability. By incorporating the hostname that the client intends to connect to during the handshake process, the server can host multiple HTTPS-secured websites on the same IP address and TCP port number, each with its own unique SSL certificate.