SNI is an extension of the TLS protocol — an additional field sent as part of the handshake in plain text. It lets a web server use the correct certificate to establish a connection when several sites are hosted on a single IP address. That same feature also allows providers' equipment to see the destination domains and block the traffic.
SNI (Server Name Indication) is an extension of the TLS (Transport Layer Security) protocol that lets a server determine exactly which security certificate to use when establishing an encrypted connection with a client. This is especially useful when several websites with different domain names are hosted on a single IP address.
Server Name Indication (SNI) was developed in the early 2000s to solve the shortage of IPv4 addresses. Before that, every site available over SSL (which was used instead of TLS back then) required a separate IP address.
The idea was for the client (for example, a browser or an application) to state the domain name it wanted to establish a secure connection with at the start of the TLS handshake. This meant the server could determine which certificate to use based on the supplied domain name. The original SNI specification was proposed at the IETF in RFC 3546, released in 2003.
Initially SNI was not supported by all browsers and servers, but over time the technology became a de facto standard. Modern web servers such as Apache and Nginx, as well as the major browsers (Chrome, Firefox, Safari and others), began to actively support SNI.
With the growth of virtual hosting, cloud technologies and security initiatives such as Let's Encrypt, SNI became widely used to manage SSL certificates for many domains integrated on a single server.
Support for SNI has indeed brought many benefits, yet during its rollout and use some problems have arisen and still persist. Here are a few of the main ones: 1. Compatibility of legacy systems: SNI is not supported by some older clients and libraries, especially old versions of browsers and operating systems. This can make it harder for users on outdated devices or software to access sites that use SNI. 2. Limited proxy server capabilities: Some proxy servers, especially outdated or misconfigured ones, may not support SNI, which can lead to connection failures when users try to reach sites that use this mechanism. 3. Certificate issues: If a server is misconfigured for SNI, this can lead to certificate errors. For example, users may receive warnings that the certificate does not match the requested domain. 4. Security and privacy: Because SNI transmits the host name in plain text (i.e. unencrypted), it can raise privacy concerns. Attackers or observers on the network can see which sites a user is visiting, even if the content of the connection itself is encrypted. 5. SNI-based attacks: Specific attacks can target SNI, for example Man-in-the-Middle (MitM) attacks, in which an attacker can intercept the SNI and attempt to substitute certificates. 6. Routing and load-balancing mechanisms: Some routing and load-balancing solutions do not take SNI into account, which can lead to incorrect request routing and degraded performance. 7. The need for proper configuration: For a successful SNI deployment, system administrators must correctly configure web servers and certificate authorities, which can be a challenge for those without enough experience. Despite these problems, SNI remains an important tool for supporting secure connections in situations where several domains may share a single IP address. Many of these problems can be solved with software updates, better server configuration and the use of modern technologies such as DNS over HTTPS (DoH) and TLS 1.3.
