Domain fronting

Domain fronting is a technique that circumvents internet censorship by leveraging the certificates and request forwarding systems of large hosting providers to use different domain names at different communication layers of HTTPS connections with servers and discreetly connect to a different target domain than discernable to third parties monitoring requests and connections.

After TLS encryption is established, the HTTP header reroutes to another domain hosted on the same CDN.

Due to the protection provided by HTTPS—for any given domain name, censors are typically unable to differentiate circumvention ("domain-fronted") 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 the SNI extension and HTTP Host header to contain the same domain. A large share of cloud service providers, including Amazon and Google, now explicitly prevent domain fronting; this has effectively 'disabled' domain fronting as a censorship bypass technique.

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 (CDN) which use certificates that support multiple target domains (i.e. SAN).[1][2]

In an HTTPS request, the destination domain name appears in three relevant places: the DNS query, the TLS Server Name Indication (SNI) extension, and the HTTP Host header; ordinarily the same domain name is listed in all three places.[3]:1

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 covert 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.[1][3]:2

Domain fronting works with CDNs because the manner these networks are generally configured: a CDN's frontend server on receiving a request for a resource not already cached, forwards the request internally to the domain found in the Host header; this forwarded request—which appears to be destined for an unrelated front domain—is the final connection a censor typically monitors. The frontend server decrypts the request on receiving it, reads the Host header and forwards the request to the covert domain specified in the Hosts header—which in the circumvention scenario will be a proxy. No traffic ever reaches the specified front domain; but a CDNs frontend server is the only third-party in this interaction that can decrypt the Hosts header and know the true destination of the request. 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.[3]:2

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 (for DNS and STI).[3]:2

Due to encryption of the HTTPS hosts header by the HTTPS protocol, circumvention traffic is indistinguishable from 'legitimate' (non-fronted) traffic. Implementations of domain fronting supplement HTTPS with using large content delivery networks (such as various large CDNs) as their front domains,[3] which are relied on by large parts of the web for functionality.[4] To block the circumvention traffic, a censor will have to outright block the front domain.[3] Blocking popular content delivery networks is economically, politically, and diplomatically infeasible for most censors;[4][1] and equivalent to "disabling the internet".[5]

When Telegram was blocked in Russia after a court ruling in April 2018, by ISP-blocking of the CDNs Telegram used as a front to evade blocks on its own IP addresses, 15.8 million IP addresses associated with Google and Amazon's CDN were blocked. This resulted in the large scale network outages for major banks, retail chains, and numerous websites. The block was criticised for incompetency.[6]

Usage

Internet censorship circumvention

Signal

Signal, the secure messaging service, deployed domain fronting in builds of their apps from 2016 to 2018 to bypass blocks of direct connections to their servers in Egypt, Oman, Qatar and the United Arab Emirates.[5][4]

Tor Browser

The Tor anonymity network uses an implementation of domain fronting called 'meek' in its official web browser to bypass blocks to the Tor network.[2][4][1]

Telegram

Telegram used Amazon Web Services as a domain front to resist attempts to block the service in Russia.[7]

GreatFire

The anti-Chinese censorship organisation GreatFire used domain fronting at one point.[4]

Cyberattacks

Domain fronting has been used by private, and state-sponsored individuals and groups to cover their tracks and discreetly launch cyberattacks and disseminate malware.[4][1]

Disabling

Cloudflare disabled domain fronting in 2015.[8] Google disabled domain fronting in April 2018, saying that it had "never been a supported feature at Google”.[9][10] 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".[11][12][13] 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.[14][15][16]

Interaction with standards

The use of a different domain in the SNI extension of a request 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.[3]:2

See also

References
  1. "Privacy 2019: Tor, Meek & The Rise And Fall Of Domain Fronting". SentinelOne. 2019-04-15. Retrieved 2020-06-30.
  2. "doc/meek – Tor Bug Tracker & Wiki". trac.torproject.org. Retrieved 2017-01-04.
  3. Fifield, David; Lan, Chang; Hynes, Rod; Wegmann, Percy; Paxson, Vern (15 February 2015). "Blocking-resistant communication through domain fronting" (PDF). Proceedings on Privacy Enhancing Technologies. 2015 (2). doi:10.1515/popets-2015-0009. ISSN 2299-0984. Retrieved 2017-01-03 – via De Gruyter.CS1 maint: date and year (link)
  4. "The Death of Domain Fronting | What Lies Ahead?". Finjan Blog. 2018-06-11. Retrieved 2020-06-30.
  5. "Open Whisper Systems >> Blog >> Doodles, stickers, and censorship circumvention for Signal Android". whispersystems.org. Retrieved 2017-01-04.
  6. Savov, Vlad (2018-04-17). "Russia's Telegram ban is a big, convoluted mess". The Verge. Retrieved 2020-08-10.
  7. Brandom, Russell (2018-04-30). "Amazon Web Services starts blocking domain-fronting, following Google's lead". The Verge. Retrieved 2020-08-08.
  8. "#14256 (Clarify whether Cloudflare's Universal SSL thing works with meek) – Tor Bug Tracker & Wiki". Tor Bug Tracker. Retrieved 12 May 2020.
  9. Brandom, Russell. "A Google update just created a big problem for anti-censorship tools". The Verge. Retrieved 2018-04-19.
  10. "Google ends "domain fronting," a crucial way for tools to evade censors - Access Now". 18 April 2018.
  11. "Enhanced Domain Protections for Amazon CloudFront Requests". 2018-04-27.
  12. "Signal >> Blog >> A letter from Amazon". signal.org.
  13. "Amazon Web Services starts blocking domain-fronting, following Google's lead". 2018-04-30.
  14. "Amazon and Google bow to Russian censors in Telegram battle". Fast Company. 2018-05-04. Retrieved 2018-05-09.
  15. Bershidsky, Leonid (May 3, 2018). "Russian Censor Gets Help From Amazon and Google". www.bloomberg.com.
  16. "Info". Tass.ru. Retrieved 2018-11-14.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.