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.
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:
curl -sI https://github.com
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:
<a href="https://medium.com/media/4fefecb051387720e2d22b0c85c969d4/href">https://medium.com/media/4fefecb051387720e2d22b0c85c969d4/href</a>
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.
<a href="https://medium.com/media/caf90a67285ea49d3efece48db52fc5b/href">https://medium.com/media/caf90a67285ea49d3efece48db52fc5b/href</a>
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.
Sometimes websites which use GitHub pages also use CDNs with restricted domain fronting. In this case, domain fronting is not achievable.
At the time of writing this post, it’s possible to use domain fronting with Fastly CDN. List of websites which use this CDN is here.
Similar to the example above, I randomly selected StackOverflow like a “blocked” domain and NY Times like “allowed” :
<a href="https://medium.com/media/7006db36fe8b38ad8c8aad754d90856d/href">https://medium.com/media/7006db36fe8b38ad8c8aad754d90856d/href</a>
The output:
<meta property=”og:url” content=”https://stackoverflow.com/"/>
In the first terminal, tshark shows nytimes.com and we get a response from StackOverflow. Traffic was successfully rerouted from nytimes.com and Fasty CDN to stackoverflow.com
More examples just for fun with domains under Fasty CDN (check the last link above):
<a href="https://medium.com/media/597248a6496b3f7561eccec8d50f8bb2/href">https://medium.com/media/597248a6496b3f7561eccec8d50f8bb2/href</a>
<meta property=og:url content=https://imgur.com/ />
Tshark points to drupal.org
<a href="https://medium.com/media/28941f8b8e5241c76f85cf4bd319929c/href">https://medium.com/media/28941f8b8e5241c76f85cf4bd319929c/href</a>
<meta property=”og:url” content=”https://giphy.com/">
Like it was expected, tshark shows apple.stackexchange.com
Side effects
CDNs serve thousands of different domains. As a result, censorship of a single domain may disrupt the availability of many innocent resources. It happened a year ago in Russia when the authorities were trying to block Telegram. Authorities blindly blocked all resources under CDNs used by Telegram. Many major and minor web services were unavailable. This precedent seems to have been the real reason for the ban on using this technique in AWS in GCP.