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