Domain fronting is a technique that circumvents internet censorship by leveraging the certificates and request forwarding systems of large hosting providers to obfuscate the SNI extension of a TLS connection—effectively hiding the target domain of a connection. Due to the protection provided by TLS, for any given domain name, censors are typically unable to differentiate circumvention traffic from legitimate non-fronted traffic; as such they are forced to either allow all traffic to the domain—including circumvention traffic—or block the domain name entirely, which may result in expensive collateral damage. Domain fronting does not conform to HTTP standards that require SNI and in HTTP Host header to contain the same domain. Cloud service providers, including Amazon and Google, explicitly prevent domain fronting. IETF working group is currently developing an alternative solution, called TLS Encrypted Client Hello, which works by encrypting the whole Client Hello, including SNI.
Technical details
The basis for domain fronting is using different domain names at different layers of communication with a server. This can be done by leveraging the infrastructure of hosting providers or content delivery networks which use certificates that support multiple target domains. In an HTTPS request, the destination domain name appears in three relevant places: the DNS query, the TLS Server Name Indication extension, and the HTTP Host header; ordinarily the same domain name is listed in all three places. In a domain-fronted HTTPS request, one domain appears on the “outside” of an HTTPS request in plain text—in the DNS request and SNI extention—which will be what the client wants to pretend they are targeting in the connection establishment and is the one that is visible to censors, while a different domain appears on the “inside”—in the HTTP Host header, invisible to the censor under HTTPS encryption—which would be the actual target of the connection. Domain fronting works with CDNs because a CDN's frontend server on receiving a request for a resource not already cached, forwards the request to the domain found in the Host header. The client issues a request that appears to be destined for an unrelated front domain, which may be any of the CDN’s domains that resolve to a frontend server; this fronted request is what the censor sees. The frontend server decrypts the request, reads the Host header and forwards the request to the domain specified in the Hosts header, which in the circumvention scenario is a general-purpose proxy. The Hosts header domain, being a proxy, would be blocked by the censor if accessed directly. Fronting hides its address from the censor. It is possible to emulate this same behaviour with host services that don't automatically forward requests, through a "reflector" web application. As a general rule, web services only forward requests to their own customers' domains, not arbitrary ones. It is necessary then for the blocked domains, that use domain fronting, to also be hosted by the same large provider as the innocuous sites they will using as a front in their HTTPS requests. By using domain fronting, a user can connect to a disallowed site while pretending to be visiting an allowed site. Due to the protection provided by TLS, for any given domain name, censors are typically unable to differentiate circumvention traffic from legitimate traffic. As such, they are forced to either allow all traffic to the domain name, including circumvention traffic, or block the domain name entirely, which may result in expensive collateral damage.
Disabling
Cloudflare disabled domain fronting in 2015. Google disabled domain fronting in April 2018, saying that it had "never been a supported feature at Google." Amazon also decided to disable domain fronting for CloudFront in April 2018, claiming it was "already handled as a breach of AWS Terms of Service". This effort by both Google and Amazon was in part due to pressure from the Russian government over Telegram domain fronting activity using both of the cloud providers' services.
Interaction with standards
The use of a fake domain in the SNI information goes against the definition of SNI itself, and many services do ensure that the SNI host matches the HTTP header host, rejecting domain-fronted requests as invalid. This problem can be circumvented on some services by not using SNI at all.
