David Fifield

Google did not give any engineering reasons at the time. That's misleading. Here's what they said:

"Domain fronting has never been a supported feature at Google, but until recently it worked because of a quirk of our software stack," a Google spokesperson explained in a statement emailed to The Register. "We're constantly evolving our network, and as part of a planned software update, domain fronting no longer works. We don't have any plans to offer it as a feature."

This might superficially sound like domain fronting stopped working accidentally, as part of other changes, but notice how carefully it's phrased. They made an update. It stopped working. Nothing in this phrasing would be false if they made a business decision to kill it and did so.

I find this explanation extremely likely for several reasons:

1. It happened just when fronting was being adopted by Signal, a high profile app that would have caught attention.

2. All the other big players made the same change, again, prompted by specific events related to anti-censorship.

https://www.bamsoftware.com/papers/fronting/

GreatFire speculated that the attacks were precipitated by the publication of an article in the Wall Street Journal that described in detail domain fronting and other “collateral freedom” techniques. The interview associated with the article also caused CloudFlare to begin matching SNI and Host header, in an apparent attempt to thwart domain fronting.

This explanation turned out to be correct.…

> your client will automatically, in plain text, transmit the full DNS name of whatever server it wants to talk to

AIUI, it's slightly better than this, because you only actually need to send the name of some domain that the server can serve, not necessarily the one you actually want to talk to. If the domain is on Cloudfront, App Engine, Heroku, etc, that means you can choose one of a billion innocuous sites to use for SNI, before connecting to the one you actually want.

This is called 'domain fronting':

https://www.bamsoftware.com/papers/fronting/

I can't quite work out the trust algebra of this, though. You don't have any cryptographic guarantee that you're connecting to the right site. But you can be sure that you're connecting to whichever server hosts the site whose name you're taking in vain. But if that server was able to serve your site all along, because it had its private key, did you ever really have any guarantee?

Probably won't help for wikipedia, though, as they're not behind a CDN.

The Chinese government has had a lot of success blocking Tor (and VPNs) most recently. You may know that all of the normal relays are publicly listed in the Tor directory, making them trivial to block by IP address. That will then require Tor users to do extra work to find bridges or configure pluggable transports for censorship circumvention, which most users may not be motivated enough to do. Censors can also try to fingerprint and block some of the circumvention methods.

In sum, Tor is not trivially or resoundingly winning the censorship arms race, even though it has some good work on censorship circumvention that's often effective in particular countries.

Some good background on this is in

https://www.bamsoftware.com/papers/thesis/

Sure -- but libp2p's network transports underneath are pluggable. There's already Websockets (/ws, think domain fronting! [1]) and Tor (/onion) transports, so there's various options for evading censorship (I personally consider bandwidth throttling a form of censorship).

[1] Domain fronting lets you use a well-established web frontend for your web service. E.g. we could host /ws nodes in Google Cloud, and to the ISP the TLS handshake looks like it's for google.com, while inside the connection there's e.g. a `Host: libp2p.googlecloud.com` header. More info: https://www.bamsoftware.com/papers/fronting/

But then again, net neutrality is a political issue! You don't solve it for good with technology.

I had a closer look at this technique after reading the article.

The cool thing about this hack is that even in the TLS Server Name Indication (SNI) extension, the front domain name shows up, and only the (encrypted) HTTP Host header shows the true covert destination.

The paper "Blocking-resistant communication through domain fronting" (https://www.bamsoftware.com/papers/fronting/) is very interesting.

One thing that I'm left wondering is if the front domain owners will be at risk being blocked if domain fronting is being done with their domain.
If so they may ask the CDN companies to block this routing behaviour.

Interesting. Reading their developer guide [1] pg 293 - CloudFront servers have all the private keys anyway, so it hardly matters—from a security perspective—which key is used to establish the TLS connection to the CloudFront endpoint. The connection between CloudFront and Signal’s own severs would be encrypted with Signal’s key.

I also found this paper on domain fronting to be a very good read - Blocking-resistant communication through domain fronting [2]

[1] - https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cf_dg.pdf#page302

[2] - https://www.bamsoftware.com/papers/fronting/