Hacker News new | ask | show | jobs
by dice 2969 days ago
>You can't use TLS and load balancing hacks to pretend to be us in oppresive countries

They're not pretending to be Amazon, they're pretending to initiate a connection to an Amazon domain. The "conversation" goes like so:

Clear text request: "Hello, I would like to speak TLS with souq.com"

Clear text response: "Why yes, let us do that with these parameters"

Encrypted request: "Please give me the page for signal.org/api/whatever"

etc...

4 comments

This important description of the actual implementation of domain fronting — namely that it’s implemented on the client side, and only as a cover for initializing the TLS channel — I think is very important and unfortunately missing from TFA.

There is nothing on the server side which is masquerading as Amazon or Google. There is no impersonation or spoofing whatsoever.

This is akin to making a DNS lookup for a different domain to find the IP of a service which you know is hosted on the same machine.

While it seems to me that this is clearly not actually violating Amazon ToS, I can understand why Signal must give up on this approach.

As an aside, I’m not sure why this doesn’t break SNI, or exactly when or how the certificate gets switched out over to Signal’s cert and private key. The whole point of putting the domain in the ‘Client Hello’ is to get hooked up to the right cert for the rest of the negotiation when there isn’t a 1:1 mapping of IP->Cert so to switch the GET domain/path later on would, I assume, require restarting the key agreement, which I’m surprised doesn’t blow up the TLS session and require a new clear text ‘Client Hello’.

> I’m not sure why this doesn’t break SNI, or exactly when or how the certificate gets switched out over to Signal’s cert and private key.

They way I understand it, the connection really _is_ using amazon’s cert+key, not Signal’s cert+key.

Is signal (the server side) using amazons’s cert+key? Not technically.

Interesting. Reading their developer guide [1] pg 293 - CloudFront servers have all the private keys anyway, so it hardly matters—from a security perspective—which key is used to establish the TLS connection to the CloudFront endpoint. The connection between CloudFront and Signal’s own severs would be encrypted with Signal’s key.

I also found this paper on domain fronting to be a very good read - Blocking-resistant communication through domain fronting [2]

[1] - https://docs.aws.amazon.com/AmazonCloudFront/latest/Develope...

[2] - https://www.bamsoftware.com/papers/fronting/

Exactly. This works because the point of TLS in this instance is for the Signal client to be sure it's talking to Amazon CloudFront. The certificate for an Amazon service also hosted on CloudFront is certainly good enough to prove this, provided the client knows to expect it, which it does.
That would mean that Amazon was supplying Signals content as authentic Souq traffic, something that I doubt was happening.
Amazon was supplying Signal's content as souq.com but with the request making it clear it was for Signal.

How might this be noticeable? Like so:

     - (irrelevant) the SNI and certificate presented by the server don't match the request -- only the hoster can see this, so what might they care?
     - (serious) metering: if the hoster uses SNI for metering... then Signal would be stealing the fronter's bandwidth
     - (mild) DNS metering: the fronter's domains will see more DNS lookups not related to serving the fronter's content
Nothing that couldn't be addressed contractually. Signal could pay the costs that would otherwise be unfairly born by the fronter, and whatever makes the hoster comfortable with the whole thing (if making the fronter good is insufficient for that).
The metering isn't based o he SNI header, so the second point doesn't apply. And since the frontier's domains are presumably using the CDN's DNS servers anyway, it's not an issue either.
2 is hypothetical as none of the fronts are doing this, and even if a front "could" that doesn't matter as the fronts in question do not. We can agree that if this was happening then it would be an issue.

3 seems just wrong. Where does the DNS lookup take place? Why would the fronting server look up the SNI entry?

Are you 100% confirming that the encryption takes place using Souq's cert? Obviously it isn't going to display in a browser, but I'd wonder if there was something else you could do with it.

If the fronting is done on the client side, can we set up clients to perform the same trick on other services? E.g. make Amazon and Google think they use domain fronting, and thus have them reconsider ban?
A couple important things to note:

- This most definitely is against the CloudFront terms of service. See the linked article if you disagree - the ToS is quoted there.

- One direct impact to the owners of the SOUQ.COM domain is that their DNS query volume will increase drastically. They have to pay for those queries. Would you like it if your side project all of a sudden got a 6 figure DNS bill because Signal decided they want to piggy back on your domain to route around censorship?

> Would you like it if your side project all of a sudden got a 6 figure DNS bill because Signal decided they want to piggy back on your domain to route around censorship?

In this hypothetical example, is my side project doing $178,000,000,000 of annual revenue like Amazon.com? If so, I'd like to think I'd be honored help subvert censorship by oppressive regimes.

Except that amazon is not the one paying, it is quad.com (or some other domain they’re piggybacking on) who has to pay for the DNS traffic. If my $3 side project suddenly became a $1000 side project I’d be pissed too. I like what signal is doing but that should not be making others pay for it. Ideally amazon would help them do that but that don’t.
> Except that amazon is not the one paying, it is quad.com

It's souq.com, which is a wholly-owned subsidiary of Amazon. https://en.wikipedia.org/wiki/Souq.com It's an e-commerce site targeted at the middle east that Amazon bought as their play for that market.

Signal deliberately chose it because it's an Amazon domain, so governments would be reluctant to block it.

That may be true but Signal is purposely using high-profile domains, not someone's small side project.
Nothing stops the signal app from looking up that domain anyway. It's not abuse to genuinely look up an IP. It's the job of resolver caches to keep the traffic under control.
Since Signal is open source, presumably anybody can fork it with a version that implements domain fronting.
Except as the article points out, both Amazon and Google have or intend to make domain fronting not work, regardless of the domain being fronted.
Good point.
They may not be impersonating Amazon, but they are using Amazon's services to circumvent the intent of policies (laws) that Amazon wants to comply with. Amazon has decided to stop be an unwitting participant in this particular mechanism of circumventing oppression.

For the record, I'm of the opinion that the US should insist that American companies not help dictators abroad in their censorship efforts. But it's hardly unreasonable for Amazon to say, "this type of stuff is illegal in Egypt. We don't want any trouble, so please stop using us as a means of circumventing Egyptian law."

It is perfectly understandable why Amazon did that and siding with oppressive regimes is of course not unreasonable at all.

Just unethical, hence the discussion.

AWS is not siding with oppressive regimes, what's with the misleading political slant?

They don't want customers breaking terms of service, whatever those terms are, and especially when it means the rest of their customers are affected. It's not a single company involved here and they're looking out for everyone else they serve.

In this case, enforcing their Terms of Service does constitute siding with oppressive regimes. You could argue that it's not AWS' goal to help oppressive regimes, but in the struggle against censorship, that is the side they have put themselves on in practice. On one side, there are people all over the world who want to communicate freely. On the other, there are authoritarians who want to suppress and surveil that communication. AWS policy used to help the former, and now helps the latter.

I think maybe you're trying to express that under a free market ethical framework, AWS has done nothing wrong here. Which is true, and an insightful indictment of the free market as an inherently liberatory force.

That's not what "siding with" means. AWS is remaining neutral to politics as a company, which is a very good thing. Why do you want multinational corporations to get more involved in geopolitics? Do you think that will somehow lead to a better outcome?

Signal had an strategy, but it involves breaking the terms of service, so that vendor has no reason to comply and put the other customers at risk. Signal just needs to figure out another option. It's a technical issue and nobody is stopping Signal itself. AWS will still host them just fine as long as they follow the terms.

By the way, the free market is what allowed companies like AWS and Signal to exist in the first place, and lets you contributed effort and money if you'd like, so perhaps you should widen your context before throwing around indictments.

Exactly! These countries may start blocking Amazon and Cloudfront domains. Amazon needs to put its foot down.
Amazon isn’t nesessarily against censorship. They just don’t want to provide this sort of spoofing service. Regardless of whether the spoofers are good or bad.
I believe this is the fundamental issue, from Amazons PoV: this altruistic project with nice goals is abusing a network nuance, but most other actors using this capability are likely to be bad actors.

I don't think Amazons reasoning was "oh, lets help dictators dictate", but more "hey, isn't this a potential security hole ripe for abuse that would make us look incompetent?".

Reasonable, but cowardly and disgusting.
Maybe point that anger towards the government and military then, instead of a private corporation with thousands of business customers and millions of consumers.
.... Because the US Military is responsible for changing a sovereign state's law if Americans don't like it? What the fuck?
Yes. It's called war. What's confusing here? If a citizen of a nation thinks that another nation is not behaving as they would like (whichever country or whatever behavior that is), the proper channels to enact change are through government action, either diplomatic or militarized.

Asking a private corporation to be international police is not good for anyone, as well intentioned as it may seem.

Military (or state in general) may have other, softer and more covert means of influencing other countries besides war, like “persuading” home corporations to act on their behalf. Thats not unheard of nowadays
War is an ultimate and extremely costly measure. Just as inter-personal violence should be reserved for extreme cases - if you don't like a mayor in your city, you vote against him, campaign against him, write letters, go to protests - but you do not assassinate him. The same way, inter-national war is a measure of last resort and should not be resorted to due to mere disagreement about cultural norms and such.

> Asking a private corporation to be international police

This implies only police can and does enforce cultural and moral norms. This is the exact opposite of the correct order of things - the police should be preventing or punishing crimes, like theft, robbery, rape, murder, etc. - and people themselves - individually or in organized groups, like companies, NGOs, voluntary societies, etc. - should be creating and enforcing moral norms. You can not just delegate this to "the police", being it national or international.

Thus, asking Amazon to take part in helping to create an international norm of upholding free speech is reasonable. And their refusal is morally despicable.

You say "proper" but what you're describing (at least the military option) is a war of aggression. This is not only illegal (both internationally, and, for example, in US Law), but described as "the supreme international crime."
You're being very nonchalant about going to war to make things easier for Amazon.

I find that chilling.

Yes, but I don't think you're considering the significant direct cost to the owner of SOUQ.COM for DNS queries. If all of a sudden I get millions of extra DNS queries for my domain because Signal is using it to front their traffic to CloudFront, I might get a huge DNS bill.

Should any government coerce me into paying a large DNS bill just to sponsor freedom of speech? Even if it is a noble cause, we shouldn't coerce innocent 3rd parties into doing this.

It's not a significant direct cost. Millions of extra DNS queries amounts to single-digit dollars (route 53 pricing).
And the owner of souq.com isn't some random person; it's Amazon.
They're not pretending to be Amazon, but they are making their client pretend to talk to an Amazon host, and use the SSL keys of an Amazon-owned host rather than their own.

It's more like this:

Clear text request: "Hello, I would like to speak TLS with host souq.com and encrypt my connection with a key signed by souq.com"

Clear text response: "Why yes, let us do that with these parameters"

Encrypted request: "Actually I meant host signal.org, but please route my request anyway since both hosts are being routed by this service. Please ignore the fact that my symmetric key for this connection was encrypted and transmitted using the keypair of souq.com."

----

This is similar to buying a train ticket to a nearby stop, using it to get on the train, then getting off at a different stop because you know they won't check your ticket again.

Google and Amazon are now adding an additional ticket check.

Sure, as long as that "different stop" is no further down the line.

There's no need for the ticket to match. They're not traveling on any rail segments they weren't supposed to be on.

Except that you aren’t actually using an additional service that you’d otherwise have to pay for, so that analogy is bullshit.
Souq.com is owned by Amazon.
They're arguably impersonating Amazon on the server side by hosting their service behind Amazon's proxies and using a trick to pretend that they're talking to some Amazon service instead of their own.
The beauty of this is they are not doing anything on the server side to impersonate or spoof Amazon.
Right, it’s the _client_ side that’s tricking Amazon’s servers.

It seems to me Amazon should just close their loophole rather than threaten to kick signal out of the server side.

According to the article, that's exactly what they're doing.
You're right of course, my comment was too short and factually wrong. What I meant was that what they're doing is effectively renting office space in Amazon's building and then exploiting a loophole in the way mail is distributed to receive packages even though the outside envelope says "c/o amazon.com" (or c/o souq.com in this case).

So while they don't do anything fishy on the server side they still took care to put their servers there for a reason. And since they also write the client code it's not difficult to show that the intent is to impersonate Amazon to 3rd parties.

Interestingly it seems that amazon couldn't really complain if the people writing the client were independent from those maintaining the servers since the spoofing code is entirely in the client. Although in the end I'm sure if it turned out to be a problem for they they'd just enforce that the domains match the HTTPS query and remove the technical possibility of fronting altogether.