4 ms·

(I lead privacy products at CF and co-authored the linked post) This—improving trust in the system and making it provable—is something we're looking to do. Hav

(I lead privacy products at CF and co-authored the linked post) This—improving trust in the system and making it provable—is something we're looking to do. Having the publisher sign the hashes and publish the public key is one approach we've discussed. You'd be able to validate this out-of-band. Most users, however, likely won't go to this extent - a lot of the motivation behind this work was around automating the stuff that folks just don't do (like comparing hashes). Longer term we'd like to get more of these capabilities into the browser itself - comparing the hash in a separate context, validating signatures, etc - so that this is scalable. Ultimately these systems are also still built on trust: at some level there are humans in the loop, an assumption that the user's machine itself isn't compromised, and/or that the code itself is actually "correct" (for some definition of correct).

hades32 5y ago
I would have liked an example of an attack this is supposed to stop. I assume. something like this, but the article really isn't clear about that: You're using a CDN which got compromised, but your CICD servers haven't and your DNS provider also hasn't been compromise. Therefore by looking at some DNS records the browser cam verify stuff that's loaded within your domain from a 3rd party CDN. Or maybe, your TLS certs were hacked, but not the ones from the Cloudflare hash registry. TBH those don't really seem like common attack vectors. If you're a state level actor and can fake TLS, the later example doesn't work and if your CDN gets hacked, chances are high this vendor is also your DNS and CI/CD provider... What am I missing here?
dane-pgp 5y ago
It's great to hear that you want this added to browsers themselves, and you're right that browsers are more likely to implement such changes if you can show that users are deliberately installing an extension to add the missing functionality. There has been some discussion at the W3C about extending the SRI spec in this direction[0], but it seems they are reluctant to do that unless "multiple browser vendors" choose to implement something like this.[1] Hopefully the existence and adoption of this browser extension helps to solve that bootstrapping / Catch-22 problem. As for usability, would it be sufficient to just adopt a TOFU model, where the browser pins the first key it sees for a domain? To prevent the risk of permanently bricking a site (if the key gets lost, or the host gets temporarily compromised) you could politely warn the user that the key has changed, or just show a different colour icon representing that the code is correctly signed with an unknown key. [0] https://github.com/w3c/webappsec/issues/449 https://github.com/w3c/webappsec/issues/449 [1] https://github.com/w3c/webappsec-subresource-integrity/issues/85#issuecomment-570752283 https://github.com/w3c/webappsec-subresource-integrity/issue...
- elithrar 5y ago
  (Feel free to drop me an email - silverlock@cloudflare.com - if you want to chat more) We’re iterating on a standard for this - our current thinking is to use well-known URIs to publish both a public key (is the hash legit?) and hash endpoint URIs for clients to pull. The extension requirement is an “unfortunate” friction point due to needing a separate security context for hash verification. Doing this part natively will be the biggest adoption win.

hades32 5y ago

I would have liked an example of an attack this is supposed to stop. I assume. something like this, but the article really isn't clear about that: You're using a CDN which got compromised, but your CICD servers haven't and your DNS provider also hasn't been compromise. Therefore by looking at some DNS records the browser cam verify stuff that's loaded within your domain from a 3rd party CDN. Or maybe, your TLS certs were hacked, but not the ones from the Cloudflare hash registry. TBH those don't really seem like common attack vectors. If you're a state level actor and can fake TLS, the later example doesn't work and if your CDN gets hacked, chances are high this vendor is also your DNS and CI/CD provider... What am I missing here?

dane-pgp 5y ago

It's great to hear that you want this added to browsers themselves, and you're right that browsers are more likely to implement such changes if you can show that users are deliberately installing an extension to add the missing functionality. There has been some discussion at the W3C about extending the SRI spec in this direction[0], but it seems they are reluctant to do that unless "multiple browser vendors" choose to implement something like this.[1] Hopefully the existence and adoption of this browser extension helps to solve that bootstrapping / Catch-22 problem. As for usability, would it be sufficient to just adopt a TOFU model, where the browser pins the first key it sees for a domain? To prevent the risk of permanently bricking a site (if the key gets lost, or the host gets temporarily compromised) you could politely warn the user that the key has changed, or just show a different colour icon representing that the code is correctly signed with an unknown key. [0] https://github.com/w3c/webappsec/issues/449 https://github.com/w3c/webappsec/issues/449 [1] https://github.com/w3c/webappsec-subresource-integrity/issues/85#issuecomment-570752283 https://github.com/w3c/webappsec-subresource-integrity/issue...

elithrar 5y ago
(Feel free to drop me an email - silverlock@cloudflare.com - if you want to chat more) We’re iterating on a standard for this - our current thinking is to use well-known URIs to publish both a public key (is the hash legit?) and hash endpoint URIs for clients to pull. The extension requirement is an “unfortunate” friction point due to needing a separate security context for hash verification. Doing this part natively will be the biggest adoption win.