Hacker News new | ask | show | jobs
by dsl 2969 days ago
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.
2 comments

How is Amazon "one of the two parties" to my Signal message to a friend? An infrastructure provider, a carrier maybe, but a party to?

I'm not against Amazon's decision, but I disagree with anyone framing this as Signal trying to deceive its users. What they're doing isn't too far removed from me using a VPN to deceive Comcast regarding my use of "their" services. That is, if we're going to get loose with our metaphors.

I think you are misunderstanding what is going on here.

The Signal client on your phone is connecting to a load balancer that Amazon owns. In the initial handshake it lies about what website it is trying to contact, claiming to be looking for an Amazon shopping site. Once the connection is fully established it says "just kidding I am actually trying to reach the Signal server hosted in AWS."

They are abusing a bug in Amazon's front end load balancers, having them route traffic in a way that wasn't intended. This is a warning to knock it off, while Amazon works on fixing that bug.

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

Yes, this is the premise of domain fronting.
still lying though and it seems like that’s a foundational problem. it’s reasonable for a machine to refuse connections from a machine that has lied.