2.1.Unanticipated Usage of SNI Information

The SNI was defined to facilitate management of servers, but thedevelopers of middleboxes found out that they could takeadvantage of the information. Many examples of such usage arereviewed in[RFC8404]. Other examples came outduring discussions of this document. They include:¶

• Filtering or censoring specific services for a variety of reasons¶
• Content filtering by network operators or ISPs blocking specific websites, for example, to implement parental controls or to prevent accessto phishing or other fraudulent websites¶
• ISP assigning different QoS profiles to target services¶
• Firewalls within enterprise networks blocking websites not deemedappropriate for work¶
• Firewalls within enterprise networks exempting specific websites fromman-in-the-middle (MITM) inspection, such as healthcare or financialsites for which inspection would intrude on the privacy of employees¶

The SNI is probably also included in the general collection of metadataby pervasive surveillance actors[RFC7258],for example, to identify servicesused by surveillance targets.¶

2.2.SNI Encryption Timeliness

The cleartext transmission of the SNI was not flagged as a problemin the Security Considerations sections of[RFC3546],[RFC4366], or[RFC6066]. These specifications did not anticipate thealternative usage describedinSection 2.1. One reason may be that, whenthese RFCs were written, theSNI information was available through a variety of other means,such as tracking IP addresses, DNS names, or server certificates.¶

Many deployments still allocate different IP addresses to differentservices, so that different services can be identified by their IPaddresses. However, CDNs commonlyserve a large number of services through a comparatively smallnumber of addresses.¶

The SNI carries the domain name of the server, which is also sent aspart of the DNS queries. Most of the SNI usage described inSection 2.1could also be implemented by monitoring DNS traffic or controlling DNSusage. But this is changing with the advent of DNS resolversproviding services like DNS over TLS[RFC7858]or DNS over HTTPS[RFC8484].¶

The subjectAltName extension of type dNSName of the server certificate(or in its absence, the common name component) exposesthe same name as the SNI. In TLS versions 1.0[RFC2246], 1.1[RFC4346],and 1.2[RFC5246], servers send certificates in cleartext,ensuring that there would be limited benefits in hiding the SNI. However,in TLS 1.3[RFC8446], server certificates areencrypted in transit.Note that encryption alone is insufficient to protect server certificates;seeSection 3.1 for details.¶

The decoupling of IP addresses and server names, deployment of DNS privacy, and protection of server certificate transmissions all contribute to user privacy in the face of an RFC 7258-style adversary[RFC7258]. Encrypting the SNI complements this push for privacy and makes it harder to censor or otherwise provide differential treatment to specific Internet services.¶

2.3.End-to-End Alternatives

Deploying SNI encryption helps thwart most of the unanticipated SNI usages,including censorship and pervasive surveillance, but it alsowill break or reduce the efficacy of the operational practices andtechniques implemented in middleboxes, as described inSection 2.1. Most ofthese functions can, however, be realized by other means. For example, some DNS serviceproviders offer customers the provision to "opt in" to filtering servicesfor parental control and phishing protection. Per-stream QoS could be provided bya combination of packet marking and end-to-end agreements. AsSNI encryption becomes common, we can expect more deployment of such "end-to-end"solutions.¶

At the time of this writing, enterprises have the option of installing afirewall performing SNI filtering toprevent connections to certain websites. With SNI encryption, this becomes ineffective.Obviously, managers could block usage of SNI encryption in enterprise computers, butthis wide-scale blocking would diminish the privacy protection of traffic leaving theenterprise, which may not be desirable.Enterprise managers could rely instead on filtering software and managementsoftware deployed on the enterprise's computers.¶

3.1.Mitigate Cut-and-Paste Attacks

The simplest SNI encryption designs replace the cleartext SNI in the initial TLS exchange withan encrypted value, using a key known to the multiplexed server. Regardless of theencryption used, these designs can be broken by a simple cut-and-paste attack, which worksas follows:¶

1. The user starts a TLS connection to the multiplexed server, including an encrypted SNI value.¶
2. The adversary observes the exchange and copies the encrypted SNI parameter.¶
3. The adversary starts its own connection to the multiplexed server, including in its connection parameters the encrypted SNI copied from the observed exchange.¶
4. 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 whichhidden service the client is using. Successful cut-and-paste attacks break that goal byallowing adversaries to discover that service.¶

3.2.Avoid Widely Shared Secrets

It is easy to think of simple schemes in which the SNI is encrypted or hashed using ashared secret. This symmetric key must be known by the multiplexed server and byevery user of the protected services. Such schemes are thus very fragile, since thecompromise of a single user would compromise the entire set of users and protectedservices.¶

3.3.Prevent SNI-Based Denial-of-Service Attacks

Encrypting the SNI may create extra load for the multiplexed server. Adversaries may mountdenial-of-service (DoS) attacks by generating random encrypted SNI values and forcing themultiplexed 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 connectionattempts 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 componentwith limited resources, while the TLS operations are performed by the component dedicatedto their respective services. SNI-based DoS attacks could target the front-end component.¶

3.4.Do Not Stick Out

In some designs, handshakes using SNI encryption can be easily differentiated from"regular" handshakes. For example, some designs require specific extensions inthe 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 forspecial treatment.¶

In the future, it might be possible to assume that a large fraction of TLS handshakesuse SNI encryption. If that were the case, the detection of SNI encryption wouldbe a lesser concern. However, we have to assume that, in the near future, onlya small fraction of TLS connections will use SNI encryption.¶

This requirement to not stick out may be difficult to meet in practice, as noted inSection 5.¶

3.5.Maintain Forward Secrecy

TLS 1.3[RFC8446] 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.¶

3.6.Enable Multi-party Security Contexts

We can design solutions in which a frontingservice acts as a relay to reach the protected service. Some of thosesolutions involve just one TLS handshake between the client and the fronting service.The master secret is verified by verifying a certificate provided bythe fronting service but not by the protected service.These solutions expose the client to a MITM attack bythe fronting service. Even if the clienthas some reasonable trust in this service, the possibility of aMITM attack is troubling.¶

There are other classes of solutions in which the master secret is verified byverifying a certificate provided by the protected service. These solutions offermore protection against a MITM attack by the fronting service.Thedownside is that the client will not verify the identity of the fronting service,which enables fronting server spoofing attacks, such as the "honeypot" attackdiscussed 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 tothe protected service or to divulge which client accessed it. Butif a MITM attack is possible, the adversaries would also be able to pressurethe fronting service into intercepting or spoofing the communications betweenclient and protected service.¶

Adversaries could also mount an attack by spoofing the fronting service. Aspoofed fronting service could act as a "honeypot" for users ofhidden services. At a minimum, the fake server could record the IPaddresses of these users. If the SNI encryption solution places toomuch trust on the fronting server, the fake server could alsoserve fake content of its own choosing, including various forms ofmalware.¶

There are two main channels by which adversaries can conduct thisattack. Adversaries can simply try to mislead users into believingthat the honeypot is a valid fronting server, especially if thatinformation is carried by word of mouth or in unprotected DNSrecords. Adversaries can also attempt to hijack the traffic to theregular fronting server, using, for example, spoofed DNS responsesor spoofed IP-level routing, combined with a spoofed certificate.¶

3.7.Support Multiple Protocols

The SNI encryption requirement does not stop with HTTP over TLS.Multiple otherapplications currently use TLS, including, for example, SMTP[RFC3207],DNS[RFC7858], IMAP[RFC8314],and the Extensible Messaging and Presence Protocol (XMPP)[RFC7590]. These applications, too,will benefit from SNI encryption.HTTP-only methods, like those described inSection 4.1,would not apply there. In fact, even for the HTTPS case, the HTTPS tunnelingservice described inSection 4.1 iscompatible with HTTP 1.0 and HTTP 1.1but interacts awkwardly with the multiple streams feature of HTTP/2[RFC7540].This points to the need for an application-agnostic solution, which would beimplemented fully in the TLS layer.¶

4.1.HTTPS Tunnels

The HTTP domain fronting solution places a lot of trust in the fronting server. This required trust can be reduced by tunneling HTTPS in HTTPS, which effectively treats the fronting server as an HTTP proxy. In this solution, the client establishes a TLS connection to the fronting server and then issues an HTTP connect request to the hidden server. This will establish an end-to-end HTTPS-over-TLS connection between the client and the hidden server, mitigating the issues described inSection 3.6.¶

The HTTPS-in-HTTPS solution requires double encryption of every packet. Italso requires that the fronting server decrypt and relay messages to thehidden server. Both of these requirements make the implementation onerous.¶

4.2.Delegation Control

Clients would see their privacy compromised if they contacted the wrongfronting server to access the hidden service, since this wrong servercould disclose their access to adversaries. This requires a controlledway to indicate which fronting server is acceptable by the hidden service.¶

This problem is similar to the "word of mouth" variantof the "fronting serverspoofing" attack described inSection 3.6. The spoofingwould be performed by distributing fake advice, such as "to reachhidden.example.com, use fake.example.com as a frontingserver", when "fake.example.com" is under the control of anadversary.¶

In practice, this attack is well mitigated when the hidden service is accessed through a specialized application. The name of the fronting server can then be programmed in the code of the application. But the attack is harder to mitigate when the hidden service has to be accessed through general-purpose web browsers.¶

There are several proposed solutions to this problem, such as creatinga special form of certificate to codify the relation between the fronting andhidden server or obtaining the relation between the hidden and fronting servicethrough the DNS, possibly using DNSSEC, to avoid spoofing.The experimentdescribed in[DOMFRONT] solved the issue byintegrating with the Lantern Internet circumvention tool.¶

We can observe that CDNs have a similar requirement.They need to convince the client that "www.example.com" can be accessedthrough the seemingly unrelated "cdn-node-xyz.example.net". Most CDNs havedeployed DNS-based solutions to this problem. However, the CDN oftenholds the authoritative certificate of the origin. There is, simultaneously,verification of a relationship between the origin and the CDN (through thecertificate) and a risk that the CDN can spoof thecontent from the origin.¶

4.3.Related Work

The ORIGIN frame defined for HTTP/2[RFC8336] can be used to flag content provided by the hidden server. Secondary certificate authentication[HTTP2-SEC-CERTS] can be used to manage authentication of hidden server content or to perform client authentication before accessing hidden content.¶