Bad Decisions: Google Screws Over Tools Evading Internet Censorship Regimes
from the who's-fronting-now? dept
Just as places like Russia are getting more aggressive with companies like Google and Amazon in seeking to stop online communications they can't monitor, Google made a move that really fucked over a ton of people who rely on anti-censorship tools. For years, various anti-censorship tools from Tor to GreatFire to Signal have made use of "domain fronting." That's a process by which services could get around censorship by effectively appearing to send traffic via large companies' sites, such as Google's. The link above describes the process as follows:
Domain fronting works at the application layer, using HTTPS, to communicate with a forbidden host while appearing to communicate with some other host, permitted by the censor. The key idea is the use of different domain names at different layers of communication. One domain appears on the “outside” of an HTTPS request—in the DNS request and TLS Server Name Indication—while another domain appears on the “inside”—in the HTTP Host header, invisible to the censor under HTTPS encryption. A censor, unable to distinguish fronted and nonfronted traffic to a domain, must choose between allowing circumvention traffic and blocking the domain entirely, which results in expensive collateral damage. Domain fronting is easy to deploy and use and does not require special cooperation by network intermediaries. We identify a number of hard-to-block web services, such as content delivery networks, that support domain-fronted connections and are useful for censorship circumvention. Domain fronting, in various forms, is now a circumvention workhorse.
In short, because most countries are reluctant to block all of Google, the ability to use Google for domain fronting was incredibly useful in getting around censorship. And now it's gone. Google claims that it never officially supported it, that this was a result of a planned update, and it has no intention of bringing it back:
“Domain fronting has never been a supported feature at Google,” a company representative said, “but until recently it worked because of a quirk of our software stack. 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.”
As Ars Technica notes, companies like Google may be concerned that it could lead to larger blocks that could harm customers. But, as Access Now points out, there are larger issues at stake, concerning individuals who are put at risk through such censorship:
“As a repository and organizer of the world’s information, Google sees the power of access to knowledge. Likewise, the company understands the many ingenious ways that people evade censors by piggybacking on its networks and services. There’s no ignorance excuse here: Google knows this block will levy immediate, adverse effects on human rights defenders, journalists, and others struggling to reach the open internet,” said Peter Micek, General Counsel at Access Now. “To issue this decision with a shrug of the shoulders, disclaiming responsibility, damages the company’s reputation and further fragments trust online broadly, for the foreseeable future.”
“Google has long claimed to support internet freedom around the world, and in many ways the company has been true to its beliefs. Allowing domain fronting has meant that potentially millions of people have been able to experience a freer internet and enjoy their human rights. We urge Google to remember its commitment to human rights and internet freedom and allow domain fronting to continue,” added Nathan White, Senior Legislative Manager at Access Now.
Google doesn't need to support domain fronting, and there are reasonable business reasons for not doing so. But... there are also strong human rights reasons why the company should reconsider. In the past, Google has taken principled stands on human rights. This is another time that it should seriously consider doing so.
Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.
Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.
While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.
–The Techdirt Team
Filed Under: censorship, cloud services, domain fronting, encryption, tor
Companies: google
Reader Comments
Subscribe: RSS
View by: Time | Thread
Correlation or causation?
I find it really suspicious that this comes a day after russia tries to ban telegram by blocking parts of google.
[ link to this | view in thread ]
[ link to this | view in thread ]
The Upgrade Police
It makes me wonder if there any tools that can enable someone to spoof ALL browser settings (plugins, javascript, screen size, etc - not just user-agent) so as to avoid being actively blocked out of fussy sites?
[ link to this | view in thread ]
overlord
[ link to this | view in thread ]
That was the old Google. It's Alphabet now.
Their 2 favorite letters are F and U.
[ link to this | view in thread ]
Wasn't the solution anyway.
There are a lot of people trying to figure out how to make backwards compatible security solutions. You can't do that if the problem exists at a lower level of the stack. Which it does.
The web is busted in ten thousand ways. TCP/IP is busted in just a few ways. Fix the latter, and the formers problems dwindle by an order of magnitude, just on the basis of mitigating leakage.
[ link to this | view in thread ]
[ link to this | view in thread ]
Re: Wasn't the solution anyway.
That is what TOR provides, but even that relies on a valid address on the visible envelope, and trusted relay nodes. Would you trust the Telecoms sector to provide a secure TOR like system, as that is what you are asking for.
[ link to this | view in thread ]
Timing argument is BS
This is almost certainly (99.999999% likelyhood) either exactly what they say it is, a planned rollout with changes for security reasons, or it has to do with something that happened months ago (SESTA/FOSTA or some security issue that popped up internally last year and wasn't broadcast by Alphabet because they didn't want people swooping in and exploiting before it could be fixed).
I'm not saying Alphabet is all rainbows and unicorns, they're a corporation, and they will screw you over for their bottom line, but I work in tech and you can't toss out something on a production environment this big in a few day developing it from scratch.
I will grant that they may have had it in the pipe and moved it up in response to Russia, but caused by Russia? Extremely unlikely.
[ link to this | view in thread ]
Re:
[ link to this | view in thread ]
Re: Re: Wasn't the solution anyway.
A fundamental design tenant of TOR like systems, is that trust of the carrier is not required. If it is or was required in any way, then the protocol design is by definition a failure. TOR does have some weakness's as I understand it, and it has been a while since I looked at the spec. But the goal of TOR is achievable, even if TOR itself is not the solution.
You spend 1/3rd on building the thing, you spend 1/3rd operating it, and the last 1/3rd is spent preventing thievery. We should very much like it not to be so, because it adds a tremendous demand on computational resources. But it is so.
Since IPV4 and IPV6 have no mechanism for preventing thievery, they are failures in terms of providing their designed goal. Which was to deliver an inexpensive resilient communications system. While the network may be resilient against backhoes, it isn't resilient against corruption. And without the resilience, it will eventually (and may have already) evolve into something that is more of a weapon than a facilitator of free interchange of ideas.
[ link to this | view in thread ]
Re: overlord
[ link to this | view in thread ]
Re: Wasn't the solution anyway.
There's an IETF plan to standardize something like it.
Mike: there's nothing that limits domain fronting to Google. If you think it's a good service to provide, why not hide a Tor service on https://www.techdirt.com/? You're not "too big to fail" like Google, but it's something.
[ link to this | view in thread ]
If society isn't willing to boycott companies for decisions that aren't good (for lack of a better word) then we have to just eat it. We should have imposed financial punishment when they bowed to China censorious pressure, when they accepted working with tyrannical regimes (ie: Federation Internationale de l'Automobile when they took their busines to Bahrein) etc etc.
I'm also guilty of it to some extent even though I have been trying to do my best. I stopped buying from companies that have been caught using slave labor for example. Some are easier to avoid, others are much harder.
[ link to this | view in thread ]
Re: Re: Re: Wasn't the solution anyway.
However if you widely available and fast TOR like networks, you need infrastructure on the scale of the carriers for its implementation.
As a general rule, if you introduce any broker or middleman into a secure system, you have to trust that they are not evil, or compromised. The certificate system suffers failures because of this, as do public key system if there is a key broker involved. The central problem being verification of who you are communicating with, and that requires direct public key exchange where the parties can verify each other identities as they exchange keys.
The certificate system, which is meant to be able to verify identity of the certificate user has been compromised on many occasions.
[ link to this | view in thread ]
Re:
[ link to this | view in thread ]
Google's decision
A good article here on the problem:
http://hackwolrdwide.com/domain-fronting-technique-for-hiding-malware-cc-traffic-within-a-cd n/tranning-it-hacking/2018/
[ link to this | view in thread ]
Re: Timing argument is BS
Who's making that argument?
What I'm inferring is that Google was worried about overly broad blocking, and Russia and China provide some examples of this.
[ link to this | view in thread ]
Ironic Verge link
[ link to this | view in thread ]
Every Nation eats the Paint chips it Deserves!
[ link to this | view in thread ]
Re: Re: Re: Re: Wasn't the solution anyway.
I disagree. The first commercial Internet provider was a single leased T1 line. You don't need administrative authority over layer 1 to start. You do need it over layer 3, with layer being 2 is debatable.
The remaining question is whether there is a market for semi-public capacity that isn't shit-smudged by the current ISP environment. Which I think is more a question of "when" than "if".
[ link to this | view in thread ]
Re: Re: Timing argument is BS
[ link to this | view in thread ]
Re: Google's decision
So that leaves only the other 1000 Google services that can do the same thing. Post your target on a Google Docs spreadsheet, a Google Plus post, on some page indexed in the Google search engine or cache...
[ link to this | view in thread ]
Re: Re: Wasn't the solution anyway.
There are lots of incremental hacks that are being worked on in IETF working groups. Much of it is intended to extend the life of existing infrastructure.
Sometimes you can extend the life of infrastructure past its full depreciation point. Nobody really knows whether we are there yet. And we also don't really know whether the market is calling for the next iteration of the lower levels of the stack.
But I'm better we are, and it is.
[ link to this | view in thread ]
by design, Google would be liable now
They didn't originate the communication, they may not have been the end point, but their system allowing domain fronting could have been held to have been facilitating in the communication.
[ link to this | view in thread ]
[ link to this | view in thread ]
Re:
[ link to this | view in thread ]