Domain Shadowing: Leveraging Content Delivery Networks for Robust Blocking-Resistant Communications (USENIX Security 2021)

[agiix]

Domain Shadowing: Leveraging Content Delivery Networks for Robust Blocking-Resistant Communications
Mingkui Wei
https://censorbib.nymity.ch/#Wei2021a
https://www.usenix.org/conference/usenixsecurity21/presentation/wei

This paper presents a novel censorship evasion technique called Domain Shadowing, which takes advantage of the fact that CDNs allow their customers to bind their front-end domain to any back-end domain. A censored user only needs to register a new domain to a CDN service that is accessible from the censored country and bind the domain to the actual target domain, in other words the censored domain the he/she wants to visit. Within the CDN user account, a rule needs to be specified that rewrites the Host header of the incoming requests to the target domain.

Once these steps have been established, the user sends a request to the registered domain within the censored area. The request will be sent to the CDN, where the Host header will be rewritten according to the specified rule and the request will be forwarded to the target domain. The subsequent response will be delivered under the user's registered domain name.
During this process, a censor only sees an HTTPS request to the CDN, requesting the previously registered user domain and thus will not block the connection.

Additionally the author proposes the use of DfDs, which combines the efforts of domain fronting and domain shadowing.
Domain fronting achieves censorship circumvention by setting the SNI header of an HTTPS request to an allowed domain, while the host header points to a prohibited domain on the same CDN. This technique will prevent the censor from discovering, which real domain the user was requesting. Furthermore, the censor will most likely choose to not block access to the CDN, since it would simultaneously block permitted services and domains as well.
On the contrary domain shadowing offers the advantage that the desired domain doesn’t need to be hosted on the same CDN, however the shadow domain can easily be blocked, once discovered by the censor.
Therefore, the combination of domain fronting and domain shadowing can be used to achieve a more robust blocking-resistance.

This paper was the subject of the Tor anti-censorship team's reading group on 2021-04-29.
A transcript of the session can be found here:
http://meetbot.debian.net/tor-meeting/2021/tor-meeting.2021-04-29-16.00.log.html#l-65.

Thanks to the author for reviewing a draft of this summary.

[est]

Furthermore, the censor will most likely choose to not block access to the CDN, since it would simultaneously block permitted services and domains as well

Not sure about other countries but this method is proven useless for China. It was popularized in the past decade by the alternative name "collateral freedom" and the final result is CDN gets blocked or have to implement self-censor mechanism.

Some years further back, people who gets Hilary Clinton's funding claimed they have invented "unblockable information delivery" turns out it just slam webpages into zipped attachments inside emails. They also claim Gmail could not be blocked because of collateral damage. The result? Gmail gets blocked.

[wkrp]

Blog post by the author of the paper:
https://blog.torproject.org/anti-censorship-domain-shadowing

After USENIX Security 2021 happens (August 11–13, 2021), there will probably be a presentation video here:
https://www.usenix.org/conference/usenixsecurity21/presentation/wei

Further interesting points about this paper:

1. The basic deployment scenario of domain shadowing uses a front-end domain you own, but it's also possible to use a domain owned by someone else, or even a nonexistent domain. Section 3.5 gives an example of using cmu.edu as a shadow domain. It seems that you can configure almost any combination of domains in a domain binding: as long as you can arrange to have the requests delivered to the CDN edge server (which may require, for example, overriding local DNS resolution), the edge server will proxy the requests for you.
2. CDNs provide APIs to automate the creation of domain bindings. Creating a binding takes only a few seconds,so it's practical to create them on demand while browsing. The paper describes a proof-of-concept implementation (Section 4.2) using the Fastly API and a Firefox extension. When the browser tries to access a site that has not been seen before, the extension pauses to create a new domain binding for it. It requires some care, though, to preserve the security properties of the same-origin policy when a browser extension is internally rewriting domain names.

To me, this work on domain shadowing can be seen as filling a gap left by CDNBrowsing/CDNReaper, which had the limitation of only being able to access sites that were already on a CDN, and required a local database of site-to-CDN mappings. With domain shadowing, it is as if every site is on a CDN, because you make the domain bindings yourself.

Not sure about other countries but this method is proven useless for China. It was popularized in the past decade by the alternative name "collateral freedom" and the final result is CDN gets blocked or have to implement self-censor mechanism.

I wouldn't say "useless," rather "not invincible." It's a question of costs and resources. Co-location with a CDN raises the cost of blocking, but doesn't make blocking impossible. The government of China has a lot of resources (in terms of money and people, but also domestic substitutes for foreign services) which means the GFW can afford to block some things that would be too expensive for other censors.

I agree with you on the point about self-censorship by CDNs. Holowczak and Houmansadr even noted such in 2015 with Akamai (Section 3.2.1 "China-based edge servers of Akamai censor queries..."). As our circumvention systems become harder to block, the weakest link becomes network intermediaries, like CDNs and app stores.