Couldn't they ask people to donate their AWS instances or a portion of their webserver (or domain) resources to running a small outward facing webserver as a dummy, making the domain look like its a real website (eCommerce etc) and then passing Signal data through a Shadowsocks (or something similar) proxy? Couldn't they develop an AMI that they hold the keys to that people could deploy with ease?
Amazon threatens to suspend Signal's AWS account over censorship circumvention
101–110 of 519 posts
Re: Amazon threatens to suspend Signal's AWS account over censorship circumvention
#102They're spoofing identity of non-consenting parties. The cause is noble, but it isn't what the headline would imply. Amazon isn't saying "You can't host encrypted services on our platform", they are saying "You can't use TLS and load balancing hacks to pretend to be us in oppresive countries". And >The idea behind domain fronting was that to block a single site, you’d have to block the rest of the internet as well. I…
I agree. The intent is noble, but this headline makes Amazon look like the bad guy for disapproving unauthorized use of one of their domains, which is quite reasonable.
Hardly reasonable. Domains are (in reality, if not in legislative fantasy) property of ICANN and merely rented by everyone else.
Re: Amazon threatens to suspend Signal's AWS account over censorship circumvention
#103This is nothing to do with censorship. AWS has many clients and does not want its network to be blocked because of a single customer. Tough for Signal but that's how it is when dealing with businesses (especially one that so many others rely on). The same thing just happened with Telegram in Russia which explains the preemptive messages: https://arstechnica.com/information-technology/2018/04/in-ef...
I wonder if that means AWS, Google, etc oppose measures like encrypted SNI, since it's more likely to get their entire IP range banned by authoritarian governments.
Re: Amazon threatens to suspend Signal's AWS account over censorship circumvention
#104Earlier quoted context omitted.
You can’t really stop someone from domain fronting on any CDN. This is like “maybe you should have not talked about this on HN”. :)
Exactly, bragging about this hack made them do something about it.
The post that alerted AWS was submitted by HN user hapnin, who I don't believe has anything to do with Signal.
Re: Amazon threatens to suspend Signal's AWS account over censorship circumvention
#105Earlier quoted context omitted.
What part of the post shows they feel entitled to it?
The fact that they posted the e-mail from Amazon, so readers could direct the blame at them. You can’t read that blog post and say it’s the most unbiased and objective way they could have presented this, especially if they want to remain on good terms with Amazon, who has done nothing wrong at all.
One can have an opinion and disagree with Amazon without feeling entitled to anything from them.
I'm not objective; it's my subjective opinion that you're wrong. That doesn't mean I feel entitled to have you change your mind.
Re: Amazon threatens to suspend Signal's AWS account over censorship circumvention
#106Earlier quoted context omitted.
The part you're missing is: ... to third parties. They aren't spoofing the domain, they are just making sure that outside parties to an SSL connection will have a difficult time determining where that SSL connection is going. The two parties creating the SSL connection are not lying to each other, though.
But they are. With SNI you are literally lying to the Amazon load balancer, which is one of the two parties of your encrypted communications.
How is Amazon "one of the two parties" to my Signal message to a friend? An infrastructure provider, a carrier maybe, but a party to?
I'm not against Amazon's decision, but I disagree with anyone framing this as Signal trying to deceive its users. What they're doing isn't too far removed from me using a VPN to deceive Comcast regarding my use of "their" services. That is, if we're going to get loose with our metaphors.
Re: Amazon threatens to suspend Signal's AWS account over censorship circumvention
#107Their AWS wasn't threatened, only their ability to use CloudFront. We will immediately suspend your use of CloudFront if you use third party domains without their permission to masquerade as that third party.
How is it possible to "use" a domain name without owning it? More specifically, which mentions count as "uses"?
Re: Amazon threatens to suspend Signal's AWS account over censorship circumvention
#108Earlier quoted context omitted.
But they are. With SNI you are literally lying to the Amazon load balancer, which is one of the two parties of your encrypted communications.
Are you? It looks like the Amazon load balancers don't actually care what your SNI domain is when routing traffic. They terminate your TLS connection, and then use the domain in your actual HTTP request to route it, which is not Amazon's domain. Amazon's ability to allow these two domains to differ, and to mostly ignore the former, is the crux of this whole trick.
still lying though and it seems like that’s a foundational problem. it’s reasonable for a machine to refuse connections from a machine that has lied.
Re: Amazon threatens to suspend Signal's AWS account over censorship circumvention
#109Earlier quoted context omitted.
An HTTPS connection sends the domain it wants to connect to in two layers: first unencrypted in the TLS headers, then encrypted in the HTTP header. In a regular connection (even using a CDN), those two will match. Using domain fronting, you put a popular domain in the unencrypted part, and the real domain in a encrypted HTTP header. Due to how they're implemented, the load balancers at Google and Amazon will ignore t…
What if Signal sent the correct domain by default, but made it user configurable? Users in oppressive regimes would figure it out pretty quickly.
My guess is that Amazon would say "we're not idiots" and shut down their Cloudfront account anyway.
Re: Amazon threatens to suspend Signal's AWS account over censorship circumvention
#110Telegram has some pretty interesting ideas wrt censorship circumvention. I.e. you can still use Amazon, Google, Microsoft as an unblockable side channel to deliver proxy settings, same way domain fronting relies on them. And you can sponsor other people to setup proxies, making it hard to detect and suspend accounts used for censorship circumvention on Amazon and other hosting companies.
As a side channel dns over https still works even with tls to google.com and then putting Host: dns.google.com into the header. Frequent updates to applications and push notifications can be used as side channels too. You can also register a bunch of domain names ahead of time using hash of a current day, month, year and then let the app generate domains names to query on the fly and query them over normal dns. The censor would need to reverse engineer the app to figure out the domain generation algorithm.
To make proxies hard to enumerate you can shard the mapping of ids/phone_numbers to proxies in a such way, that each id receives multiple proxies using multiple different sharding schemes. This not only makes it harder to enumerate, but also lowers the chances of someone else obtaining the same set of proxies as the censor and rendering the app unusable. Changing IPs then forces the censor to chase you, but never really catch you to censor the app.
But I do think building peer-to-peer network instead of proxies is a better idea for circumvetion.