In this post, we\u2019ll 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.<\/p>\n\n\n\n
Table of Contents<\/h4>\nDomain Fronting Basics\n<\/a>
\nWhat Is Domain Fronting?\n<\/a>
\nWhat Is Domain Fronting Used For?\n<\/a>
\nHow Domain Fronting Works\n<\/a>
\nDomain Fronting in Action: Practical Examples of Misdirects\n<\/a>
\nDomain Fronting Detection and Monitoring Strategies\n<\/a>
\nMitigation and Prevention of Domain Fronting\n<\/a>
\nDomain Fronting: Frequently Asked Questions\n<\/a>
<\/div>\n\n\n\n<\/p>\n\n\n
Domain Fronting Basics<\/h2>\n\n\n\n\n\n- What it is:<\/strong> A technique that disguises the true destination of internet traffic by making requests sent through a content delivery network (CDN) appear to go to a trusted domain while routing the request to a different destination.<\/li>\n\n\n
- What it does:<\/strong> Makes security tools see a request for a legitimate and trusted domain, while the CDN quietly forwards the connection to a different, hidden origin server once the request reaches its backend.\u00a0<\/li>\n\n\n
- Main use: <\/strong>Formerly used to help privacy tools maintain access in restricted environments, but also exploited by threat actors to hide malicious communications behind high-reputation domains.<\/li>\n\n\n
- Key risks: <\/strong>Makes malicious traffic indistinguishable from routine web activity, allowing it to bypass firewalls, evade monitoring tools, and remain undetected for extended periods.<\/li>\n\n<\/ul><\/div>\n\n\n\n
What Is Domain Fronting?<\/h2>\n\n\n\n
Domain fronting is a method that makes a connection appear to be heading to one website when it\u2019s actually going to another destination.<\/strong> The destination address routed through a CDN doesn\u2019t match the actual backend destination.<\/p>\n\n\n\nIt\u2019s a technique that\u2019s 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\u2019s server.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Classic Domain Fronting vs. ECH<\/h3>\n\n\n\n
Major cloud providers largely put a stop to domain fronting in 2018, when they stopped issuing certificates that didn\u2019t match the domain actually being requested1<\/sup>.<\/p>\n\n\n\nThis closed the loophole that allowed domain fronting to happen, but it hasn\u2019t 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.<\/p>\n\n\n\n
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.<\/strong><\/p>\n\n\n\nAs 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.<\/p>\n\n\n\n
What Is Domain Fronting Used For?<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
\n- Circumventing censorship:<\/strong> 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.\u00a0<\/li>\n\n\n\n
- Protecting journalists:<\/strong> Journalists have used domain fronting as part of a wider toolkit to communicate more securely and obscure the services they\u2019re connecting to.<\/li>\n\n\n\n
- Spreading malware: <\/strong>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.<\/li>\n\n\n\n
- Data exfiltration:<\/strong> 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.\u00a0<\/li>\n\n\n\n
- Resilience against takedowns:<\/strong> 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.<\/li>\n<\/ul>\n\n\n\n
How Domain Fronting Works<\/h2>\n\n\n\n![\"\"](\"https:\/\/www.privateinternetaccess.com\/blog\/wp-content\/uploads\/2026\/07\/How-Domain-Fronting-Work-1024x695.png\")
<\/figure>\n\n\n\nPhase 1: Setting Up the HTTP Host Header<\/h3>\n\n\n\n
Domain fronting exploits a major feature of the internet\u2019s infrastructure that most users take for granted: CDNs.\u00a0<\/p>\n\n\n\n
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\u2019re often connecting to a CDN rather than the site\u2019s own server.\u00a0<\/p>\n\n\n\n
Because it\u2019s 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.<\/p>\n\n\n\n
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\u2019s security certificate to hand back to the client.<\/p>\n\n\n\n
The second piece of data the CDN needs is the HTTP Host header. It\u2019s also a field inside the request, and it tells the CDN which website\u2019s backend it should forward the request to. It\u2019s only readable once the connection has been decrypted.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
The bait-and-switch happens with the Host header. Instead of naming safewebsite.com, the client sets the Host header to evilwebsite.com.\u00a0<\/strong><\/p>\n\n\n\nThe CDN hands over a legitimate security certificate for one domain, but the request sent over the encrypted connection is for evilwebsite.com.<\/p>\n\n\n\n
Phase 2: DNS Resolution and SNI in the TLS Handshake<\/h3>\n\n\n\n
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).<\/p>\n\n\n\n
As safewebsite.com and evilwebsite.com are both hosted on the same CDN, the DNS query resolves to the CDN\u2019s IP address exactly as it would for any other visitor. Nothing alters or manipulates the DNS resolution itself.<\/p>\n\n\n\n
When the IP address returns successfully, your device initiates a TLS handshake, which is the setup that establishes an encrypted HTTPS connection<\/a>.\u00a0<\/p>\n\n\n\nDuring 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.<\/strong><\/p>\n\n\n\nThe handshake completes and CDN encrypts the connection using a certificate the CDN believes is for safewebsite.com. It\u2019s 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.<\/p>\n\n\n\n
Phase 3: Forwarding the Request to the Origin Server<\/h3>\n\n\n\n
Once the client establishes the encrypted connection, the request arrives at the CDN and the misdirection is executed.<\/strong><\/p>\n\n\n\nFirst, 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.\u00a0<\/p>\n\n\n\n
In a normal connection, that Host header points to the correct destination and the CDN forwards the request to the site\u2019s origin server without issue. In a domain fronting attack, the CDN reads the Host header and finds the malicious domain instead.\u00a0<\/p>\n\n\n\n
Phase 4: Target Server Response Through the Trusted Domain Path<\/h3>\n\n\n\n
With the request routed to the malicious domain\u2019s origin server, the fronter\u2019s infrastructure is now active and in control.\u00a0<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
The response travels back across the same path, from the malicious domain\u2019s origin server to the CDN and back to the device that made the original request<\/strong>, all within the same encrypted tunnel established using the legitimate domain as the front.<\/p>\n\n\n\nTo any security tool monitoring outbound or inbound traffic, the entire exchange looks like a routine HTTPS conversation with the correct domain.\u00a0<\/p>\n\n\n\n
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<\/strong>.<\/p>\n\n\n\nDomain Fronting in Action: Practical Examples of Misdirects<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
Tor<\/h3>\n\n\n\n
Tor, or The Onion Router, sends internet traffic through a series of encrypted relays<\/a> to mask users\u2019 identities.\u00a0<\/p>\n\n\n\nWhile it encrypts connections, Tor lists its nodes\u2019 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.\u00a0<\/p>\n\n\n\n
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.\u00a0<\/p>\n\n\n\n
Meek became a lot less effective when Google and Amazon disabled domain fronting in 2018, which forced Tor to adapt their approach to traffic obfuscation2<\/sup>.<\/p>\n\n\n\nAPT29 (Cozy Bear)<\/h3>\n\n\n\n
APT29, a Russian state-sponsored threat group widely attributed to Russia\u2019s Foreign Intelligence Service (SVR)3<\/sup> is one of the most well-documented examples of domain fronting for malicious purposes.\u00a0<\/p>\n\n\n\nThe 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 infrastructure4<\/sup>. This helped them to maintain persistent backdoor access to targets, including US government agencies and political organizations, for extended periods without triggering detection.\u00a0<\/p>\n\n\n\nThe technique was particularly effective because it blended APT29\u2019s C2 traffic with legitimate HTTPS traffic to well-known domains. To security monitoring tools, it was indistinguishable from routine web activity.<\/p>\n\n\n\n
Signal<\/h3>\n\n\n\n
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 infrastructure5<\/sup>, meaning blocking it could also have affected access to other Google services.<\/p>\n\n\n\nAs with Tor, the approach worked until 2018, when Google and Amazon disabled domain fronting on their platforms.<\/p>\n\n\n\n
Domain Fronting Detection and Monitoring Strategies<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
TLS vs. HTTP Mismatch<\/h3>\n\n\n\n
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<\/strong> of the encrypted request6<\/sup>.\u00a0<\/p>\n\n\n\nIn a legitimate connection, these two values match. When they don\u2019t, it\u2019s a signal that something might be wrong.<\/p>\n\n\n\n
Security tools that can inspect both layers \u2013 the SNI visible during the handshake and the Host header revealed after TLS decryption \u2013 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.<\/p>\n\n\n\n
Full Packet Inspection and TLS Termination<\/h3>\n\n\n\n
Identifying a TLS\/HTTP mismatch requires visibility into the encrypted portion of a request<\/strong>, which depends on decrypting that portion first. Full packet inspection combined with TLS termination gives security teams exactly that.<\/p>\n\n\n\nWith 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.<\/p>\n\n\n\n
DNS and Traffic Analysis<\/h3>\n\n\n\n
Before establishing a connection, DNS queries reveal the domain a device is trying to reach.\u00a0<\/strong><\/p>\n\n\n\nHigh 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\u2019t correspond to any subsequent legitimate web activity are all potential indicators of domain fronting in progress.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
CDN Telemetry<\/h3>\n\n\n\n
Content delivery network providers generate detailed logs of the traffic passing through their infrastructure. Those logs can be a valuable source of detection intelligence.\u00a0<\/p>\n\n\n\n
Where available, CDN telemetry can reveal mismatches between the domain used to establish a connection and the domain specified in the Host header<\/strong>, flagging potential fronting activity that network-level tools might miss.<\/p>\n\n\n\nUnusual spikes in traffic volume through a specific CDN, requests originating from unexpected geographic locations, or connections to CDN endpoints that don\u2019t correspond to any known business activity are all worth scrutinizing.<\/p>\n\n\n\n
Some CDN providers also offer built-in domain fronting detection and blocking as part of their security features.\u00a0<\/p>\n\n\n\n
Secure Gateways and Next-Gen Firewalls<\/h3>\n\n\n\n
Secure web gateways and next-generation firewalls<\/a> can inspect outbound traffic for domain fronting indicators, particularly where there\u2019s a TLS and Host header mismatch.\u00a0<\/p>\n\n\n\nUnlike traditional firewalls that make decisions based on IP addresses<\/a> and ports alone, next-gen firewalls operate at the application layer, giving them visibility into the content of requests rather than just their destination<\/strong>.<\/p>\n\n\n\nWhen 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\u2019t 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.<\/p>\n\n\n\n
Mitigation and Prevention of Domain Fronting<\/h2>\n\n\n\n
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:<\/p>\n\n\n\n
\n- Require SNI and Host header consistency:<\/strong> Configure proxies, secure web gateways, and next-gen firewalls to block any outbound HTTPS request where the SNI and HTTP Host header don\u2019t match.\u00a0<\/li>\n\n\n\n
- Use provider-level controls: <\/strong>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\u2019t depend on your own inspection capabilities.<\/li>\n\n\n\n
- Restrict outbound traffic to approved destinations:<\/strong> 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.<\/li>\n\n\n\n
- Apply TLS inspection selectively:<\/strong> 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.<\/li>\n\n\n\n
- Understand domain fronting patterns: <\/strong>Ensure you know what SNI\/Host header mismatches look like in logs and alerts and configure monitoring rules to surface them proactively.<\/li>\n\n\n\n
- Harden applications against misuse:<\/strong> Where your organization owns CDN-hosted infrastructure, configure it to reject requests where the SNI and Host header don\u2019t match. This prevents third parties from using your domains as unwitting fronts.<\/li>\n<\/ul>\n\n\n\n
Domain Fronting: Frequently Asked Questions<\/h2>\n\n\n\nWhat is domain fronting?<\/h3>
Domain fronting is a technique that disguises the true destination of internet traffic<\/a> by making a connection appear to be heading to a trusted, high-reputation domain while routing it to another. It exploits the way content delivery networks handle HTTPS requests to hide malicious activity from users and security tools.
<\/p> <\/div> How does domain fronting work?<\/h3>
Domain fronting works by mismatching two parts of an HTTPS request<\/a> to surreptitiously reroute traffic from one destination to another on a CDN server. The domain fronter alters the HTTP Host header and SNI field to make it appear as though traffic is heading to a trusted domain when it\u2019s actually going to a malicious one.
<\/p> <\/div> Why is domain fronting used in networking and security?<\/h3>
Domain fronting had both legitimate and malicious applications<\/a> before major cloud providers shut down the technique in 2018. It was previously used by tools like Signal and Tor to maintain access in places that restricted these services. Threat actors also exploited it to conceal malicious communications, deliver malware, and exfiltrate data undetected.
<\/p> <\/div> Is domain fronting legal or allowed by major cloud providers?<\/h3>
Domain fronting is not explicitly illegal in most jurisdictions, but it violates the terms of service of most major cloud and CDN providers. Google and Amazon disabled it on their platforms<\/a> in 2018, and Microsoft Azure followed suit. Using domain fronting through these providers risks account termination and, in malicious contexts, potential criminal liability.
<\/p> <\/div> How is domain fronting different from a VPN or proxy?<\/h3>
A VPN<\/a> encrypts all traffic between your device and a VPN server, masking your activity from your ISP and other observers. A proxy reroutes traffic through an intermediary server. Domain fronting doesn\u2019t encrypt or reroute traffic in the same way. It manipulates the destination fields of an HTTPS request to disguise where traffic is going within a CDN\u2019s infrastructure.
<\/p> <\/div> Can a VPN be used as an alternative to domain fronting?<\/h3>
Yes, for most legitimate use cases. A VPN encrypts your traffic<\/a> and masks your IP address from ISPs and monitoring tools without relying on CDN infrastructure or violating provider terms of service.
<\/p> <\/div> <\/div>\n\n\n\nReferences:<\/strong><\/p>\n\n\n\n\n- Google disables \u201cdomain fronting\u201d capability used to evade censors \u2013 Ars Technica<\/a><\/li>\n\n\n\n
- Domain Fronting Is Critical to the Open Web \u2013 Tor<\/a><\/li>\n\n\n\n
- Russian Foreign Intelligence Service (SVR) Cyber Operations: Trends and Best Practices for Network Defenders \u2013 CISA<\/a><\/li>\n\n\n\n
- Enhanced Analysis of GRIZZLY STEPPE Activity \u2013 Homeland Security<\/a><\/li>\n\n\n\n
- Doodles, stickers, and censorship circumvention for Signal Android \u2013 Signal<\/a><\/li>\n\n\n\n
- Domain Fronting Detection \u2013 Palo Alto Networks<\/a><\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"
Domain Fronting Basics<\/h2>\n\n\n\n\n\n- What it is:<\/strong> A technique that disguises the true destination of internet traffic by making requests sent through a content delivery network (CDN) appear to go to a trusted domain while routing the request to a different destination.<\/li>\n\n\n
- What it does:<\/strong> Makes security tools see a request for a legitimate and trusted domain, while the CDN quietly forwards the connection to a different, hidden origin server once the request reaches its backend.\u00a0<\/li>\n\n\n
- Main use: <\/strong>Formerly used to help privacy tools maintain access in restricted environments, but also exploited by threat actors to hide malicious communications behind high-reputation domains.<\/li>\n\n\n
- Key risks: <\/strong>Makes malicious traffic indistinguishable from routine web activity, allowing it to bypass firewalls, evade monitoring tools, and remain undetected for extended periods.<\/li>\n\n<\/ul><\/div>\n\n\n\n
What Is Domain Fronting?<\/h2>\n\n\n\n
Domain fronting is a method that makes a connection appear to be heading to one website when it\u2019s actually going to another destination.<\/strong> The destination address routed through a CDN doesn\u2019t match the actual backend destination.<\/p>\n\n\n\nIt\u2019s a technique that\u2019s 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\u2019s server.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
Classic Domain Fronting vs. ECH<\/h3>\n\n\n\n
Major cloud providers largely put a stop to domain fronting in 2018, when they stopped issuing certificates that didn\u2019t match the domain actually being requested1<\/sup>.<\/p>\n\n\n\nThis closed the loophole that allowed domain fronting to happen, but it hasn\u2019t 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.<\/p>\n\n\n\n
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.<\/strong><\/p>\n\n\n\nAs 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.<\/p>\n\n\n\n
What Is Domain Fronting Used For?<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
\n- Circumventing censorship:<\/strong> 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.\u00a0<\/li>\n\n\n\n
- Protecting journalists:<\/strong> Journalists have used domain fronting as part of a wider toolkit to communicate more securely and obscure the services they\u2019re connecting to.<\/li>\n\n\n\n
- Spreading malware: <\/strong>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.<\/li>\n\n\n\n
- Data exfiltration:<\/strong> 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.\u00a0<\/li>\n\n\n\n
- Resilience against takedowns:<\/strong> 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.<\/li>\n<\/ul>\n\n\n\n
How Domain Fronting Works<\/h2>\n\n\n\n<\/figure>\n\n\n\nPhase 1: Setting Up the HTTP Host Header<\/h3>\n\n\n\n
Domain fronting exploits a major feature of the internet\u2019s infrastructure that most users take for granted: CDNs.\u00a0<\/p>\n\n\n\n
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\u2019re often connecting to a CDN rather than the site\u2019s own server.\u00a0<\/p>\n\n\n\n
Because it\u2019s 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.<\/p>\n\n\n\n
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\u2019s security certificate to hand back to the client.<\/p>\n\n\n\n
The second piece of data the CDN needs is the HTTP Host header. It\u2019s also a field inside the request, and it tells the CDN which website\u2019s backend it should forward the request to. It\u2019s only readable once the connection has been decrypted.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
The bait-and-switch happens with the Host header. Instead of naming safewebsite.com, the client sets the Host header to evilwebsite.com.\u00a0<\/strong><\/p>\n\n\n\nThe CDN hands over a legitimate security certificate for one domain, but the request sent over the encrypted connection is for evilwebsite.com.<\/p>\n\n\n\n
Phase 2: DNS Resolution and SNI in the TLS Handshake<\/h3>\n\n\n\n
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).<\/p>\n\n\n\n
As safewebsite.com and evilwebsite.com are both hosted on the same CDN, the DNS query resolves to the CDN\u2019s IP address exactly as it would for any other visitor. Nothing alters or manipulates the DNS resolution itself.<\/p>\n\n\n\n
When the IP address returns successfully, your device initiates a TLS handshake, which is the setup that establishes an encrypted HTTPS connection<\/a>.\u00a0<\/p>\n\n\n\nDuring 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.<\/strong><\/p>\n\n\n\nThe handshake completes and CDN encrypts the connection using a certificate the CDN believes is for safewebsite.com. It\u2019s 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.<\/p>\n\n\n\n
Phase 3: Forwarding the Request to the Origin Server<\/h3>\n\n\n\n
Once the client establishes the encrypted connection, the request arrives at the CDN and the misdirection is executed.<\/strong><\/p>\n\n\n\nFirst, 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.\u00a0<\/p>\n\n\n\n
In a normal connection, that Host header points to the correct destination and the CDN forwards the request to the site\u2019s origin server without issue. In a domain fronting attack, the CDN reads the Host header and finds the malicious domain instead.\u00a0<\/p>\n\n\n\n
Phase 4: Target Server Response Through the Trusted Domain Path<\/h3>\n\n\n\n
With the request routed to the malicious domain\u2019s origin server, the fronter\u2019s infrastructure is now active and in control.\u00a0<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
The response travels back across the same path, from the malicious domain\u2019s origin server to the CDN and back to the device that made the original request<\/strong>, all within the same encrypted tunnel established using the legitimate domain as the front.<\/p>\n\n\n\nTo any security tool monitoring outbound or inbound traffic, the entire exchange looks like a routine HTTPS conversation with the correct domain.\u00a0<\/p>\n\n\n\n
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<\/strong>.<\/p>\n\n\n\nDomain Fronting in Action: Practical Examples of Misdirects<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
Tor<\/h3>\n\n\n\n
Tor, or The Onion Router, sends internet traffic through a series of encrypted relays<\/a> to mask users\u2019 identities.\u00a0<\/p>\n\n\n\nWhile it encrypts connections, Tor lists its nodes\u2019 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.\u00a0<\/p>\n\n\n\n
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.\u00a0<\/p>\n\n\n\n
Meek became a lot less effective when Google and Amazon disabled domain fronting in 2018, which forced Tor to adapt their approach to traffic obfuscation2<\/sup>.<\/p>\n\n\n\nAPT29 (Cozy Bear)<\/h3>\n\n\n\n
APT29, a Russian state-sponsored threat group widely attributed to Russia\u2019s Foreign Intelligence Service (SVR)3<\/sup> is one of the most well-documented examples of domain fronting for malicious purposes.\u00a0<\/p>\n\n\n\nThe 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 infrastructure4<\/sup>. This helped them to maintain persistent backdoor access to targets, including US government agencies and political organizations, for extended periods without triggering detection.\u00a0<\/p>\n\n\n\nThe technique was particularly effective because it blended APT29\u2019s C2 traffic with legitimate HTTPS traffic to well-known domains. To security monitoring tools, it was indistinguishable from routine web activity.<\/p>\n\n\n\n
Signal<\/h3>\n\n\n\n
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 infrastructure5<\/sup>, meaning blocking it could also have affected access to other Google services.<\/p>\n\n\n\nAs with Tor, the approach worked until 2018, when Google and Amazon disabled domain fronting on their platforms.<\/p>\n\n\n\n
Domain Fronting Detection and Monitoring Strategies<\/h2>\n\n\n\n
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.<\/p>\n\n\n\n
TLS vs. HTTP Mismatch<\/h3>\n\n\n\n
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<\/strong> of the encrypted request6<\/sup>.\u00a0<\/p>\n\n\n\nIn a legitimate connection, these two values match. When they don\u2019t, it\u2019s a signal that something might be wrong.<\/p>\n\n\n\n
Security tools that can inspect both layers \u2013 the SNI visible during the handshake and the Host header revealed after TLS decryption \u2013 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.<\/p>\n\n\n\n
Full Packet Inspection and TLS Termination<\/h3>\n\n\n\n
Identifying a TLS\/HTTP mismatch requires visibility into the encrypted portion of a request<\/strong>, which depends on decrypting that portion first. Full packet inspection combined with TLS termination gives security teams exactly that.<\/p>\n\n\n\nWith 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.<\/p>\n\n\n\n
DNS and Traffic Analysis<\/h3>\n\n\n\n
Before establishing a connection, DNS queries reveal the domain a device is trying to reach.\u00a0<\/strong><\/p>\n\n\n\nHigh 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\u2019t correspond to any subsequent legitimate web activity are all potential indicators of domain fronting in progress.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
CDN Telemetry<\/h3>\n\n\n\n
Content delivery network providers generate detailed logs of the traffic passing through their infrastructure. Those logs can be a valuable source of detection intelligence.\u00a0<\/p>\n\n\n\n
Where available, CDN telemetry can reveal mismatches between the domain used to establish a connection and the domain specified in the Host header<\/strong>, flagging potential fronting activity that network-level tools might miss.<\/p>\n\n\n\nUnusual spikes in traffic volume through a specific CDN, requests originating from unexpected geographic locations, or connections to CDN endpoints that don\u2019t correspond to any known business activity are all worth scrutinizing.<\/p>\n\n\n\n
Some CDN providers also offer built-in domain fronting detection and blocking as part of their security features.\u00a0<\/p>\n\n\n\n
Secure Gateways and Next-Gen Firewalls<\/h3>\n\n\n\n
Secure web gateways and next-generation firewalls<\/a> can inspect outbound traffic for domain fronting indicators, particularly where there\u2019s a TLS and Host header mismatch.\u00a0<\/p>\n\n\n\nUnlike traditional firewalls that make decisions based on IP addresses<\/a> and ports alone, next-gen firewalls operate at the application layer, giving them visibility into the content of requests rather than just their destination<\/strong>.<\/p>\n\n\n\nWhen 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\u2019t 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.<\/p>\n\n\n\n
Mitigation and Prevention of Domain Fronting<\/h2>\n\n\n\n
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:<\/p>\n\n\n\n
\n- Require SNI and Host header consistency:<\/strong> Configure proxies, secure web gateways, and next-gen firewalls to block any outbound HTTPS request where the SNI and HTTP Host header don\u2019t match.\u00a0<\/li>\n\n\n\n
- Use provider-level controls: <\/strong>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\u2019t depend on your own inspection capabilities.<\/li>\n\n\n\n
- Restrict outbound traffic to approved destinations:<\/strong> 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.<\/li>\n\n\n\n
- Apply TLS inspection selectively:<\/strong> 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.<\/li>\n\n\n\n
- Understand domain fronting patterns: <\/strong>Ensure you know what SNI\/Host header mismatches look like in logs and alerts and configure monitoring rules to surface them proactively.<\/li>\n\n\n\n
- Harden applications against misuse:<\/strong> Where your organization owns CDN-hosted infrastructure, configure it to reject requests where the SNI and Host header don\u2019t match. This prevents third parties from using your domains as unwitting fronts.<\/li>\n<\/ul>\n\n\n\n
Domain Fronting: Frequently Asked Questions<\/h2>\n\n\n\nWhat is domain fronting?<\/h3>
Domain fronting is a technique that disguises the true destination of internet traffic<\/a> by making a connection appear to be heading to a trusted, high-reputation domain while routing it to another. It exploits the way content delivery networks handle HTTPS requests to hide malicious activity from users and security tools.
<\/p> <\/div> How does domain fronting work?<\/h3>
Domain fronting works by mismatching two parts of an HTTPS request<\/a> to surreptitiously reroute traffic from one destination to another on a CDN server. The domain fronter alters the HTTP Host header and SNI field to make it appear as though traffic is heading to a trusted domain when it\u2019s actually going to a malicious one.
<\/p> <\/div> Why is domain fronting used in networking and security?<\/h3>
Domain fronting had both legitimate and malicious applications<\/a> before major cloud providers shut down the technique in 2018. It was previously used by tools like Signal and Tor to maintain access in places that restricted these services. Threat actors also exploited it to conceal malicious communications, deliver malware, and exfiltrate data undetected.
<\/p> <\/div> Is domain fronting legal or allowed by major cloud providers?<\/h3>
Domain fronting is not explicitly illegal in most jurisdictions, but it violates the terms of service of most major cloud and CDN providers. Google and Amazon disabled it on their platforms<\/a> in 2018, and Microsoft Azure followed suit. Using domain fronting through these providers risks account termination and, in malicious contexts, potential criminal liability.
<\/p> <\/div> How is domain fronting different from a VPN or proxy?<\/h3>
A VPN<\/a> encrypts all traffic between your device and a VPN server, masking your activity from your ISP and other observers. A proxy reroutes traffic through an intermediary server. Domain fronting doesn\u2019t encrypt or reroute traffic in the same way. It manipulates the destination fields of an HTTPS request to disguise where traffic is going within a CDN\u2019s infrastructure.
<\/p> <\/div> Can a VPN be used as an alternative to domain fronting?<\/h3>
Yes, for most legitimate use cases. A VPN encrypts your traffic<\/a> and masks your IP address from ISPs and monitoring tools without relying on CDN infrastructure or violating provider terms of service.
<\/p> <\/div> <\/div>\n\n\n\nReferences:<\/strong><\/p>\n\n\n\n\n- Google disables \u201cdomain fronting\u201d capability used to evade censors \u2013 Ars Technica<\/a><\/li>\n\n\n\n
- Domain Fronting Is Critical to the Open Web \u2013 Tor<\/a><\/li>\n\n\n\n
- Russian Foreign Intelligence Service (SVR) Cyber Operations: Trends and Best Practices for Network Defenders \u2013 CISA<\/a><\/li>\n\n\n\n
- Enhanced Analysis of GRIZZLY STEPPE Activity \u2013 Homeland Security<\/a><\/li>\n\n\n\n
- Doodles, stickers, and censorship circumvention for Signal Android \u2013 Signal<\/a><\/li>\n\n\n\n
- Domain Fronting Detection \u2013 Palo Alto Networks<\/a><\/li>\n<\/ol>\n","protected":false},"excerpt":{"rendered":"
What Is Domain Fronting?<\/h2>\n\n\n\n
Domain fronting is a method that makes a connection appear to be heading to one website when it\u2019s actually going to another destination.<\/strong> The destination address routed through a CDN doesn\u2019t match the actual backend destination.<\/p>\n\n\n\n It\u2019s a technique that\u2019s 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\u2019s server.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Major cloud providers largely put a stop to domain fronting in 2018, when they stopped issuing certificates that didn\u2019t match the domain actually being requested1<\/sup>.<\/p>\n\n\n\n This closed the loophole that allowed domain fronting to happen, but it hasn\u2019t 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.<\/p>\n\n\n\n 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.<\/strong><\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Domain fronting exploits a major feature of the internet\u2019s infrastructure that most users take for granted: CDNs.\u00a0<\/p>\n\n\n\n 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\u2019re often connecting to a CDN rather than the site\u2019s own server.\u00a0<\/p>\n\n\n\n Because it\u2019s 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.<\/p>\n\n\n\n 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\u2019s security certificate to hand back to the client.<\/p>\n\n\n\n The second piece of data the CDN needs is the HTTP Host header. It\u2019s also a field inside the request, and it tells the CDN which website\u2019s backend it should forward the request to. It\u2019s only readable once the connection has been decrypted.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n The bait-and-switch happens with the Host header. Instead of naming safewebsite.com, the client sets the Host header to evilwebsite.com.\u00a0<\/strong><\/p>\n\n\n\n The CDN hands over a legitimate security certificate for one domain, but the request sent over the encrypted connection is for evilwebsite.com.<\/p>\n\n\n\n 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).<\/p>\n\n\n\n As safewebsite.com and evilwebsite.com are both hosted on the same CDN, the DNS query resolves to the CDN\u2019s IP address exactly as it would for any other visitor. Nothing alters or manipulates the DNS resolution itself.<\/p>\n\n\n\n When the IP address returns successfully, your device initiates a TLS handshake, which is the setup that establishes an encrypted HTTPS connection<\/a>.\u00a0<\/p>\n\n\n\n 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.<\/strong><\/p>\n\n\n\n The handshake completes and CDN encrypts the connection using a certificate the CDN believes is for safewebsite.com. It\u2019s 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.<\/p>\n\n\n\n Once the client establishes the encrypted connection, the request arrives at the CDN and the misdirection is executed.<\/strong><\/p>\n\n\n\n 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.\u00a0<\/p>\n\n\n\n In a normal connection, that Host header points to the correct destination and the CDN forwards the request to the site\u2019s origin server without issue. In a domain fronting attack, the CDN reads the Host header and finds the malicious domain instead.\u00a0<\/p>\n\n\n\n With the request routed to the malicious domain\u2019s origin server, the fronter\u2019s infrastructure is now active and in control.\u00a0<\/p>\n\n\n\n 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.<\/p>\n\n\n\n The response travels back across the same path, from the malicious domain\u2019s origin server to the CDN and back to the device that made the original request<\/strong>, all within the same encrypted tunnel established using the legitimate domain as the front.<\/p>\n\n\n\n To any security tool monitoring outbound or inbound traffic, the entire exchange looks like a routine HTTPS conversation with the correct domain.\u00a0<\/p>\n\n\n\n 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<\/strong>.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Tor, or The Onion Router, sends internet traffic through a series of encrypted relays<\/a> to mask users\u2019 identities.\u00a0<\/p>\n\n\n\n While it encrypts connections, Tor lists its nodes\u2019 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.\u00a0<\/p>\n\n\n\n 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.\u00a0<\/p>\n\n\n\n Meek became a lot less effective when Google and Amazon disabled domain fronting in 2018, which forced Tor to adapt their approach to traffic obfuscation2<\/sup>.<\/p>\n\n\n\n APT29, a Russian state-sponsored threat group widely attributed to Russia\u2019s Foreign Intelligence Service (SVR)3<\/sup> is one of the most well-documented examples of domain fronting for malicious purposes.\u00a0<\/p>\n\n\n\n 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 infrastructure4<\/sup>. This helped them to maintain persistent backdoor access to targets, including US government agencies and political organizations, for extended periods without triggering detection.\u00a0<\/p>\n\n\n\n The technique was particularly effective because it blended APT29\u2019s C2 traffic with legitimate HTTPS traffic to well-known domains. To security monitoring tools, it was indistinguishable from routine web activity.<\/p>\n\n\n\n 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 infrastructure5<\/sup>, meaning blocking it could also have affected access to other Google services.<\/p>\n\n\n\n As with Tor, the approach worked until 2018, when Google and Amazon disabled domain fronting on their platforms.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n 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<\/strong> of the encrypted request6<\/sup>.\u00a0<\/p>\n\n\n\n In a legitimate connection, these two values match. When they don\u2019t, it\u2019s a signal that something might be wrong.<\/p>\n\n\n\n Security tools that can inspect both layers \u2013 the SNI visible during the handshake and the Host header revealed after TLS decryption \u2013 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.<\/p>\n\n\n\n Identifying a TLS\/HTTP mismatch requires visibility into the encrypted portion of a request<\/strong>, which depends on decrypting that portion first. Full packet inspection combined with TLS termination gives security teams exactly that.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Before establishing a connection, DNS queries reveal the domain a device is trying to reach.\u00a0<\/strong><\/p>\n\n\n\n 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\u2019t correspond to any subsequent legitimate web activity are all potential indicators of domain fronting in progress.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n Content delivery network providers generate detailed logs of the traffic passing through their infrastructure. Those logs can be a valuable source of detection intelligence.\u00a0<\/p>\n\n\n\n Where available, CDN telemetry can reveal mismatches between the domain used to establish a connection and the domain specified in the Host header<\/strong>, flagging potential fronting activity that network-level tools might miss.<\/p>\n\n\n\n Unusual spikes in traffic volume through a specific CDN, requests originating from unexpected geographic locations, or connections to CDN endpoints that don\u2019t correspond to any known business activity are all worth scrutinizing.<\/p>\n\n\n\n Some CDN providers also offer built-in domain fronting detection and blocking as part of their security features.\u00a0<\/p>\n\n\n\n Secure web gateways and next-generation firewalls<\/a> can inspect outbound traffic for domain fronting indicators, particularly where there\u2019s a TLS and Host header mismatch.\u00a0<\/p>\n\n\n\n Unlike traditional firewalls that make decisions based on IP addresses<\/a> and ports alone, next-gen firewalls operate at the application layer, giving them visibility into the content of requests rather than just their destination<\/strong>.<\/p>\n\n\n\n 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\u2019t 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.<\/p>\n\n\n\n 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:<\/p>\n\n\n\n Domain fronting is a technique that disguises the true destination of internet traffic<\/a> by making a connection appear to be heading to a trusted, high-reputation domain while routing it to another. It exploits the way content delivery networks handle HTTPS requests to hide malicious activity from users and security tools. Domain fronting works by mismatching two parts of an HTTPS request<\/a> to surreptitiously reroute traffic from one destination to another on a CDN server. The domain fronter alters the HTTP Host header and SNI field to make it appear as though traffic is heading to a trusted domain when it\u2019s actually going to a malicious one. Domain fronting had both legitimate and malicious applications<\/a> before major cloud providers shut down the technique in 2018. It was previously used by tools like Signal and Tor to maintain access in places that restricted these services. Threat actors also exploited it to conceal malicious communications, deliver malware, and exfiltrate data undetected. Domain fronting is not explicitly illegal in most jurisdictions, but it violates the terms of service of most major cloud and CDN providers. Google and Amazon disabled it on their platforms<\/a> in 2018, and Microsoft Azure followed suit. Using domain fronting through these providers risks account termination and, in malicious contexts, potential criminal liability. A VPN<\/a> encrypts all traffic between your device and a VPN server, masking your activity from your ISP and other observers. A proxy reroutes traffic through an intermediary server. Domain fronting doesn\u2019t encrypt or reroute traffic in the same way. It manipulates the destination fields of an HTTPS request to disguise where traffic is going within a CDN\u2019s infrastructure. Yes, for most legitimate use cases. A VPN encrypts your traffic<\/a> and masks your IP address from ISPs and monitoring tools without relying on CDN infrastructure or violating provider terms of service. References:<\/strong><\/p>\n\n\n\nClassic Domain Fronting vs. ECH<\/h3>\n\n\n\n
What Is Domain Fronting Used For?<\/h2>\n\n\n\n
\n
How Domain Fronting Works<\/h2>\n\n\n\n
<\/figure>\n\n\n\nPhase 1: Setting Up the HTTP Host Header<\/h3>\n\n\n\n
Phase 2: DNS Resolution and SNI in the TLS Handshake<\/h3>\n\n\n\n
Phase 3: Forwarding the Request to the Origin Server<\/h3>\n\n\n\n
Phase 4: Target Server Response Through the Trusted Domain Path<\/h3>\n\n\n\n
Domain Fronting in Action: Practical Examples of Misdirects<\/h2>\n\n\n\n
Tor<\/h3>\n\n\n\n
APT29 (Cozy Bear)<\/h3>\n\n\n\n
Signal<\/h3>\n\n\n\n
Domain Fronting Detection and Monitoring Strategies<\/h2>\n\n\n\n
TLS vs. HTTP Mismatch<\/h3>\n\n\n\n
Full Packet Inspection and TLS Termination<\/h3>\n\n\n\n
DNS and Traffic Analysis<\/h3>\n\n\n\n
CDN Telemetry<\/h3>\n\n\n\n
Secure Gateways and Next-Gen Firewalls<\/h3>\n\n\n\n
Mitigation and Prevention of Domain Fronting<\/h2>\n\n\n\n
\n
Domain Fronting: Frequently Asked Questions<\/h2>\n\n\n\n
What is domain fronting?<\/h3>
<\/p> <\/div> How does domain fronting work?<\/h3>
<\/p> <\/div> Why is domain fronting used in networking and security?<\/h3>
<\/p> <\/div> Is domain fronting legal or allowed by major cloud providers?<\/h3>
<\/p> <\/div> How is domain fronting different from a VPN or proxy?<\/h3>
<\/p> <\/div> Can a VPN be used as an alternative to domain fronting?<\/h3>
<\/p> <\/div> <\/div>\n\n\n\n\n