Live data from Hacker News

Amazon threatens to suspend Signal's AWS account over censorship circumvention

signal.org

121–130 of 519 posts

Re: Amazon threatens to suspend Signal's AWS account over censorship circumvention

#121
post #107

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"?

In the request from the Signal app to Amazon's servers, they pretend that's the domain they want to contact, but inside the encrypted connection, they actually ask for a different domain (the latter of which they own).

Re: Amazon threatens to suspend Signal's AWS account over censorship circumvention

#122
Why can you not run load-balancers on AWS using randomly-selected subject names of other certificates on other AWS machines?

Or 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

#123

This 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.

No, it doesn't. This is Amazon saying they don't wish to be a part of this dispute, which is entirely their right. It is not Signal's right to drag Amazon into the dispute against their will.

Re: Amazon threatens to suspend Signal's AWS account over censorship circumvention

#124
post #73
post #59

I'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?

Re: Your deleted

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

#125

They'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…

Spot on. How about "Amazon threatens to suspend Signal's AWS account over CloudFront ToS violations".

Re: Amazon threatens to suspend Signal's AWS account over censorship circumvention

#126
post #67

Earlier 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.

You're not wrong, it would certainly not be in shareholder's financial interest for amazon to take this stance.

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

#127

Earlier 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…

> After reading that you will completely understand why "see how long it is until they protest or move" is a silly thing to say.

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

#128
If TLS incorporated a feature by which clients can send the server name after the TLS handshake which would cause renegotiation of encryption keys with the requested server (if available) then wouldn't that solve the problem at hand?

That 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

#129
post #89
post #66

Earlier 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…

When hosting one of those servers could potentially get limbs cut off, that makes it a much less attractive proposition.

Re: Amazon threatens to suspend Signal's AWS account over censorship circumvention

#130

This 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 :(

What do you encrypt the header to? Options include:

- 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)

Post reply on HN