Domain Fronting in a nutshell
By: Artem Rukavytsia
Tags: Security, Censorship, Privacy, Network Security, Web Development

You’ve probably already heard about domain fronting, especially in the context of evading from government censorship by popular messaging applications like Signal and Telegram

CDNs

Brief description

Domain fronting allows bypassing censorship to a resource that may be blocked by DPI, DNS filtering or IP blocking, under the hood it relies on CDNs that host multiple domains. Neither AWS nor GCP (major CDN providers) will allow this trick to be used anymore. Google claimed that it had never been a supported feature at GCP, while Amazon stated that it was a breach of AWS Terms of Service.

How Does Domain fronting work?

Domain fronting is used to bypass censorship by making traffic look like it’s generated by a valid domain. This method is feasible because modern CDNs contain two parts that exist independently of each other. The external part is used to establish an SSL connection with a client, while the internal processes a request after traffic decryption. Rerouting to the hidden destination becomes possible at this stage.

In a normal situation, the three requests (DNS, SNI and HTTP Host Header) have the same hostname.DNS and SNI requests are sent in the plain text (it could be tracked by a censor), while the inner HTTP traffic is encrypted. Domain fronting relies on sending the same host in DNS and SNI requests and different blocked host in HTTP Host header.

Domain fronting in a nutshell

For example, domain-A, domain-B are under the same CDN, and domain-A is blocked in some country while domain-B is not. Placing valid domain-B in the SNI header and blocked domain-A in the HTTP header is the primary idea of domain fronting. As SNI is not an encrypted part of the TLS protocol, an authority could see an intention to establish a connection with a valid domain-B. CDN reads HTTP Host header with a blocked domain-A and forwards the request to the specified origin — blocked domain-A.

Experiment

The process that captures network traffic is an imitation of the censor. I prefer to use Wireshark or ngrep for this purpose.

Launch tshark in one terminal:

sudo tshark -T fields -Y ‘tcp.dstport == 443 and ssl.handshake.extensions_server_name’ -e ssl.handshake.extensions_server_name

In the second terminal run this command:

In the first terminal tshark shows the name of the site to which we have just accessed:

github.com

It’s an emulation of the request above which cURL sends:

Tshark shows the same response live above.

Now let’s try to harness domain fronting. As GCP and AWS forbade this approach, let’s use GitHub Pages for purpose of demonstration. List of websites which use GitHub pages is here. Like it was described above, the forbidden domain (randomly selected from the list above - bulma.io) must be set in HTTP Host header only, while “valid” domain under the same CDN (github.io domain — GitHub pages) must be specified in remained places.

It generates the output which proves that the response was sent by “forbidden” resource:

<meta property=”og:url” content=”https://bulma.io">

In the first terminal, tshark shows github.io — “valid” domain for a censor. It’s done.