7 ms·

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

by dice 8y 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...

simias 8y ago
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.
- zaroth 8y ago
  The beauty of this is they are not doing anything on the server side to impersonate or spoof Amazon.
  - collinmanderson 8y ago
    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.
    - s73v3r_ 8y ago
      According to the article, that's exactly what they're doing.
  - simias 8y ago
    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.
zaroth 8y 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’.
- collinmanderson 8y ago
  > 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.
  - zaroth 8y ago
    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/DeveloperGuide/cf_dg.pdf#page302 https://docs.aws.amazon.com/AmazonCloudFront/latest/Develope... [2] - https://www.bamsoftware.com/papers/fronting/ https://www.bamsoftware.com/papers/fronting/
ucarion 8y ago
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."
- fwn 8y ago
  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.
  - collinmanderson 8y ago
    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.
    - bonesss 8y ago
      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?".
  - manigandham 8y ago
    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.
aeternus 8y ago
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.
- krehl 8y ago
  Souq.com is owned by Amazon.
- vertex-four 8y ago
  Except that you aren’t actually using an additional service that you’d otherwise have to pay for, so that analogy is bullshit.
- Dylan16807 8y ago
  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.

by dice 8y ago

simias 8y ago

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.

zaroth 8y ago
The beauty of this is they are not doing anything on the server side to impersonate or spoof Amazon.
- collinmanderson 8y ago
  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.
  - s73v3r_ 8y ago
    According to the article, that's exactly what they're doing.
- simias 8y ago
  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.

zaroth 8y 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’.

collinmanderson 8y ago
> 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.
- zaroth 8y ago
  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/DeveloperGuide/cf_dg.pdf#page302 https://docs.aws.amazon.com/AmazonCloudFront/latest/Develope... [2] - https://www.bamsoftware.com/papers/fronting/ https://www.bamsoftware.com/papers/fronting/

ucarion 8y ago

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

fwn 8y ago
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.
- collinmanderson 8y ago
  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.
  - bonesss 8y ago
    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?".
- manigandham 8y ago
  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.

aeternus 8y ago

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.

krehl 8y ago
Souq.com is owned by Amazon.
vertex-four 8y ago
Except that you aren’t actually using an additional service that you’d otherwise have to pay for, so that analogy is bullshit.
Dylan16807 8y ago
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.