3 ms·
That stuff (checking hashes, etc) is currently mostly theatre because, as you say, a nation-state can easily serve you different hashes to check. But it's pret
by EdHominem 11y ago
That stuff (checking hashes, etc) is currently mostly theatre because, as you say, a nation-state can easily serve you different hashes to check.
But it's pretty easy to imagine a feature where, similar to cert-pinning, many clients report the hashes that they see on the website and if you see something different from what everyone else does, you know something is wrong. It wouldn't need to be a "techie" feature - it would simply show a package as broken and refuse to install if it wasn't verifying, etc.
And the goal isn't some impossible 100% security, the goal is enough security to end mass interception and make the government rely on warrants and targeted tactics again.
- darkr 11y ago> That stuff (checking hashes, etc) is currently mostly theatre because, as you say, a nation-state can easily serve you different hashes to check. This is why as well as serving those hashes over HTTPS, you sign the hashes with a key, the public part of which is distributed/retrievable/verifiable via some other means.
- EdHominem 11y agoRight. But if I were attacking you and was in your site and knew that you signed your hashes I'd be targeting your build script to save your key and passphrase, or build a backdoored version at the same time. Something like Certificate Transparency for code-signing would be really solid though; tampering would stand out. https://www.certificate-transparency.org/log-proofs-work https://www.certificate-transparency.org/log-proofs-work I think there's value in the purely user-based solution though. If two people go to a site at the same time and aren't served the same binary they should be curious why, even if the company securely and auditably signed both images. And, it helps in all the cases when companies don't implement great release-security.