Hacker News Reader

Comment by bsdetector | Hacker News Reader

However code coming from the server can be verified, so you can know if the cryto.js delivered to you was modified from a known good version. You can audit a particular version and say, "this works correctly", and then look at changes over time.

For instance you can have a greasemonkey script that tells you when the crypto code is different from last time.

The best solution realistically would be SSL plus encrypting data first in the browser (separately encrypt the data and the transmission of it).

View on HN

If you're going to have a script/extension checking that the code you download is the code you want, then just package everything as an extension and be done with it. If you're signing with your private key and verifying with your public, you're going to have to keep your private key on separate machines from your app servers (and hopefully on another network entirely) otherwise Hacky McMalware can just publish a version of crypto.js (using your private key) that sends data to a remote server in plaintext. With all this signing going on, you no longer have automatic deployment (you have to re-sign on every change) and the benefits of serving a webapp+extension (with complexity of signing/verifying) start to look similar to just having an extension that packages everything and you sign on each change anyway.

Best solution is not to try to build any kind of webapp that touches client-side crypto. If you have to, package everything in an extension since you'll need one to distribute your public key anyway.

This post is talking about the W3C WebCrypto API, which allows browsers to expose native versions of cryptographic primitives directly into the browser. This mitigates an entire class of attacks that things like "crypto.js" can't, like cache timing attacks, for example. Providing a native JavaScript API for cryptography which is baked into the browser solves a lot of problems around both security and performance. This is also a much better solution than a GreaseMonkey script. The W3C has been doing their homework.

BUT...

That said, this entire post is about why even when the fundamentals of exposing cryptographic primitives into the browser are solved, the browser is still a bad platform for cryptography applications, particularly when the user doesn't want to trust the server.

sorry, this is only somewhat related. but i am really ignorant. this is a genuine question that i have for quite some time now.

when i download security relevant software, the website usually gives me a hash/signature of the download file, so i can verify afterwards whether the data i downloaded really is the file i want or whether it has been tampered with.

but in case an attacker switches the downloaded file for a malignant one, why should s/he be so stupid and not also switch the hash/signature on the website? i am positive i am missing something, as really smart people [0] are doing this, but i do not get it. thanks in advance.

[0] https://www.torproject.org/projects/torbrowser.html.en

The signature is generated using public key cryptography [1] meaning, to generate a valid signature, you have to have the private key.

Because the signature only has to be generated when a new version of the file is released, you can use the most bothersome (and effective) manual methods of security, like keeping the private key on an air gapped [2] computer.

So if an attacker manages to switch the downloaded file for a malicious one, they may still not have got access to the private key used for release signing.

Of course, the attacker could still remove all links to the signature file and all mention of it in the public documentation, so downloaders wouldn't know there was a signature to check. So it's better if the site isn't compromised in the first place.

[1] https://en.wikipedia.org/wiki/Public-key_cryptography [2] https://en.wikipedia.org/wiki/Air_gap_%28networking%29

So this will also probably be another seemingly clueless question, but after reading up on air gapped computers, how would that help with the new hash?

You're running into a basic bootstrapping problem: the person providing the file wants you to be able to check that the file is authentic, but you have no cryptographic mechanism to verify that.

What they're assuming is that someone who has compromised the download servers won't also compromise the rest of the web site. That's certainly a possibility though.

An attacker who compromises both could trick you into downloading compromised software, even though you're checking the hashes from the web site. There are also multiple ways they could pull this off.

For what it's work, much of The Update Framework work which I referenced in the blog post has come out of Thandy, the Tor updater. The model Tor is providing here is often referred to as TOFU, or "Trust On First Use", i.e. once you have received a good copy of Thandy, you will continue to receive uncompromised versions of the software.

add: so thanks to bascule and michaelt i now realise that the idea is basically increasing the cost to the attacker. by serving the signature and the file from different servers, the attacker has to compromise both servers. by signing with a private key and publicising the public key, the attacker has to compromise either the private key storage or all the public key storages. thanks a lot.

Reply on news.ycombinator.com