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.
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. CloudFlare said:
Among other network service providers, it's clear domain fronting could be awkward. "Cloudflare does not support domain fronting," a Cloudflare spokesperson said in an email to The Register. "Doing so would put our traditional customers at risk as it would mask banned traffic behind their domains."
Note that their explanation of why they killed it would also apply to encrypted SNI.
3. I worked at Google for a long time and am very familiar with their serving infrastructure. I remember noticing that resolved hostname and host header didn't have to match a decade or more ago. This ability lasted a very long time, right up until the moment people started using it in ways that upset governments. Then it went poof.
I can believe that these particular 4 players might have had a change of heart. Mozilla doesn't run any CDN or third party web services of note, and has nothing to lose from implementing this. Nor does Apple. Cloudflare and Fastly are both small firms who might have genuinely changed their minds, although if they have they should state explicitly that they are newly willing to let their "traditional customers mask banned traffic".
But I'm also not naive: it's possible some people are thinking, better ask for forgiveness than permission.
> "Doing so would put our traditional customers at risk as it would mask banned traffic behind their domains."
> Note that their explanation of why they killed it would also apply to encrypted SNI.
I'd say that's an interesting interpretation. What they likely meant is that if govs/orgs want to block X and X starts using domain fronting via domain Y, there's a chance Y starts getting blocked. (basic SNI/DNS filtering) The same idea does not apply to the encrypted SNI - there's no damage to a random domain, unless the whole provider range gets blocked.
But the circumvention can use any domain and switch repeatedly, or dump lots of them using various techniques and randomly select. It doesn't need to be the case that domain Y is static.
In particular, note that encrypted SNI could just be blocked at the network level, thus forcing fallback to regular old TLS. But domain fronting can't be blocked like that.
> It doesn't need to be the case that domain Y is static.
That's true, but I don't think it's relevant to what the providers want to prevent. Even if the domain changes based on some pool, if Y is used at some point, Y could be blocked as a collateral damage.
Since Y pays the provider, the provider cares about them not being blocked because of a functionality they enable.
"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. CloudFlare said:
Among other network service providers, it's clear domain fronting could be awkward. "Cloudflare does not support domain fronting," a Cloudflare spokesperson said in an email to The Register. "Doing so would put our traditional customers at risk as it would mask banned traffic behind their domains."
Note that their explanation of why they killed it would also apply to encrypted SNI.
3. I worked at Google for a long time and am very familiar with their serving infrastructure. I remember noticing that resolved hostname and host header didn't have to match a decade or more ago. This ability lasted a very long time, right up until the moment people started using it in ways that upset governments. Then it went poof.
I can believe that these particular 4 players might have had a change of heart. Mozilla doesn't run any CDN or third party web services of note, and has nothing to lose from implementing this. Nor does Apple. Cloudflare and Fastly are both small firms who might have genuinely changed their minds, although if they have they should state explicitly that they are newly willing to let their "traditional customers mask banned traffic".
But I'm also not naive: it's possible some people are thinking, better ask for forgiveness than permission.