4 ms·
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 Prot
by TimTheTinker 7y ago
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 https://qconsf.com/sf2019/presentation/security
- acqq 7y ago> (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:// 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 https://www.usenix.org/system/files/1401_08-12_mickens.pdf