
Amazon threatens to suspend Signal's AWS account over censorship circumvention - jboynyc
https://signal.org/blog/looking-back-on-the-front/
======
unethical_ban
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. In the end, the rest of the
internet didn’t like that plan.

That they interpret AWS and Google as "the rest of the Internet" is pretty
sad, too.

~~~
tonyztan
> "They're spoofing identity"

That's the entire point. By making it impossible for censors to distinguish
Signal traffic from other web traffic going to AWS, domain fronting forces the
government censors to either 1) stop censoring, or 2) censor many important
websites that people rely upon. The associated economic cost has the tendency
to discourage censors, and as shown by Signal, is actually quite an effective
deterrent against many oppressive regimes. This concept is known as collateral
freedom.[1]

Instead of shutting this down, Amazon could have let Signal continue. In fact,
all companies should collaborate to make censorship as expensive as possible.
Someone here at HN pointed out that it is very difficult for someone under an
oppressive regimes to speak out; this makes it all the more important for
those of us who can to assist dissidents and support freedom of expression.

[1]
[https://en.wikipedia.org/wiki/Collateral_freedom](https://en.wikipedia.org/wiki/Collateral_freedom)

~~~
crazypyro
My first thought is "How is it in the interest of Amazon's stockholders to
prevent censorship in countries ruled by dictatorial regimes?" and secondly,
"How does consenting to being a front for services that are strictly forbidden
in certain countries benefit our company?"

~~~
xtat
Shareholders still come first if they do the right thing here. Letting
reputable people do good with your product rises the tide for the ecosystem.
Good for the Internet is good for AWS.

~~~
stingraycharles
What if souq.com is blocked instead ? How is that good for AWS or the internet
?

------
QuinnyPig
Sorry, I'm not on board with using an Amazon owned domain for this. That's got
the potential to get Amazon itself blacklisted in some places, so they're
absolutely not going to be okay with it.

~~~
smileysteve
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.

~~~
freedomben
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 how long it is until they protest or
move" is a silly thing to say.

[1] [https://smile.amazon.com/Dear-Reader-Unauthorized-
Autobiogra...](https://smile.amazon.com/Dear-Reader-Unauthorized-
Autobiography-Jong/dp/1495283259)

~~~
godelski
There is a difference when people have never had access to things and when you
take away access.

A difference would be like America and North Korea and taking away the
internet. The vast majority of Americans use the internet and it is an
integral part to their lives. You take it away and they would riot in a
heartbeat. On the other hand if you have a regime where the majority of people
never had access to the internet (or any whatever), taking it away does not
cause a riot. The small groups of people that had access won't have the
critical mass needed to cause such a riot.

The point is not to make a dictator to realize "Hey, maybe I'm the baddie" but
"If I take this away then someone will stage a coup." Dictatorships tend not
to be very stable regimes. It is hard to balance the line of power and being
overthrown.

TLDR: People care much more when you remove something that is already integral
to their life. Not so much if it isn't.

~~~
paranoidrobot
> You take it away and they would riot in a heartbeat.

I'm not certain that this is true.

No American Dictator would just outright ban the internet, no they'd say they
were protecting children and blocking terrorists, and require internet
providers to block that content.

Anyone arguing that this is censorship would be branded as a supporter of
child pornography and terrorists.

A few more steps along that line and what you have is no longer the internet
as we know it, but PatriotNet(tm) (insert waving flag, anthem, etc).

Do it enough subtle steps and they'd get away with it without anything more
than a few grumpy "libtards" complaining on TV.

~~~
godelski
You're right in that it can be done through a long process. But as freedomben
notes (in response to my reply), Egypt is an example of what I'm talking
about.

------
zzzcpan
Telegram 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.

~~~
theintern
Given its an open source app, it should be reasonably easy for the censor to
reverse engineer the algorithmically generated domains. Frequent tiny updates
would be an interesting solution though. Now that most mobile apps can deliver
just deltas to save bandwidth it'd be viable.

~~~
zzzcpan
I realize now, that it's possible to even dynamically deliver a bytecode of a
domain generating algorithm itself or pretty much any circumvention logic by
embedding a tiny interpreter into the app.

~~~
caf
You don't need to deliver bytecode, just a new seed for the algorithm. Even 64
bits is more than sufficient to ensure that they can't enumerate all possible
seeds.

~~~
zzzcpan
Seeds don't impose human costs of reverse engineering though. Which could be
important in some cases, since we are up against state actors.

But yeah, having seeds sharded per id/phone_number same way I proposed above
could make it pretty much unblockable.

------
manigandham
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...](https://arstechnica.com/information-
technology/2018/04/in-effort-to-shut-down-telegram-russia-blocks-amazon-
google-network-addresses/)

~~~
maxerickson
Capitulating to foreign censors for business reasons has _something_ to do
with censorship.

~~~
mi100hael
Amazon has a _ton_ of customers, at least a few of which like
[https://preemptivelove.org/](https://preemptivelove.org/) are also doing good
things in these countries. It's not just Amazon that suffers, but Amazon's
customers and everyone else downstream.

~~~
noobermin
I'm sure Amazon will be ok. They'll probably have enough money even with the
loss to run the servers for that site I think.

~~~
mi100hael
The point is that Signal isn't the only app being used for good in such
countries. Amazon's bottom line will be ok, but the customers & users who live
in the censored countries will no longer be able to access other important
sites hosted by Amazon.

------
Talyen42
Misleading headline?

> Signal plans to make its traffic look like traffic from another site,
> (popularly known as “domain fronting”) by using a domain owned by Amazon --
> Souq.com

~~~
pyre
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.

~~~
dsl
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.

~~~
apendleton
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.

~~~
textmode
Does this mean that Cloudfront does not actually require (correct) SNI?

Example: Sending HTTP request for signal.org over TLS to Cloudfront IP address
with SNI as "allergan.com" returns signal.org web page, not allergan.com web
page.

~~~
computerfriend
Yes, this is the premise of domain fronting.

------
mvanbaak
I really dislike the way they put it in the title of this post. What they are
doing is simply abusing the name/size of a totally unrelated company to mask
signal traffic.

While I am totally in favor of signal, simply using a domain name you dont own
in the SNI header just because it is terminated at the same service as you
want to use is something you cannot do.

They could have simply have sent the question to the owner of the domains
(google and amazon) explaining what they wanted to do, and only think about
implementing it when the owner agreed.

And last but not least to answer those: 'why would they even care, the traffic
goes to cloudfront anyways?' ... It will seriously mess up the stats (and
billing, yes, amazon owned companies pay internal bills to aws for usage, it's
a very normal way of doing business and get your taxes right).

It's sad that tricks like these are being considered/needed to have access to
internet services in some parts of the world, but simply doing it without all
parties involved knowing about it and agreeing on it is _NOT_ the way to do
it.

~~~
nebulous1
> simply using a domain name you dont own in the SNI header just because it is
> terminated at the same service as you want to use is something you cannot do

Why not out of curiosity? I'm not disputing Amazon's right to disallow this
(it's their service after all), but before that I don't see any objective
reason why this is something they they "cannot" or even "should not" do. Also,
unless Amazon put in a technical barrier (which they are in the process of
doing), then they can't stop a third party from doing it anyway (i.e. me
personally sending a different domain in the SNI header than the one I
actually end up communicating with), and on that level (ie me rather than
Amazon's customer) I see no reason why I wouldn't do exactly that if my ISP
was blocking the target domain.

~~~
mvanbaak
> Why not out of curiosity?

Because you are lying about what domain you want to access. This is against
the TOS, and simply something you should not do. I know it helps signal to get
around censorship and blocks, and it's technically working, but one should not
do that.

~~~
Tepix
You are only pretending to contact a certain address during the (short)
unencrypted phase of the request. As soon as encryption is present you reveal
the real address you want to talk to.

The only ones getting spoofed are the censors.

~~~
mvanbaak
Correct. But still it's something one should not do and is against the TOS of
AWS Cloudfront.

------
andrewaylett
Surely better to get an at-least-vaguely-friendly warning pre-implementation
rather than a post-implementation block?

I would much prefer censorship circumvention to be possible, but I have some
sympathy for platform providers not wanting their customers and their platform
to be conflated so easily.

------
goatsi
The HN post that alerted Amazon:
[https://news.ycombinator.com/item?id=16868564](https://news.ycombinator.com/item?id=16868564)

~~~
jessaustin
Thanks, HN!

------
_bxg1
Is this something that CloudFlare could help with? They tend to have an
idealistic bend, and they serve content for enough sites that they could
conceivably disguise traffic in the crowd for altruistic purposes. I could be
misunderstanding the mechanism in question, though.

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

~~~
yodon
Please don’t use code formatting for quotes, it makes the content unreadable
on mobile

~~~
gsich
Last I checked scrolling is possible on mobile. As is landscape.

------
maxmorlocke
I posted on the signal community forums in significantly more detail (e.g. how
to configure nginx exactly with test connections), but it's relatively easy to
use AWS infrastructure only for pass through and configure nginx to accept
specific public SNI headers while connecting to domains you are authoritative
for (e.g. google.com, amazon.com, yahoo.com, yandex.ru). You can do this by
using the ssl_preread nginx module to proxy based on the SNI header (e.g.
amazon.com -> 127.0.0.1:444, google.com -> 127.0.0.1:445, yahoo.com ->
127.0.0.1:446). This effectively means that you are not having AWS or GAE do
anything other than directly proxy encrypted content, which I would argue is
an important distinction.

The downside is that no one is providing the DNS redirect in an encrypted
transaction.

------
bluefox
"If you put a spoonful of wine in a barrel of sewage, you get sewage. If you
put a spoonful of sewage in a barrel of wine, you get sewage." \--
Schopenhauer

Unencrypted server name indication is sewage.

~~~
nemothekid
In the past, the alternatives was a static IP, which are easier to block. i
can’t think of a solution that doesn’t just pass the buck to another third
party (like a CA) which would be sucseptible to the same attacks.

------
ChuckMcM
Clearly they need to create a free iPhone/Android game that becomes wildly
popular in these countries so that they can use their own domain to front
their 'secret' packets.

~~~
coolspot
Censors are not stupid, they will ban domain with no problem.

See Russia banning millions of AWS and Azure IPs to block Telegram, damaging a
lot innocent applications by the way.

~~~
sorokod
Some censor are very stupid. I visited a country in south east Asia about ten
years ago that was blocking Google. On http. But not on https.

------
RockyMcNuts
I feel like Amazon has a moral obligation to name the country that is forcing
them to do this under penalty of having their entire IP block black-holed.

I assume Amazon would not take this step unless that was going to happen
otherwise, or at least I don't see why they would.

They don't need to make a political statement about it, just say they did it
to comply with law / order of 'X'. <cough>Russia<cough>

~~~
RandomCSGeek
Why wouldn't they do this on their own? Keeping their reputation good with all
countries(even the oppressive one's) is an important part of business. After
all, amazon has stakeholders to answer to.

~~~
RockyMcNuts
I don't see how it hurts their reputation to allow Signal to anonymize. They
could even block domain fronting in general to block bad actors, and quietly
whitelist Signal.

~~~
RandomCSGeek
It's not about anonymizing, it's about hiding under the mask of some other
entity, without their(other entity's) permission. AWS's other customers and
various governments won't be happy about aws allowing Signal to do so.

While they could white list Signal, I don't see why they would want to go
through this trouble. It's not like any of these public companies care any
more about supporting people under oppressive rules, than profit.

------
mtgx
Google did the same to Telegram:

[https://www.theverge.com/2018/4/18/17253784/google-domain-
fr...](https://www.theverge.com/2018/4/18/17253784/google-domain-fronting-
discontinued-signal-tor-vpn)

Tech companies being "on users side" (if they ever were) is now officially
over.

Hopefully they don't expect users to be on _their_ side when the regulations
are coming.

------
rajacombinator
It’s pretty clear Amazon is in the right here. Actually I’d say it’s a
positive that they made an effort at human outreach.

------
CamTin
Can't we just fix TLS to not have this plaintext negotiation component? It
clearly isn't necessary, or domain "fronting" couldn't even work.

~~~
manquer
It is still nessecary , it only works because both domains are serviced by the
same CDN servers which ignores the plain text version once the packet reaches
them.

If the plain text component is not there none of the intermediary parties will
know where to route the packet as they cannot decrypt the header.

------
Tinyyy
So they're basically asking for forgiveness instead of permission, fronting
other sites until they are told to stop?

~~~
foobarbazetc
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”. :)

~~~
dsl
Fixing domain fronting is easy. You just match the certificate SANs (or SNI
requested domain) to the request Host header.

The only problem is it breaks a subset of users who are domain fronting by
accident (Think a mobile app that connects to www.app.com but sends
api.app.com).

~~~
foobarbazetc
I’ve used every major CDN on the market and none of them do this.

Some don’t even check that the Host header host is a customer and just proxy
it anyway.

~~~
dsl
I said the fix was easy, not that people were actually fixing it. :/

------
pasbesoin
Demonstrating that these companies are willing to sell the values of the
societies, and many of the people, who created them, down the road. Free and
open speech, interaction, and association. Privacy.

For most of us, this is "somewhere else", right now. But it will be "coming to
a theater near you", real soon now.

------
Promarged
It seems centralized solutions (Telegram, Signal) are under fire recently. I
wonder what would happen if federated protocols (Matrix, XMPP, etc.) were more
popular and, thus, also in spotlight.

~~~
mmahmad
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 would be
affected. There wouldn't be any collateral damage. If the censors somehow
didn't hit every single worthwhile federated endpoint, users would still be
left wondering why they couldn't communicate with most of their friends.
Moving between federated hosts would also necessitate an entirely new
identifier, so users would need to rebuild their social graph again.

In addition to being ineffective against censorship, there are several other
properties and trade-offs that make federation a difficult proposition for an
application like Signal: [https://signal.org/blog/the-ecosystem-is-
moving/"](https://signal.org/blog/the-ecosystem-is-moving/")

src:
[https://news.ycombinator.com/item?id=16868564](https://news.ycombinator.com/item?id=16868564)

~~~
Boulth
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 app.

~~~
jlund
An aspiring censor could also "easily connect to the broader network" and
masquerade as a federated server in order to discover others. This process
could even be automated.

Federated services also require an identifier, and this identifier usually
indicates where the user's account is located and how to connect with them
(e.g. user@domain.com). As people share these identifiers, the aspiring censor
can just keep adding new entries to the blacklist.

~~~
seba_dos1
At least in case of XMPP, the client doesn't need to be able to connect to
other domains, so as long as you can connect to your own server outside of the
censorship's reach (which could be accessible for c2s connections in a
completely different way than for s2s), you should be fine.

~~~
Paul-ish
How do you ensure the censor doesn't block the major c2s connections? I
suspect most techniques are too technical for your average user.

~~~
Boulth
Modern clients can connect via port 443. There is also support for XMPP via
WebSockets, that looks like regular HTTPS traffic.

~~~
majewsky
Sure, but they can just block the IP.

~~~
Boulth
Yes, but it's always possible to block IP (targeted attack). Federated with a
big amount of small servers make it hard to automate. You can block several
hosts but the rest of the network would work fine. And because of how
federation in XMPP works you just need a one client to server connection to
reach the entire network.

------
idonotknowwhy
Haven't these guys solved this problem:
[https://zencash.com/](https://zencash.com/)

They're paying over 12,000 people in zencash, to host 'securenodes' with
domain names and ssl certificates for domain fronting, rather than using
domain names without permission.

[https://securenodes.na.zensystem.io/nodes/all](https://securenodes.na.zensystem.io/nodes/all)

~~~
flyGuyOnTheSly
That second link you provided lists every single one of the IP addresses and
hostnames associated with the service.

It would be trivial for censors to just block every single one of them.

~~~
idonotknowwhy
Good point, in it's current form it's a little weak. I'm hoping they get rid
of that list eventually.

------
myth_buster
The title is a bit clickbaity. It makes complete sense why Amazon will not be
happy with domain fronting.

Side note, Not sure what the point of [Redacted] is as it's trivial to get
name from > General Manager, Amazon CloudFront

~~~
insensible
To focus the attention on the role rather than the person, who is clearly just
representing the company. It softens it.

------
sounds
I took away two important messages:

1\. Amazon is paying more attention to the TLS handshake than I thought.

2\. Censorship-bypassing software is getting popular enough that it's hitting
the news.

~~~
kazinator
What? Surely:

0\. _Amazon is paying more attention to HackerNews than I thought._

I mean: _Yesterday AWS became aware of your Github and Hacker News
/ycombinator posts [ ... ] General Manager, Amazon CloudFront_

~~~
ry_ry
All the big tech companies are pretty well represented here - it is most
likely an employee spotted and flagged the issue whilst having a wee browse
over their morning coffee.

------
textmode
"Unfortunately, a TLS handshake fully exposes the target hostname in
plaintext, since the hostname is included in the SNI header in the clear. This
remains the case even in TLS 1.3, and it gives a censor all they need."

Does this mean that endpoints that require SNI are potentially contributing to
censorship?

Facts: SNI is optional. Not all websites require it. For example,
[https://signal.org](https://signal.org) does not require SNI; clients that do
not send SNI can be used to fetch this blog post, without exposing the
hostname.

~~~
krallja
The process listening to IPs that resolve as signal.org must not have
alternative hosts on it, since the web server can’t choose a certificate based
on anything but IP. Now the censor can just block your IP.

------
manquer
Why is fully decentralized option like WebRTC not considered ?, there is no
real need for message apps to be centralized especially on mobile.

Loss of message queuing can be mitigated easily when both end points are more
or less always running and messages sent only when both parties are on online.

TURN relays could still be a problem and potential censorship blocks. However
the protocol is standard it is not very difficult to setup one even behind
NAT. You could even bundle lightweight version with app and make all the
clients relays too making it very hard to crackdown on

------
ars
Could they use http instead, with random (generated) domains? And then encrypt
the payload?

For extra credit encrypt the payload as html tags (i.e. build valid html where
the tags correspond to the bytes in the payload.)

~~~
manquer
All of the domains still would need to point to cloudfront. Only CF was
ignoring the outer header, which aws is changing it and this hack won't work
in the future

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

~~~
therealmarv
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 :(

~~~
geofft
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](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)

~~~
icebraining
_that adds at least one extra round-trip, so most people won 't do it_

Eh, people will do whatever the TLS libraries have as default. Optimizing for
an extra RT is way above what most app developers do.

~~~
geofft
Most app developers, sure, but most web server developers are definitely going
to optimize for it - the cost of an extra round-trip is immediately noticeable
in benchmarks. And most app developers are running a pre-existing web server
to proxy to their code (whether via HTTP to localhost / within the firewall,
or something else like WSGI or FCGI), not linking TLS libraries themselves.

------
merb
wouldn't it be possible to actually allow "signal" customers create an
appengine account via the signal app? i.e. every customer can just add their
google account as a setup to setup an appengine proxy to signal. this would
mean that iran would either need to block appengine or they would need to find
out all customers. it could be even implemented with a shuffle so that you can
shuffle your app id.

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

------
QuinnyPig
Note that this was about to break in any case:
[https://aws.amazon.com/blogs/security/enhanced-domain-
protec...](https://aws.amazon.com/blogs/security/enhanced-domain-protections-
for-amazon-cloudfront-requests/)

------
shruubi
It's frustrating because I can see both sides having valid concerns, however,
while Signal's position may be the right one ethically, AWS/Google are in the
right practically.

Should these countries kick up a stink about a private business acting from
their perspective to undermine the laws of their country, it could very well
blow up into an international incident. From the point of view of AWS/Google,
allowing this to happen or turning a blind eye makes them just a culpable if
this were to turn into an incident.

That's not to say I don't support what Signal is trying to achieve, in fact, I
very much do, however, given that in essence they forced Google/AWS into this
situation without much thought makes me less sympathetic to their plight.

------
cavisne
It's a strange choice to use Souq.com as the target here. They could have used
any AWS customer but chose to use one owned by Amazon. It probably is
genuinely one of the biggest Middle East customers on AWS but going this way
would really have forced Amazon's hand.

~~~
wastedhours
It needs to be big enough so you can try and rationalise the morality of the
DNS call cost (even being a few dollars, you're still being a bad actor in
this scenario), a site known and well classified by traffic monitors that they
won't get blocked on their own.

I guess also that hitting an Amazon domain means the logical recourse is to
get AWS restrictions (such as we have here), rather than having an aggressive
this party company outright trying to sue.

------
cddotdotslash
Couldn't Signal use popular domains to host IP addresses as a rudimentary DNS
server of sorts? For example, host a text file containing Signal server IPs on
Google App engine (using the app.google.com address), Azure Blob Storage
(using blob.azure.com endpoint), GitHub (raw.githubusercontent.com), S3
(s3.amazonaws.com), etc. There are hundreds of possibilities on some really
popular hosting services. Then, when the app starts, it queries in them in
series, gets a list of IPs used by Signal, and tries them directly. Signal can
then push new IPs (preferably ones in the AWS address space) to the list as
often as needed to avoid blocking. Need a new IP? Just grab another from AWS
elastic IP service, update the text file, etc.

~~~
gregschlom
And then the censors can very conveniently block all those IPs too, can't
they?

~~~
cddotdotslash
That's the point, it'd be a never ending game of cat and mouse, resulting in
them blocking thousands of Amazon IPs. You don't have to plaintext the text
files either, you could require some kind of shared secret from the app or
user login to prevent the censors from just pulling the file in plaintext.

------
jsjohnst
Why can’t they use raw HTTP vs HTTPS and use an encrypted payload? That
handles the SNI front as they outlined as the detection mechanism hindering
them. I’m sure there’s more to it because this seems pretty basic, but curious
the reason why this was ruled out.

~~~
emmelaich
That occurred to me too. But HTTP/1.1 requires a Host: header. It also brings
a problem of key distribution.

The other technique that might be useful to register lots and lots of obscure
domain names and rotate them regularly. Might cost a bit in SSL certs.

~~~
jsjohnst
> That occurred to me too. But HTTP/1.1 requires a Host: header.

Yes, but that’s easily forgeable as long as the servers in between allow it.

> It also brings a problem of key distribution.

Not really, you can still do chain of trust SSL validation on a payload in the
body of HTTP as you could to encrypt the entire HTTP connection as in the case
of HTTPS.

> Might cost a bit in SSL certs.

LetsEncrypt could help there.

------
pera
I still don't understand why would Google or Amazon care about this, and why
it's against their ToS. Do they think that some of those states may block all
kind of access to their IP blocks just because of some people using Signal?

~~~
zoltaan
I can imagine why someone cares if someone else pretend being that someone....

~~~
icebraining
No, the trick works the other way around; they pretend they want to talk to
someone, but then talk to someone else. They never pretend to _be_ someone
else.

~~~
zoltaan
Right. Even so, don't you see problem in that too? Pretending doing one but in
fact doing other?

Just imagine using that for a non noble cause....

~~~
icebraining
I actually can't :) I mean, I can see why one would oppose it because of how
it affects Amazon, but I can't see how it could be used for a non-noble cause.

------
yani
"If you’d like to help, we’re hiring." Sure but none of the open jobs are
related to the problem the post is describing ... unless designers started to
have super powers or Android developers are the new Avengers

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

~~~
krallja
The load balancers will have to have a public IP address, controlled by
Signal, which is trivial to block.

The whole reason this hack works is because CloudFront is the one terminating
the TLS connection with a misleading SNI header. Blocking CloudFront means
nobody can use CloudFront for any purpose.

------
alpb
Can someone explain how does one serve content on a domain they don't own,
like in this case Souq.com? Do they shove their content to something like
product reviews or what?

EDIT: I realized they use souqcdn.com. Does this mean it works because their
clients use "souqcdn.com" to resolve to CloudFront CDN's IP address and then
they craft a different Host header (like "Host: api.signal.org").

Also how can they possibly use CDN for this? As far as I know, CDN works only
with GET requests, so how are they doing a chat app on this?

~~~
detaro
They aren't serving content on that domain. They just make requests look like
they are going to that domain in the outer layer (by using it as the TLS
server name), but the actual request inside the encryption is for a different
domain they own. The load-balancer in front of the cloud service accepts the
connection for souq.com (since it is responsible for that too it has the
matching server certificate), decrypts the request, sees in the request that
its for "signal.org" or whatever and delivers it there.

~~~
alpb
Oh so this works because of TLA SNI?

~~~
detaro
yes.

------
johnwheeler
You want to use the resources and influence of a large corporation to acheive
your organizations goals. They don’t have to be on board with your mission,
and it’s arrogant to think so IMO. Why should they let you do it, when they
won’t allow it for others? Seems like you feel entitled because you think by
default people should support what you’re trying to do.

The flipside of free speech you’re ignoring is that people get to abstain from
using their voice in addition to using it.

~~~
icebraining
What part of the post shows they feel entitled to it?

~~~
johnwheeler
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.

~~~
icebraining
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.

~~~
johnwheeler
"One can have an opinion and disagree with Amazon without feeling entitled to
anything from them."

That's a straw man. In this case, they don't only disagree, they also feel
entitled; _that 's_ what I'm saying.

~~~
icebraining
I understand; but you're saying you can tell they feel entitled by the fact
that they're not objective or unbiased. And what I'm saying is that not being
objective doesn't show they feel entitled.

Maybe they feel entitled, but I don't think there's anything in the blog post
showing that. All I see is (fairly mild) disagreement with Amazon's actions.

------
onetimemanytime
_> >Direct access to Signal has been censored in Egypt, Oman, Qatar, and UAE
for the past 1.5 years._

Yeah but Amazon alone, should not bear the cost of making Signal accessible to
these countries--especially without their consent. People underestimate
dictators, they will block God's channel to ensure their own survival. How
many times has Youtube been blocked by countries? Plenty of time. So Amazon
cannot risk being blocked completely because of this.

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

~~~
mabbo
Those who wish to suppress Signal would just play whack-a-mole. They'd login
to Signal, find what domains it was connecting to and then block those. To
update Signal with new addresses constantly, you'd need a server hosting those
updates- which would in turn be blocked immediately.

The idea of using Souq.com or Google.com as the domain name in the TLS header
was that even oppressive regimes won't block Google or Souq for their entire
country.

~~~
s73v3r_
>The idea of using Souq.com or Google.com as the domain name in the TLS header
was that even oppressive regimes won't block Google or Souq for their entire
country.

Which, at least in the case of Russia, seems to be false.

------
foxylad
Wouldn't it be nice if Facebook, Apple, Amazon, Netflix and Google all gave
Signal certificates as part of their anti-censorship support?

------
DEFCON28
Why should we in the United States coerce (or sneak into) countries whose
Governments don't want us there? Are these folks really "idealists" who think
that access to tools like "Signal" will usher in a new spring! (See how well
that worked in Egypt and Syria?)

Let these Nations enjoy their sovereign right to protect their borders--even
their digital ones--as they see fit.

~~~
lovelearning
A nation != its current government

Citizens under oppressive governments often don't like their governments. The
feeling's usually mutual. Some people in such countries - I actually think
"most" but I'll remain conservative here - appreciate such tools and its
creators. Not necessarily to do anything so ambitious as "ushering in new
springs", but often simply to talk to relatives or make online friends or
learn new things or exchange ideas online. In case you didn't realize it, lack
of freedom and powerlessness really brings down one's mood, and anything to
brighten it up is welcome.

------
pm90
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".

~~~
jpk
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?

~~~
jpk
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.

------
daveheq
Amazon isn't targeting Signal, this is their new policy based on (mostly)
abusers (though I doubt Signal was intentionally trying to abuse the system
for malicious reasons). Hopefully this doesn't get spun out of control, but
the title of this post seems to be spinning it.

------
Skunkleton
Wouldn't it make more sense to build TOR or something like it into signal for
these use cases?

~~~
icebraining
Tor was actually using the same trick to avoid censorship:
[https://blog.torproject.org/how-use-meek-pluggable-
transport](https://blog.torproject.org/how-use-meek-pluggable-transport)

 _meek-amazon makes it look like you are talking to an Amazon Web Services
server (when you are actually talking to a Tor bridge), and meek-google makes
it look like you are talking to the Google search page (when you are actually
talking to a Tor bridge)._

------
raarts
Maybe someone (ICANN) could start a donation register for domains which tells
applications they allow using there domain name in domain fronting for
censorship circumventing purposes?

Since Amazon's TOS _does_ allow domain fronting when the domain's owner allows
it.

------
exabrial
Kinda a misleading headline. Amazon is stating the don't want their domain
name used as a circumvention measure. I think that's reasonable. Signal is the
one hijacking it and Amazon is taking the risk if it gets blocked.

~~~
computerfriend
No, the fact that Amazon owns the souq.com domain is irrelevant here.

~~~
exabrial
Can you elaborate? I'm not sure I understand why.

------
soheil
The title is misleading they are pretending to be Amazon. The title, Amazon
threatening to suspend Singnal’s AWS acoount over censorship circumvention, is
more vague, less accurate and potentially harmful.

------
jeena
Wouldn't a federated system be much more robust where you would only need to
access one of the nodes and this would send it through a chain of nodes to the
receiver?

------
stevenlefty
This might be a good time to switch to Threema, which generates less metadata
than Signal b/c it doesn't use phone numbers as identifiers.

------
tripzilch
Yeah the problem must be with Amazon, not that Mr Marlinspike refuses to allow
federation of the signal protocol for no good reason whatsoever.

~~~
verbify
How would federation help in this use case?

------
jakebasile
What was it that convinced Google and Amazon to no longer allow this
particular censorship evasion?

~~~
goatsi
Russia made it clear that they would block AWS and Google Cloud if domain
fronting was allowed to continue.

[https://arstechnica.com/information-technology/2018/04/in-
ef...](https://arstechnica.com/information-technology/2018/04/in-effort-to-
shut-down-telegram-russia-blocks-amazon-google-network-addresses/)

As moxie says in the blog post

>The idea behind domain fronting was that to block a single site, you’d have
to block the rest of the internet as well. In the end, the rest of the
internet didn’t like that plan.

~~~
tonyztan
AWS and Google Cloud should have refused to cooperate. Let Russia block them
and bear the economic costs of censorship.

~~~
sterlind
Plays into Russia's hands, actually. Russia has been pushing for a nationalist
approach to messaging, rather than having its citizens use Telegram
(ironically, developed by the Russian who created VKontakte.)

Nations that lean authoritarian are teching up their sovereign walled gardens,
banning external/ungovernable services as soon as it's feasible.

The long play is to knuckle under and defer to local governments, as Amazon,
Google and Facebook have shown.

------
prabhaav
This is why we have built stealthy.im on a decentralized and censorship
resistant platform.

~~~
coolspot
If censor can enumerate nodes of P2P network, it can ban it.

------
pmlnr
This is why any centralised service is doomed. Hint: federation.

------
diedyesterday
It's like Robin Hood running from King John's guards and barging through other
people's homes. Some would definitely be pissed.

------
HIPisTheAnswer
According to the founder of matrix, him and Moxie had a meeting a few years
ago to discuss federation where Moxie debated that it wasn't ideal to create a
federated protocol, that somehow it would create too many problems. Now that
Signal is unable to service everyone without federation, does Moxie still hold
reservations on federated protocols?

On another tangent; the Host Identity Protocol would resolve this (and
countless other) security issue by simply rendering all traffic impossible to
analyze in such a way. Why a big tech company like google hasn't put their men
on the idea is beyond words, especially since it also elegantly solves
mobility.

------
dijit
Once all speech has moved to privately owned platforms, having the right to
free speech will be effectively useless.

~~~
praneshp
You have the right to read the linked article, why don't you exercise it?

------
notyourday
Well, this is what happens when countless startups go to a couple of web
hosters in the name of outsourcing unsexy stuff like racking and stacking
servers.

~~~
monochromatic
If they were self-hosted, it would be even easier for Iran to block them.

~~~
notyourday
If they hosted on VMs they would simply hop from one place to the other. The
problem is that all of this stuff is "difficult" and no one would be writing
stories about how great signal is if it could switch between thousands of
companies that provide VMs to masses.

We do not have these thousands of companies because AWS/GCS/Azure are the go
to. Well, guess what? That means that objectively there are three kings of the
world and the lieutenants of those kings get to decide what is and is not
allowed.

~~~
notriddle
> If they hosted on VMs they would simply hop from one place to the other.

No, that isn't a good enough solution. Signal needs to be _reliable_ , or it's
not worth having at all. The fundamental problem is node discovery: allowing
the users to discover the IP address of the mothership (or, if you prefer,
other members of the P2P network, but Signal is a centralized network) without
the oppressive regime finding those IP addresses. Domain fronting was supposed
to be a "cut the knot" solution, but CDN providers are shutting it down.

Tor's approach has been to use a La Resistance approach, where Dave in the US
runs an obfsproxy node for Yasim and his twelve trusted friends, that's how
node discovery works, and as long as Dave is a good sysadmin and nobody
squeals it's reliable. Personally, I think that's the only sustainable
solution, but it's not very user-friendly, because you need to have trusted
confidants on the other side of the firewall that your government doesn't know
about. Signal can't be that trusted confidant, though I imagine Signal works
over Tor just fine if you set it up.

------
vioyul
I don't like this. The last few services taking privacy seriously are under
attack all over the world. Telegram vs. Russia, Signal vs. Amazon, WhatsApp
Encryption vs. Facebook...

------
zoltaan
Based on the story Amazon has no problem with you circumventing censorship, it
is not the subject of the topic at all, do not lie please because you only
hurt your own reputation and trustfulness - which in a highly sensitive area
that you are working in is paramount!

~~~
jlund
The technique that Signal was using to circumvent censorship (domain fronting)
will no longer be possible on Amazon:

[https://aws.amazon.com/blogs/security/enhanced-domain-
protec...](https://aws.amazon.com/blogs/security/enhanced-domain-protections-
for-amazon-cloudfront-requests/)

~~~
zoltaan
This is not waht's in the title of the article! The title says the account is
threatened to be closed on the grounds of circumventing censorship! Big fat
lie!

The account suspension threat is based on using something that is not
permitted! Knowingly not permitted, illegitimate use!

------
geff82
You should be using your own servers. Guess the lesson is learned now?

~~~
pyre
How do you propose that they implement domain-fronting to circumvent
censorship from their own servers?

~~~
notyourday
Boatload of VMs with constantly migrating IP addresses.

~~~
stordoff
Which then has the problem of how do users find them (if by DNS, you can block
the DNS record).

~~~
notyourday
Service discovery is an actual interesting problem to solve when you don't
outsource it to k8s, huh?

