Domain fronting is a technique used to bypass censorship and hide command and control (aka C2) traffic. It makes a connection to one destination appear to be going somewhere else by exploiting the fact that HTTPS identifies its destination in multiple places. This allowed tools to reach blocked services by hiding behind trusted cloud providers, until the providers changed how their platforms handled requests.
Domain Fronting
An HTTPS connection identifies its destination in two places:
- The TLS SNI, which is sent in clear text during the TLS handshake so the server knows which certificate to present. This is the hostname that firewalls and censors see before encryption.
- The HTTP Host header, which is sent inside the encrypted connection and tells the server which website or backend service should receive the request.
Under normal circumstances, both values are the same.
With domain fronting, they are different on purpose. The SNI contains an allowed domain (hosted by a major CDN), and the encrypted Host header contains the real destination. A firewall only sees the permitted domain and allows the connection. Once the traffic reaches the CDN, it is decrypted and routed using the Host header to the actual backend.
Why CDNs?
Domain fronting relied on large CDNs and cloud platforms hosting thousands of websites behind the same edge servers and IP addresses.
Because those services shared the same infrastructure, blocking the visible front domain often meant disrupting access to many unrelated websites at the same time. Censors would not want to block sites blindly, so blocking CDNs is not an effective solution for them.
Legitimate and malicious uses
Anti-censorship tools such like Tor's meek transport, Signal, and some VPNs used domain fronting to reach users in countries where internet access was heavily restricted.
The same method was also adopted by malware authors. Command and control traffic could be disguised as connections to a trusted cloud provider, making it harder for security products to detect. APT29 (Cozy Bear) is one well known example, and MITRE ATT&CK classifies this technique as T1090.004.
The end of OG domain fronting
Major cloud providers began blocking the technique around 2018 by requiring the SNI and Host header to match, making domain fronting on platforms like Google and Amazon impossible and forcing censorship circumvention tools to leverage other techniques.
Domain fronting hasn't disappeared completely, though. Smaller CDNs, self-hosted reverse proxies, and open source implementations can still provide similar functionality where the infrastructure allows it, although they lack the scale and the "can't block us without collateral damage" advantage against censors that made the original technique so effective.
At the same time, newer approaches have emerged. Encrypted Client Hello (ECH) encrypts the SNI itself, preventing observers from seeing the destination hostname in the first place.
Encrypted Client Hello
ECH was published as RFC 9849 in March 2026. Instead of sending the real hostname in the TLS handshake, the client sends two ClientHellos. The outer ClientHello contains a public SNI that is shared by many domains, and the inner ClientHello, which contains the actual hostname, is encrypted. Only the server holding the ECH key can decrypt it and route the connection correctly. That key is published through a DNS HTTPS record.
Conceptually, this looks like domain fronting (cover name outside, real destination inside) but it is sanctioned by the provider and encrypted instead of just being hidden a layer up.
The limitations of ECH:
- It does not hide the IP, only the hostname, so if a service has its own dedicated IP, ECH provides little benefit.
- It depends on encrypted DNS (DoT/DoH). If DNS queries are still sent in plaintext, the hostname is exposed before the TLS connection even begins.
- If ECH cannot be used, clients fall back to a normal TLS handshake with a plaintext SNI.
Those weaknesses are already being exploited. In November 2024, Roskomnadzor blocked Cloudflare sites using ECH shortly after Cloudflare enabled it by default. Russia's TSPU equipment drops ClientHellos containing the ECH extension when cloudflare-ech.com is used as the outer SNI. China and Iran have instead focused on blocking encrypted DNS, removing the encryption layer ECH relies on.
Cloudflare remained the only major provider offering ECH, but support expanded. OpenSSL 4.0 and NGINX 1.29.4 both implement ECH, making self hosting possible. But if a service is not fronted by something and just sits behind its own dedicated IP address, there is still little practical privacy gain.