AWS sends noise to Signal: You can't use our servers to beat censors Amazon has followed Google's example by lowering the boom on a practice called “domain fronting” that organisations like Signal use to get around government censorship. As defined by Amazon Web Services, "Domain Fronting is when a non-standard client makes a TLS/SSL connection to a certain name, but then makes a HTTPS request …
I had to spend a bit of time reading up on the treatise about "Blocking-resistant communication through domain fronting."
#1, Using an implementation detail to avoid censorship means that real owners of said services and domains can change said details at a whim.
#2. Just because TLS doesn't hide everything you want it to hide, doesn't mean you can't roll your own protocol!
Solution: roll your own protocol. DNS-alike, TLS-alike, etc. There are lots of ways to keep a distributed network up and running without ever hitting a DNS server. These guys need to look for someone with network protocol experience, not app developers.
The problem with doing that is that the bad people can (and presumably do) just say that they allow a finite list of protocols to a finite set of addresses: if your protocol & address isn't in that list then you don't get through. So, OK, you can get around that by tunnelling your protocol through one of the allowed ones to one of the allowed addresses ... which is what Signal was doing.
I don't quite get this domain fronting - you make your connection to souq.com, but send a different host header (e.g. example.com) in the (encrypted) message body. How does that message find its way to example.com? Your message would be encrypted with a key known only to souq.com, so you'd need souq.com to decrypt and forward the request like it was a proxy server.
So clearly I've misunderstood something.
I think the point is that all of the AWS / Google domains share the same pool of addresses. So you connect to an allowed one, and then once you have an encrypted tunnel you just send a header for another domain (hosted in the same pool of domains), and it says OK & forwards the request to the origin server. I think this relies on whatever you are talking to not checking that the DNS / TLS hosts and the HTTPS host header match. I think that the edge server does have access to the decrypted traffic (ie it's effectively HTTP not HTTPS by then) but presumably the content of that traffic is in fact itself encrypted, which must be the case since signal does end-to-end encryption & hence it *can't* be decrypted until it reaches the other person in the conversation.
Think of AWS and google like blocks of flats.
Signal is pressing random buttons at the front door and the door is opened through the intercom system.
They then go to a completely different flat within the building.
e.g. they buzzed flat 204, then went to flat 107.
.
AWS are now saying "No, you must go to whichever flat you buzzed"
Assuming this useful analogy is correct, you are limited to accessing the flats within the block. However I assume that this may be a very large block of flats.
When I first read it, the article seemed to be describing the way to effectively set up a VPN without using a recognised VPN protocol. Which it still seems to be, but constrained to poking around inside the chosen cloud provider.
If you don't use SNI then the server has to return the default certificate, which if the server is fronting 2000 different domains will almost certainly not be the certificate you are needing.
SNI is the thing that lets the server knows what certificate to return in order to establish the connection.
Normally a standard web server would then tie the hostname in the SNI certificate to the website being served (Host in the http header). In this case the server is actually a proxy fetching content from back-end servers, the same code is serving all websites, looking at the host header and then grabbing the real content from the real origin server. Being the same code running for all websites is how the mismatch could be 'abused'.
> Anyone know why they can not just use https without sni?
There needs to be a way for the web server to resolve the intended domain of the HTTPS request so it knows which certificate to use.
Without SNI, your server needs to rely upon a unique IP address per hosted domain. IP4 addresses are a limited resource, making that a costly proposition.
I guess SAN certificates are another option, but then you get a list of unrelated sites (including potentially, er, questionable activity sites) listed on your certificate. Try explaining that to world+dog.
And the sad thing is that AWS kind of have a point. What they are doing is sort of like using an open mail relay, which people, including me, used to do for purposes we regarded as legitimate, but other people used for horribly illegitimate purposes. AWS can't distinguish technically between good uses of this and bad, so they want to stop all uses.
(I am not sure what a bad use would be although there probably are sum, but I imagine you could use this to build encrypted tunnels out through firewalls and suck data out of organisations, for instance, and the organisations having their data vacuumed out this way might have strong words with Amazon.)
"AWS can't distinguish technically between good uses of this and bad, so they want to stop all uses."
And it also has the useful side benefit of allowing countries like China and Iran to block Signal, so they're not going to get the entire of AWS blacklisted.
Just because there's some good technical reasons for what they're doing doesn't mean we should ignore the venal reasons too.
I'm not sure what you're trying to say here. I don't think it's right to assume that Amazon / Google are somehow secretly supporters of Iran & China, because that would be political suicide on their part.
So they really have two choices: they can let Signal go ahead which would cause AWS / Google to get blacklisted, meaning that Signal stopped working in those countries, or they can tell Signal not to do this which means Signal stops working in those countries.
There is no answer I can see which keeps Signal working in those countries using this trick.
Iran, no. China, yes. It was really annoying to me to watch Google engineers whine that Google is not in China & at the same time while that they are working with the US DoD. China ran an intelligence operation that exported all of Google's code a few years back. But that doesn't affect quarterly profits today or tomorrow.
$ > human rights. It's the way of corporations all over the world.
This post has been deleted by its author
In the case of a local provider here Mythic Beasts that supply IPv6-only hosts they look at the hostname in SNI BUT CANNOT or DO NOT DECRYPT and use that to TCP proxy a possibly IPv4 connection to an IPv6 host. I have only recently got my head around it.
I have slightly abused the facility to fire up a parallel webserver also on TCP port 80 but on a specially selected IPv6 address (of my /96) even though I do have a single IPv4 address. They do validate that you control it though by a DNS TXT record or perhaps other means I forget.
Obviously you have to set your A and possibly AAAA records to their proxies.
I'd be interested to know if other providers use this method.
Do you ever notice, after someone provides a decent explanation on something, 20 other people have to give their 2 cents worth; because of course, they're smarter than everyone else... BUT the explanations of these people get gradually worse until someone starts blurting out something which is offline from the original point.
Remember, it's better to have people think you may be an idiot, than to open your mouth and remove all doubt.
I am skeptical about the cloud, too, but how would signal do something to circumvent censorship in this way without using it? The best I can come up with is that they start their own cloud and then allow this to function through their clients' sites, meaning that instead of signal being blocked, signal and all their cloud business clients that signal doesn't really want get blocked. You can't hide and be active if you aren't in a group with lots of other people, hence their cloud usage.
My point is that if you're relying on the cloud, you're relying on something capricious and that can shift at any time without warning.
Perhaps there isn't another way for Signal to accomplish its goals (although it's hard to imagine that's true -- after all, software has been successfully pulling tricks to evade censorship from long before "the cloud" existed. There are numerous available methods). But my comment was not addressing that, it was addressing that this is another example of why nobody should rely on the cloud.
Russia proving once again that money > all. Signal’s theory was nice, but also naive. Russia bet on Google/Amazon doing a simple cost:benefit analysis and won. Operating in Russia makes them more money than they get from Signal. It’s an easy choice.
Once Google folded Amazon had no choice - it would leave Google free to take all of their customers in Russia.
I don’t see Signal winning this one. They’re just too small.
It was mentioned earlier in this discussion that a key to protecting communication was to blend into the crowd. It is still possible to encrypt communication and send plain old email, for example. The remaining hurdle for correspondents is to establish covert identities, which is eminently achievable. Similarly, interactive channels can be establish peer to peer.
Yes, it is more technically challenging for users and arguably unattainable for some, but ultimately, authoritarian oppressors cannot censor all communication with blocking all communication. Even inspecting content and blocking identifiable encryption is problematic because of that key word: identifiable.
So the cat wins this round, but the mouse is still in play.
This technique is already used by many malware out there... just have built-in a feature that when it can't connect properly to the servers or the user says the app is not connecting properly it starts generating and checking millions of domain names and some of them will be online and will provide the necessary information for it to get the new IP's to have access to the service covertly.
This said I would not use the Signal because it isn't that private and secure.. the phone number is your ID... what a dumb idea! The phone number to give some trust level I would understand (is what Threema, optionally, does) but using it has a ID in the network is just dumb... because the final user doesn't really own the phone number: the phone company/ government is the real owner even if they tell you otherwise.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
