Their 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"?
Amazon threatens to suspend Signal's AWS account over censorship circumvention
121–130 of 519 posts
Re: Amazon threatens to suspend Signal's AWS account over censorship circumvention
#122Or just design your protocol so it looks like TLS session resumption and no SNI hostname is in the clear at all?
Re: Amazon threatens to suspend Signal's AWS account over censorship circumvention
#123This 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...
Capitulating to foreign censors for business reasons has something to do with censorship.
Re: Amazon threatens to suspend Signal's AWS account over censorship circumvention
#124I'm thinking of a legislative, not technological solution to this, which seems to be pretty straightforward: make it unlawful for US companies to refuse service simply for Domain fronting. That way, none of the big companies could lawfully refuse service to Signal; neither could they be faulted by these other regimes for "letting Signal use their domain".
No, the solution is to solve the technical problem of leaking metadata during the TLS handshake. Should it also be unlawful to refuse service to someone who pretends to be you when they resell your widgets to the mob because they fear retaliation if the mob isn't happy with the goods?
The fact that in Signal's case, the client and the server are fully aware of who each other are is immaterial (thus not part of the analogy).
What the analogy demonstrates is that there exists a potentially-retaliatory party that sees the server identify itself as someone else. That someone else (in this case, the cloud provider) has the right to protest the use of their identity in a way that makes it a target for the retaliatory party.
Have a great day.
Re: Amazon threatens to suspend Signal's AWS account over censorship circumvention
#125They'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…
Re: Amazon threatens to suspend Signal's AWS account over censorship circumvention
#126Earlier quoted context omitted.
Or it forces oppressive regimes to realize that they are being an oppressive regime. Want to censor the internet, fine, send your citizens back to the dark ages; see how long it is until they protest or move.
Amazon isn't in the business of forcing oppressive regimes to realize they are oppressive regimes, they are in the business of selling goods and services regardless of the oppressiveness of the regime governing the region where the currency comes from. If you want Amazon to stop doing business with oppressive regimes, contact your politicians about sanctions.
For the record, U.S. politicians have voted on sanctions on Russia for cyber crimes and brought representatives to the UN raising the issue of their human rights records.
Re: Amazon threatens to suspend Signal's AWS account over censorship circumvention
#127Earlier quoted context omitted.
Or it forces oppressive regimes to realize that they are being an oppressive regime. Want to censor the internet, fine, send your citizens back to the dark ages; see how long it is until they protest or move.
I'm guessing you haven't spent much time looking into how oppressive regimes work. They aren't going "to realize that they are being an oppressive regime" and have an epiphany where they realize, "Hey maybe I'm an evil dictator?" If you are up for reading, I highly recommend Michael Malice's book, Dear Reader: The Unauthorized Autobiography of Kim Jong Il . After reading that you will completely understand why "see h…
I wonder if you could give TL;DR on this, assuming there is something else than the basic prisoner's dilemma going on?
Re: Amazon threatens to suspend Signal's AWS account over censorship circumvention
#128That way there would be no nees for an unencrypted SNI.
Is there already a TLS extension for this? If not,would have been nice if 1.3 incorporated this.
Re: Amazon threatens to suspend Signal's AWS account over censorship circumvention
#129Earlier quoted context omitted.
They say it doesn't solve the problem - "Would adding federation to Signal help with users behind country-wide blocks? Seems like a distributed service would be harder to censor than a centralized one." - "It's trivial to block several distributed hosts simultaneously. An aspiring censor would simply find the most common federated endpoints for a given service and block all of them. Only the users of that software wo…
I think it may depend on how well distributed would a service be: having several big servers would not help but if every family and company had their own mini server, located in a non-censoring country then the censors would be unable to do anything easily. These servers, in turn, would be able to easily connect to the broader network. Of course that wouldn't be as easy to setup as a simple installation of the Signal…
Re: Amazon threatens to suspend Signal's AWS account over censorship circumvention
#130This doesn't seem like a good solution from any angle. Do we need to change TCP/IP/whatever to actually allow network traffic to be secure again?
AFAIK There was some effort to make this TLS 1.3 SNI header encrypted but some influential groups blocked that (I think I read something about ability to route and control traffic easily). Really sad :(
- Start an encrypted unauthenticated conversation with the server first: that adds at least one extra round-trip, so most people won't do it, so it's easy to block all connections that do
- Encrypt it to a key you have from the previous connection: doesn't help the initial connection and you already have session resumption for the rest
- Encrypt it to a well-known "private" key: doesn't help at all
The actual proposal for TLS 1.3 SNI seems to involve ... domain fronting. https://tools.ietf.org/html/draft-ietf-tls-sni-encryption-02 (I assume that's so that it avoids the "it's easy to block" problem)