Bypass network security filters with CDN

Question

I read about Domain Fronting technique, it bypasses network security filters but requires a relatively complex configuration (having evil.com pointing to a.cdn.net, and good.com pointing to b.cdn.net, then we send a request to good.com while putting evil.com or a.cdn.net in the Host header).

My question is why can't we just bypass filters by using the domain a.cdn.net directly instead of evil.com (without relying on a good.com) since only evil.com is blocked in network-device based DNS requests and the SNI header of "TLS Client Hello" packet that contains evil.com ?

Answer 1

You don't need the "good" and "evil" domains (to use your terminology) to use different cdn servers (in fact, it would usually need them to use the same, but it's possible that the cdn doesn't care)

In the host header you need to place the website you want to visit (in your example evil.com, not a.cdn.net)

Yes, you could use other domains, such as "a.cdn.net" but (a) that internal name might not have an associated TLS certificate and (b) a.cdn.net would be easy to block, since nobody should be connecting there, while the point of domain fronting is that blocking "good.com" would cause collateral damage that the blocking party wants to avoid.

Answer 2

It seems that your example is more complicated than it needs to be.

For a more concrete example, GitHub Pages (*.github.io) allows domain fronting. Let's say that there is a site evil.github.io that is being blocked. This means that when you connect to the server and start the handshake, if the SNI of that handshake is evil.github.io, then your connection is reset. What you do, then, is instead handshake with the server for good.github.io, which does not get blocked, and then in the established TLS connection you ask the server for evil.github.io instead. You can try it yourself, for example with Curl:

curl -s -H "Host: evil.github.io" -H "Connection: close" "https://good.github.io/" -v

You will see that the TLS handshake happens for good.github.io (which matches the wildcard certificate that GH Pages uses), but the content that gets returned is from evil.github.io.

When the censor encounters this situation, they have the option to block good.github.io as well. The problem with this approach is that (for Github Pages specifically, and for many other domain-frontable sites) it's easy to create a good2.github.io, so they will be forced to accept the collateral damage of blocking all of github.io.

This collateral damage is the reason why domain fronting is usually talked about in the context of CDNs: by its nature, a CDN's content is embedded on many different sites. If you block a single domain on the CDN, you can still get at the content using domain fronting, and if you block the whole CDN you will also break all those other sites.

Whether such collateral damage is acceptable will depend on both the attitude of the censor, as well as the business interests of the CDN provider: for example, Google, AWS, Cloudflare, Akamai and Azure have disabled domain fronting using their services. Google and AWS specifically have done so after Roskomnadzor (RKN), the Russian censorship organization, had tried to block Telegram which was using domain fronting using those domains. RKN blocked many domains, disrupting online banking and mobile apps that used Google/AWS for their normal operations -- this was likely the reason why they disabled it. See https://en.wikipedia.org/wiki/Domain_fronting#Disabling for more on this.