Over the past years, there have been multiple proposals to add an SNI encryption option in TLS. A review of the TLS mailing list archives shows that many of these proposals appeared promising but were rejected after security reviews identified plausible attacks. In this section, we collect a list of these known attacks.
The simplest SNI encryption designs replace the cleartext SNI in the initial TLS exchange with an encrypted value, using a key known to the multiplexed server. Regardless of the encryption used, these designs can be broken by a simple cut-and-paste attack, which works as follows:
The user starts a TLS connection to the multiplexed server, including an encrypted SNI value.
The adversary observes the exchange and copies the encrypted SNI parameter.
The adversary starts its own connection to the multiplexed server, including in its connection parameters the encrypted SNI copied from the observed exchange.
The multiplexed server establishes the connection to the protected service, which sends its certificate, thus revealing the identity of the service.
One of the goals of SNI encryption is to prevent adversaries from knowing which hidden service the client is using. Successful cut-and-paste attacks break that goal by allowing adversaries to discover that service.
It is easy to think of simple schemes in which the SNI is encrypted or hashed using a shared secret. This symmetric key must be known by the multiplexed server and by every user of the protected services. Such schemes are thus very fragile, since the compromise of a single user would compromise the entire set of users and protected services.
Encrypting the SNI may create extra load for the multiplexed server. Adversaries may mount denial-of-service (DoS) attacks by generating random encrypted SNI values and forcing the multiplexed server to spend resources in useless decryption attempts.
It may be argued that this is not an important avenue for DoS attacks, as regular TLS connection attempts also require the server to perform a number of cryptographic operations. However, in many cases, the SNI decryption will have to be performed by a front-end component with limited resources, while the TLS operations are performed by the component dedicated to their respective services. SNI-based DoS attacks could target the front-end component.
In some designs, handshakes using SNI encryption can be easily differentiated from "regular" handshakes. For example, some designs require specific extensions in the ClientHello packets or specific values of the cleartext SNI parameter. If adversaries can easily detect the use of SNI encryption, they could block it, or they could flag the users of SNI encryption for special treatment.
In the future, it might be possible to assume that a large fraction of TLS handshakes use SNI encryption. If that were the case, the detection of SNI encryption would be a lesser concern. However, we have to assume that, in the near future, only a small fraction of TLS connections will use SNI encryption.
This requirement to not stick out may be difficult to meet in practice, as noted in Section 5
TLS 1.3 [RFC 8446
] is designed to provide forward secrecy, so that (for example) keys used in past sessions will not be compromised even if the private key of the server is compromised. The general concerns about forward secrecy apply to SNI encryption as well. For example, some proposed designs rely on a public key of the multiplexed server to define the SNI encryption key. If the corresponding private key should be compromised, the adversaries would be able to process archival records of past connections and retrieve the protected SNI used in these connections. These designs fail to maintain forward secrecy of SNI encryption.
We can design solutions in which a fronting service acts as a relay to reach the protected service. Some of those solutions involve just one TLS handshake between the client and the fronting service. The master secret is verified by verifying a certificate provided by the fronting service but not by the protected service. These solutions expose the client to a MITM attack by the fronting service. Even if the client has some reasonable trust in this service, the possibility of a MITM attack is troubling.
There are other classes of solutions in which the master secret is verified by verifying a certificate provided by the protected service. These solutions offer more protection against a MITM attack by the fronting service. The downside is that the client will not verify the identity of the fronting service, which enables fronting server spoofing attacks, such as the "honeypot" attack discussed below. Overall, end-to-end TLS to the protected service is preferable, but it is important to also provide a way to authenticate the fronting service.
The fronting service could be pressured by adversaries. By design, it could be forced to deny access to the protected service or to divulge which client accessed it. But if a MITM attack is possible, the adversaries would also be able to pressure the fronting service into intercepting or spoofing the communications between client and protected service.
Adversaries could also mount an attack by spoofing the fronting service. A spoofed fronting service could act as a "honeypot" for users of hidden services. At a minimum, the fake server could record the IP addresses of these users. If the SNI encryption solution places too much trust on the fronting server, the fake server could also serve fake content of its own choosing, including various forms of malware.
There are two main channels by which adversaries can conduct this attack. Adversaries can simply try to mislead users into believing that the honeypot is a valid fronting server, especially if that information is carried by word of mouth or in unprotected DNS records. Adversaries can also attempt to hijack the traffic to the regular fronting server, using, for example, spoofed DNS responses or spoofed IP-level routing, combined with a spoofed certificate.
The SNI encryption requirement does not stop with HTTP over TLS. Multiple other applications currently use TLS, including, for example, SMTP [RFC 3207
], DNS [RFC 7858
], IMAP [RFC 8314
], and the Extensible Messaging and Presence Protocol (XMPP) [RFC 7590
]. These applications, too, will benefit from SNI encryption. HTTP-only methods, like those described in Section 4.1
, would not apply there. In fact, even for the HTTPS case, the HTTPS tunneling service described in Section 4.1
is compatible with HTTP 1.0 and HTTP 1.1 but interacts awkwardly with the multiple streams feature of HTTP/2 [RFC 7540
]. This points to the need for an application-agnostic solution, which would be implemented fully in the TLS layer.
The Application-Layer Protocol Negotiation (ALPN) parameters of TLS allow implementations to negotiate the application-layer protocol used on a given connection. TLS provides the ALPN values in cleartext during the initial handshake. While exposing the ALPN does not create the same privacy issues as exposing the SNI, there is still a risk. For example, some networks may attempt to block applications that they do not understand or that they wish users would not use.
In a sense, ALPN filtering could be very similar to the filtering of specific port numbers exposed in some networks. This filtering by ports has given rise to evasion tactics in which various protocols are tunneled over HTTP in order to use open ports 80 or 443. Filtering by ALPN would probably beget the same responses, in which the applications just move over HTTP and only the HTTP ALPN values are used. Applications would not need to do that if the ALPN were hidden in the same way as the SNI.
In addition to hiding the SNI, it is thus desirable to also hide the ALPN. Of course, this implies engineering trade-offs. Using the same technique for hiding the ALPN and encrypting the SNI may result in excess complexity. It might be preferable to encrypt these independently.
The TLS handshake is also used over other transports, such as UDP with both DTLS [DTLS-1.3
] and QUIC [QUIC
]. The requirement to encrypt the SNI applies just as well for these transports as for TLS over TCP.
This points to a requirement for SNI encryption mechanisms to also be applicable to non-TCP transports such as DTLS or QUIC.