Domain Fronting Explained: What It Is, How It Works, and Why You Should Care

For years, private messaging services, gambling sites, and other platforms that were blocked by certain networks used a reliable trick to keep their content accessible: domain fronting. 

Domain fronting disguises connection requests to make it look like traffic is going to a trusted website when it’s really going somewhere else entirely. This made it popular for dodging regional internet restrictions and, in some cases, spreading malware.

In this post, we’ll break down what domain fronting is, how it works, who uses it and why, and what you can do to detect and defend against it.

What Is Domain Fronting?

Domain fronting is a method that makes a connection appear to be heading to one website when it’s actually going to another destination. The destination address routed through a CDN doesn’t match the actual backend destination.

It’s a technique that’s often used to hide command and control (C2) callbacks behind high-reputation domains, concealing them from both users and security tools. This is like communications sent from a compromised device back to a threat actor’s server.

By routing malicious traffic through a trusted domain, threat actors can make C2 communications appear completely normal, helping them to bypass firewalls, fool other monitoring tools, and stay hidden in plain sight.

Classic Domain Fronting vs. ECH

Major cloud providers largely put a stop to domain fronting in 2018, when they stopped issuing certificates that didn’t match the domain actually being requested¹.

This closed the loophole that allowed domain fronting to happen, but it hasn’t stopped threat actors from trying to send run-of-the-mill requests to malicious domains. Today, Encrypted Client Hello (ECH) helps cybercriminals to achieve the same goal.

ECH is a standardized Transport Layer Security (TLS) extension. It splits the connection request into an outer part containing a ClientHello public domain name and an encrypted inner part that contains the real destination.

As with classic domain fronting, anyone monitoring the connection can see that a device is connecting to a CDN provider like Cloudflare, but not the specific site visited.

What Is Domain Fronting Used For?

Domain fronting has a range of applications and not all are malicious. The same technique that threat actors use to evade detection can also help people maintain more privacy in situations where internet access may be monitored.

• Circumventing censorship: In places that restrict access to certain websites or services, people have historically used domain fronting to disguise the destination of traffic to maintain access. 
• Protecting journalists: Journalists have used domain fronting as part of a wider toolkit to communicate more securely and obscure the services they’re connecting to.
• Spreading malware: Threat actors use domain fronting to deliver malicious payloads to target devices by disguising the download source as a trusted domain, helping to bypass the security filters that would block or flag the connection before the malware reaches its destination.
• Data exfiltration: By routing outbound traffic through a trusted CDN domain, an attacker can use domain fronting to disguise the transmission of stolen sensitive data or credentials back to their server. 
• Resilience against takedowns: If someone discovers a C2 server and shuts it down, an attacker using domain fronting can swap the hidden destination to a different server and make it much harder to disrupt these attacks.

How Domain Fronting Works

Phase 1: Setting Up the HTTP Host Header

Domain fronting exploits a major feature of the internet’s infrastructure that most users take for granted: CDNs. 

Content delivery networks are a distributed network of servers that host content on behalf of thousands of websites simultaneously. When you visit a popular website, you’re often connecting to a CDN rather than the site’s own server. 

Because it’s a network of edge servers responsible for handling requests for multiple domains, the CDN needs two pieces of information to route traffic to the correct backend.

The first is the Server Name Indication (SNI). This is a field inside the ClientHello message that the device sends at the start of the connection. The CDN uses SNI to decide which domain’s security certificate to hand back to the client.

The second piece of data the CDN needs is the HTTP Host header. It’s also a field inside the request, and it tells the CDN which website’s backend it should forward the request to. It’s only readable once the connection has been decrypted.

A domain fronting attack starts with the client requesting the certificate for safewebsite.com via the SNI field. Once the CDN has the certificate, the client uses it to encrypt an HTTP request. This is all perfectly normal.

The bait-and-switch happens with the Host header. Instead of naming safewebsite.com, the client sets the Host header to evilwebsite.com. 

The CDN hands over a legitimate security certificate for one domain, but the request sent over the encrypted connection is for evilwebsite.com.

Phase 2: DNS Resolution and SNI in the TLS Handshake

With evilwebsite.com in the Host header of the encrypted request, the next step takes place with a Domain Name System (DNS) query. Your device is asking the internet for the IP address of a particular domain (for example, safewebsite.com).

As safewebsite.com and evilwebsite.com are both hosted on the same CDN, the DNS query resolves to the CDN’s IP address exactly as it would for any other visitor. Nothing alters or manipulates the DNS resolution itself.

When the IP address returns successfully, your device initiates a TLS handshake, which is the setup that establishes an encrypted HTTPS connection. 

During this handshake, the device includes the SNI. This tells the CDN exactly which domain the device is trying to reach (e.g., safewebsite.com), as well as which security certificate to present.

The handshake completes and CDN encrypts the connection using a certificate the CDN believes is for safewebsite.com. It’s only once that encrypted tunnel is up and running that the Host header inside the now-encrypted request gets a chance to do its work.

Phase 3: Forwarding the Request to the Origin Server

Once the client establishes the encrypted connection, the request arrives at the CDN and the misdirection is executed.

First, the CDN terminates the TLS connection. In other words, it decrypts the incoming request on its end so it can read the contents and figure out where to send it. 

In a normal connection, that Host header points to the correct destination and the CDN forwards the request to the site’s origin server without issue. In a domain fronting attack, the CDN reads the Host header and finds the malicious domain instead. 

Phase 4: Target Server Response Through the Trusted Domain Path

With the request routed to the malicious domain’s origin server, the fronter’s infrastructure is now active and in control. 

Depending on the objective, the server might issue C2 instructions to a piece of malware running on the compromised device, receive stolen data exfiltrated from the network, or deliver a malicious payload.

The response travels back across the same path, from the malicious domain’s origin server to the CDN and back to the device that made the original request, all within the same encrypted tunnel established using the legitimate domain as the front.

To any security tool monitoring outbound or inbound traffic, the entire exchange looks like a routine HTTPS conversation with the correct domain. 

Based on the IP address, the request went out to a trusted domain and a response came back from that same trusted domain. Nothing looks out of place, because the true origin and destination of the traffic hides in the HTTP Host header and never appears anywhere that security tools can see it.

Domain Fronting in Action: Practical Examples of Misdirects

People have been employing domain fronting for various purposes, from protecting free speech to enabling state-sponsored espionage. The three examples in this section illustrate how the same technique applies across the board.

Tor

Tor, or The Onion Router, sends internet traffic through a series of encrypted relays to mask users’ identities. 

While it encrypts connections, Tor lists its nodes’ IP addresses publicly, making it easy for censors in restrictive countries to identify and block connections to its relays. Tor developed a domain-fronting pluggable transport called meek to make connections to Tor relays harder for network-level blocking systems to identify. 

Rather than connect to a Tor relay, meek routes traffic through major CDN providers to make Tor connections look like ordinary HTTPS traffic to those platforms. 

Meek became a lot less effective when Google and Amazon disabled domain fronting in 2018, which forced Tor to adapt their approach to traffic obfuscation².

APT29 (Cozy Bear)

APT29, a Russian state-sponsored threat group widely attributed to Russia’s Foreign Intelligence Service (SVR)³ is one of the most well-documented examples of domain fronting for malicious purposes. 

The group used a modified version of Tor with the meek domain-fronting plugin to disguise C2 communications, making their traffic appear to be heading to trusted domains rather than their own infrastructure⁴. This helped them to maintain persistent backdoor access to targets, including US government agencies and political organizations, for extended periods without triggering detection. 

The technique was particularly effective because it blended APT29’s C2 traffic with legitimate HTTPS traffic to well-known domains. To security monitoring tools, it was indistinguishable from routine web activity.

Signal

Signal, the encrypted messaging app, historically used domain fronting to keep its service accessible to users in locations that blocked the app. Its traffic appeared to be connecting to Google infrastructure⁵, meaning blocking it could also have affected access to other Google services.

As with Tor, the approach worked until 2018, when Google and Amazon disabled domain fronting on their platforms.

Domain Fronting Detection and Monitoring Strategies

As domain fronting appears legitimate by design, it makes detection challenging. The most effective strategies focus on identifying the mismatches and anomalies that the technique inevitably creates, even if the traffic itself appears normal.

TLS vs. HTTP Mismatch

One of the most effective ways to detect domain fronting is by identifying a discrepancy between the domain in the SNI field of the TLS handshake and the domain in the HTTP Host header of the encrypted request⁶. 

In a legitimate connection, these two values match. When they don’t, it’s a signal that something might be wrong.

Security tools that can inspect both layers – the SNI visible during the handshake and the Host header revealed after TLS decryption – can flag these mismatches. You should treat any request where the SNI points to one domain and the Host header points to another as suspicious.

Full Packet Inspection and TLS Termination

Identifying a TLS/HTTP mismatch requires visibility into the encrypted portion of a request, which depends on decrypting that portion first. Full packet inspection combined with TLS termination gives security teams exactly that.

With TLS termination, HTTPS traffic is decrypted at a security checkpoint (usually a proxy or secure web gateway) before being re-encrypted and forwarded to its destination. This allows the inspection tool to read the HTTP Host header inside the request and compare it against the SNI declared during the handshake to identify discrepancies that could indicate domain fronting.

DNS and Traffic Analysis

Before establishing a connection, DNS queries reveal the domain a device is trying to reach. 

High volumes of requests to a single CDN domain, connections to CDN infrastructure from devices or users with no history of accessing those services, or DNS queries that don’t correspond to any subsequent legitimate web activity are all potential indicators of domain fronting in progress.

Combining DNS analysis with broader traffic monitoring (e.g., looking at connection frequency, data volumes, and timing patterns) gives security teams a more complete picture and improves the chances of catching fronted traffic that has slipped past other controls.

CDN Telemetry

Content delivery network providers generate detailed logs of the traffic passing through their infrastructure. Those logs can be a valuable source of detection intelligence. 

Where available, CDN telemetry can reveal mismatches between the domain used to establish a connection and the domain specified in the Host header, flagging potential fronting activity that network-level tools might miss.

Unusual spikes in traffic volume through a specific CDN, requests originating from unexpected geographic locations, or connections to CDN endpoints that don’t correspond to any known business activity are all worth scrutinizing.

Some CDN providers also offer built-in domain fronting detection and blocking as part of their security features. 

Secure Gateways and Next-Gen Firewalls

Secure web gateways and next-generation firewalls can inspect outbound traffic for domain fronting indicators, particularly where there’s a TLS and Host header mismatch. 

Unlike traditional firewalls that make decisions based on IP addresses and ports alone, next-gen firewalls operate at the application layer, giving them visibility into the content of requests rather than just their destination.

When combined with TLS termination, these tools can compare the SNI and Host header values in real time and block or flag connections where the two don’t match. They can also enforce policies that restrict outbound traffic to known, approved CDN domains, reducing the attack surface available to anyone attempting to use domain fronting against the network.

Mitigation and Prevention of Domain Fronting

From inconsistencies in how security systems validate hostnames to weaknesses in outbound traffic controls and a lack of visibility into encrypted requests, domain fronting mitigation aims to close these gaps. Here are some of the strategies used to prevent domain fronting:

• Require SNI and Host header consistency: Configure proxies, secure web gateways, and next-gen firewalls to block any outbound HTTPS request where the SNI and HTTP Host header don’t match. 
• Use provider-level controls: Major CDN and cloud providers have introduced built-in domain fronting protections. Enabling these where available adds a layer of enforcement at the infrastructure level that doesn’t depend on your own inspection capabilities.
• Restrict outbound traffic to approved destinations: Maintain an allowlist of known, legitimate CDN domains and block outbound connections to any CDN infrastructure that falls outside it to limit the range of front domains available to an attacker.
• Apply TLS inspection selectively: Deploy TLS termination on high-risk traffic categories to make encrypted Host headers readable and manage the operational complexity and privacy considerations that come with decrypting HTTPS at scale.
• Understand domain fronting patterns: Ensure you know what SNI/Host header mismatches look like in logs and alerts and configure monitoring rules to surface them proactively.
• Harden applications against misuse: Where your organization owns CDN-hosted infrastructure, configure it to reject requests where the SNI and Host header don’t match. This prevents third parties from using your domains as unwitting fronts.

Domain Fronting: Frequently Asked Questions

References:

1. Google disables “domain fronting” capability used to evade censors – Ars Technica
2. Domain Fronting Is Critical to the Open Web – Tor
3. Russian Foreign Intelligence Service (SVR) Cyber Operations: Trends and Best Practices for Network Defenders – CISA
4. Enhanced Analysis of GRIZZLY STEPPE Activity – Homeland Security
5. Doodles, stickers, and censorship circumvention for Signal Android – Signal
6. Domain Fronting Detection – Palo Alto Networks