3 ms·

For others that want to get more information: “ In one given scenario, if an attacker is able to obtain the private key used to sign a particular website for S

For others that want to get more information: “ In one given scenario, if an attacker is able to obtain the private key used to sign a particular website for Signed Exchanges, that attacker can then deliver false websites that appear in almost every way to be legitimate. Considering this false page in no way connects to the valid server, it would be difficult for admins to even detect. Additionally, Mozilla has publicly shared its stance that Signed Exchanges are “harmful” and will not be implemented in Firefox as currently specified. In particular, they take issue with a browser serving a particular website without connecting to its original source (or “authoritative server”). Mozilla has concerns about the shift in the web security model required for handling web-packaged information. Specifically, the ability for an origin to act on behalf of another without a client ever contacting the authoritative server is worrisome, as is the removal of a guarantee of confidentiality from the web security model (the host serving the web package has access to plain text). We recognise that the use cases satisfied by web packaging are useful, and would be likely to support an approach that enabled such use cases so long as the foregoing concerns could be addressed. A leader of Apple’s Safari development team, Maciej Stachowiak, recently backed Mozilla’s stance, adding an almost humorously phrased explanation of what Signed Exchanges for AMP really is. But even so, I’d say we are pretty uncomfortable with this approach, for similar reasons to Mozilla. We can see some advantages to Google re-serving the whole web from their own servers and getting browsers to present it as if it comes from the origin, but it also seems like a worrisome change to the web security model. ” https://9to5google.com/2019/04/18/apple-mozilla-google-amp-signed-exchanges/ https://9to5google.com/2019/04/18/apple-mozilla-google-amp-s... for those of you who want to your support the middleman: http://www.google.com/amp/s/9to5google.com/2019/04/18/apple-mozilla-google-amp-signed-exchanges/ http://www.google.com/amp/s/9to5google.com/2019/04/18/apple-...

dane-pgp 6y ago
Thanks for the clear summary. I'm still not particularly convinced by Mozilla and Apple's reasoning, though. Firstly, there are many use-cases where the content signer does not care whether an attacker has managed to steal their private key. For example, sites that just host static content (like cat pictures). There are even some hosts who don't see the point in TLS at all, as they don't believe they are hosting anything that an attacker would want to interfere with. Secondly, this is an opt-in feature and not something that would apply to all TLS certificates, so entities who considered it a genuine risk could just not use the technology. (They might also have to keep an eye on certificate transparency logs to make sure that an attacker hasn't requested such a certificate for their domain by controlling their DNS, but hosts should be doing these checks anyway, and if an attacker is in control of your DNS and has received a TLS certificate for your domain then you have bigger problems than Signed Exchanges. In any case, such certificates can be revoked once the legitimate owner has control over their domain again). Thirdly, hosts which do opt in to using Signed Exchanges can choose to include code in their signed content which sends a background HTTP request to their servers, as a way to "phone home". That wouldn't be able to detect when a key had been stolen, and it probably wouldn't reveal where the content had actually been served from (unless the specification were altered to allow signers to require that) but it would at least give signers visibility of which content was still being served. Finally, the biggest risk to websites is not that "the host serving the web package has access to plain text", because these are publicly served files which everyone has access to. The biggest risk is phishing, where a victim believes they are visiting a certain site but they're actually visiting a site with a similar-looking name, which TLS doesn't prevent and Signed Exchanges doesn't make any easier.

dane-pgp 6y ago

Thanks for the clear summary. I'm still not particularly convinced by Mozilla and Apple's reasoning, though. Firstly, there are many use-cases where the content signer does not care whether an attacker has managed to steal their private key. For example, sites that just host static content (like cat pictures). There are even some hosts who don't see the point in TLS at all, as they don't believe they are hosting anything that an attacker would want to interfere with. Secondly, this is an opt-in feature and not something that would apply to all TLS certificates, so entities who considered it a genuine risk could just not use the technology. (They might also have to keep an eye on certificate transparency logs to make sure that an attacker hasn't requested such a certificate for their domain by controlling their DNS, but hosts should be doing these checks anyway, and if an attacker is in control of your DNS and has received a TLS certificate for your domain then you have bigger problems than Signed Exchanges. In any case, such certificates can be revoked once the legitimate owner has control over their domain again). Thirdly, hosts which do opt in to using Signed Exchanges can choose to include code in their signed content which sends a background HTTP request to their servers, as a way to "phone home". That wouldn't be able to detect when a key had been stolen, and it probably wouldn't reveal where the content had actually been served from (unless the specification were altered to allow signers to require that) but it would at least give signers visibility of which content was still being served. Finally, the biggest risk to websites is not that "the host serving the web package has access to plain text", because these are publicly served files which everyone has access to. The biggest risk is phishing, where a victim believes they are visiting a certain site but they're actually visiting a site with a similar-looking name, which TLS doesn't prevent and Signed Exchanges doesn't make any easier.