Comment by tptacek | Hacker News Reader

Comment by tptacek | Hacker News Reader

Much as I'd like it to, this article will never die. I'm still convinced directionally of the argument I made here: browser Javascript cryptography is essentially cosmetic and provides none of the assurance that cryptography normally offers for client/server applications with clientside secrets. I think I could make a better, shorter, simpler can now than I did way back when I wrote this.

Just to head off as many of the standard arguments I can remember occurring whenever this shows up on HN:

* I'm talking about browsers-qua-browsers: while Javascript is not especially hospitable to cryptography the way, say, Rust is, it's not my claim that something intrinsic to Javascript is what makes cryptography hard. In particular: Node.js serverside applications and Electron clientside applications (with some caveats) are capable hosts for cryptographic features.

* Yes, Chrome extensions do complicate the analysis for the browsers themselves (of course: application providers don't want to do Chrome extensions, because it drastically cuts down user adoption). The story with extensions is not as simple as for Electron applications.

* No, WebCrypto doesn't make any of these problems better. WebCrypto provides primitives, but the interesting vulnerabilities in cryptosystems are in the joinery; a malicious server can still exfiltrate secrets even if you're using WebCrypto.

* It remains Hard to effectively assure the integrity of whole programs delivered to browsers, because there are too many ways to update an instance of content-controlled Javascript. The standard answer of "we'll just hash the js files" has never been credible!

Recently, I heard a smart person[0] make the argument that application-level encryption, even in the browser, is a net win. It's also worth mentioning that ProtonMail and 1Password both practice application-level encryption/decryption in the browser in their front-end web clients.

App-level crypto in the browser certainly provides no added security to data transmitted over the wire, since (a) connections to back-end servers are already TLS-encrypted, (b) a breakdown of TLS implies the code running on the endpoint can't be trusted, therefore (c) assume data exfiltration when TLS breaks down regardless of other variables. I think this line of reasoning is just a restatement of your points above.

However, depending on how the back-end is set up, a zero-knowledge end-to-end encrypted vault would be impractical and even dangerous to decrypt in the cloud prior to serving it. Hence, in an end-to-end encrypted app, the chain of trust in client connections is anchored at the static file servers, the JS code they serve, and the TLS connection itself, not application servers -- the less trust app servers have to have, the better. I posit that it's easier to secure a static file server and TLS endpoint than it is to secure application servers. Furthermore, client crypto protects servers from ever seeing (or having to store/hash/cache) the whole symmetric key.

So client-side crypto can improve the security and trust calculus for server-side systems. In that case, a back-end breach of all but TLS endpoints and static file services would not expose user data.

If anyone can explain what's wrong with or missing from this line of reasoning, I am all ears -- please do!

[0] https://qconsf.com/sf2019/presentation/security

> (b) a breakdown of TLS implies the code running on the endpoint can't be trusted, therefore (c) assume data exfiltration when TLS breaks down regardless of other variables

In security engineering the main question is always "from whom do you want to protect it." If your assumed adversary can overtake both your TLS and deliver modified scripts, yes, the encryption in browser doesn't bring anything. If your assumed adversary is somebody less powerful like a passive listener somewhere the traffic is comes out of TLS, or somebody who has access to the data, but the data are already encrypted, then yes, the encryption can make a difference.

Or as one great thinker wrote for Usenix 2014: "In the real world, threat models are much simpler (see Figure 1). Basically, you’re either dealing with Mossad or not-Mossad." "If your adversary is the Mossad, YOU’RE GONNA DIE AND THERE’S NOTHING THAT YOU CAN DO ABOUT IT. The Mossad is not intimidated by the fact that you employ https:// If the Mossad wants your data, they’re going to use a drone to replace your cellphone with a piece of uranium that’s shaped like a cellphone, and when you die of tumors filled with tumors, they’re going to hold a press conference and say “It wasn’t us” as they wear t-shirts that say “IT WAS DEFINITELY US,” and then they’re going to buy all of your stuff at your estate sale so that they can directly look at the photos of your vacation instead of reading your insipid emails about them."

https://www.usenix.org/system/files/1401_08-12_mickens.pdf

My intuition is that if you wanted to (you probably shouldn't) you could implement reasonably secure client side crypto with WASM. Also correct me if I'm wrong but even in 2011 you could "securely erase" data in the browser by operating on typed arrays.

WebCrypto helps by providing a cryptographically secure RNG, that's not nothing.

FWIW I'm not trying to say the gist of the article isn't spot on, but I think the tools are more or less there these days to do the thing, even if it is absurdly easy to mess it up and there's no real good reason to try.

Reply on news.ycombinator.com