In a matter of weeks, the precious domain fronting technique used by some privacy services to hide themselves from government censors has started to crumble.
Things started going wrong in April when Google abruptly blocked fronting for its cloud App Engine platform, immediately causing problems for popular privacy messenger app Signal which had quietly been using it since 2016.
As privacy advocates fretted, Google was adamant that fronting had always been an accidental feature:
Domain fronting has never been a supported feature at Google 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.
Three weeks on and Amazon has given Signal the knock-back in a brusque email the app developer has made public:
We are happy for you to use AWS Services, but you must comply with our Service Terms. We will immediately suspend your use of CloudFront if you use third party domains without their permission to masquerade as that third party.
Losing two of the biggest Content Delivery Networks (CDNs) on the planet that allowed fronting was never going to be a good day.
But how did something that few internet users have heard of become such an issue?
If an app like Signal were to connect its users to the service’s servers directly, all censors would have to do is perform a quick DNS lookup to figure out which IP addresses to block.
Several countries have been doing this for a while – Egypt, Oman, Qatar, and UAE – hence Signal’s shift to alternatives such as fronting.
Google is right to describe the way fronting works on its service as a quirk, in that it exploits the unusual way it and Amazon process HTTPS connections to their clouds.
An HTTPS request identifies the computer it’s being sent to in up to three places: an IP address, a hostname in optional Server Name Indication (SNI) metadata, and a hostname in an HTTP host header.
The IP address and SNI header are sent in the clear, and are visible to censors, whereas the HTTP host header is shielded from prying eyes by TLS encryption.
Google and Amazon allowed services to make a TLS connection to a server that acts as a front to many others. The host header that’s invisible to censors and connects users to the service they want is processed separately, after the encrypted TLS connection is made.
Censors can only see apps communicating with Google or Amazon’s IP addresses, forcing them to choose between blocking absolutely everything using those IP addresses, just to stop the one service they want to censor, or blocking nothing.
An example of where this cat and mouse can end up is recent attempts by the Russian internet regulator (and later Iran) to block the Telegram privacy app, which reportedly caused major disruption to 19 million IP addresses for surprisingly little effect on the service.
It appears Telegram’s resistance to the Russian censors was down not to fronting but to the more old-fashioned and labour-intensive technique of IP hopping (shifting the domain as fast as censors shut them down). This left the censors chasing Telegram across subnets, with predictably heavy-handed results.
It’s not hard to see why this incident might put Google and Amazon off IP hopping’s big brother, domain fronting, even as Google claims it is all for privacy in other respects.
Another problem comes in the shape of cybercriminals, who’ve been using fronting for years to hide their command & control – indeed that may have given legitimate services the idea in the first place.
As fronting fades, privacy services will need to find other ways to keep ahead of censors, for example attempting to use ‘refraction networking’ at ISP level.
Source : Naked Security