Google’s App Engine may not have been designed to provide a way for developers to evade censors, but for the past few years it has offered one, via a technique known as domain fronting. By wrapping communications to a service with a request to an otherwise innocuous domain or IP address range such as Google’s, application developers can conceal requests to domains otherwise blocked by state or corporate censors. It’s a method that has been used both for good and ill—adopted by Signal, the anti-Chinese censorship service GreatFire.org, plugins for the Tor anonymizing network, some virtual private network providers, and by an alleged Russian state-funded malware campaign to obfuscate Tor-based data theft.
But on April 13, members of the Tor Project noticed that domain fronting had become broken. The reason, according to a report by The Verge’s Russell Brandom, is that Google made changes to the company’s network architecture that had been in the works for some time. A Google representative told Brandom that domain fronting had never been officially supported by Google, and it only worked until last week “because of a quirk of our software stack… as part of a planned software update, domain fronting no longer works. We don’t have any plans to offer it as a feature.”
Ars attempted to contact Google, but we’ve received no response as of press time.
Domain fronting uses a manipulation of the secure HTTP Web protocol (HTTPS) and the Transport Layer Security (TLS) standard to help fool deep packet inspection systems and firewall rules about the intended destination of a Web request and to exploit the functionality of content delivery networks (CDNs). Domain names show up three times during a Web request—as part of a DNS query for the IP address of the site, in the Server Name Indication (SNI) extension of TLS (which tells a server with multiple sites which domain the traffic is for), and in the HTTP “host” header of the Web request. For HTTP traffic, all three of those instances of the domain name are visible to a censor’s network gear; when surfing an HTTPS site, the HTTP header is encrypted.
In a domain fronting scheme, the DNS request and SNI extension use the domain name of an unblocked host, but the HTTPS header contains the actual destination—which the request is then forwarded to, as long as it’s part of the same CDN. That destination is usually a proxy server, VPN gateway, or a Tor bridge. On Google, that proxy could be on an AppEngine host; on major CDN networks, it could be hosted on any server that is a paying customer. To anyone sitting between the client and the CDN, the traffic appears to be going to a harmless site, but it is, in fact, getting re-routed to its intended location.
There’s a straightforward reason Google and other cloud and Web service providers don’t intentionally support domain fronting: the potential damage to their business they would face if their networks were blocked as a result. “We don’t support domain fronting,” Cloudflare CEO and co-founder Matthew Prince said in an email to Ars. “Doing so would put our traditional customers at risk as it would mask banned traffic behind their domains.”
And that may be part of why Google has made changes that have broken domain fronting based on Google’s own internal CDN—increases in censorship of encrypted communications tools have had a major impact on Google’s other paying customers.
Telegram and Zello were recently ordered blocked by Roskomnadzor, Russia’s telecommunications authority, and the blocked addresses in that effort rapidly expanded to encompass Google and Amazon Web Services addresses as Telegram users started using cloud-based proxies. When Amazon reportedly asked Zello to stop hosting proxies on AWS, the service moved to Google. And many Telegram users in Russia have been using proxies on various cloud services to evade censorship. With the loss of domain fronting, users are forced to point at specific IP addresses for proxies in the cloud—addresses that censors can block wholesale.
https://arstechnica.com/?p=1296267