4 ms·

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

> 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 9y 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/
- caf 9y ago
  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.
nebulous1 9y ago
That would mean that Amazon was supplying Signals content as authentic Souq traffic, something that I doubt was happening.
- cryptonector 9y ago
  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).
  - computerfriend 9y ago
    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.
    - deleted 9y ago
      [deleted]
  - nebulous1 9y ago
    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.

zaroth 9y 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/

caf 9y ago
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.

nebulous1 9y ago

That would mean that Amazon was supplying Signals content as authentic Souq traffic, something that I doubt was happening.

cryptonector 9y ago
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).
- computerfriend 9y ago
  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.
  - deleted 9y ago
    [deleted]
- nebulous1 9y ago
  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.