Hacker News new | ask | show | jobs
by zaroth 2972 days ago
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’.

4 comments

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