Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Minibone: practical end-to-end encryption for web apps

github.com

Post reply on HN
Print view View original

61–70 of 73 posts

Re: Minibone: practical end-to-end encryption for web apps

#61

Post by camgunz »

sroussey wrote: post #34
camgunz wrote: post #27

I'm a little skeptical about this: - If I don't trust you with my data, why would I trust you to serve me the library I use to encrypt my data? - I don't think it's possible to restrict parts of your JavaScript env from a server, so even if I get minibone from a CDN, check the hash, and encrypt things clientside the unencrypted stuff lives somewhere, or the server can setup hooks to grab it before I clean it up, etc.…

This would pretty much block subpoenas for user data, since the server doesn't have it.

It sounds like they're doing serverside key management (maybe not?); if that's true they do have it.

Re: Minibone: practical end-to-end encryption for web apps

#62

Post by camgunz »

kisamoto wrote: post #39
camgunz wrote: post #27

I'm a little skeptical about this: - If I don't trust you with my data, why would I trust you to serve me the library I use to encrypt my data? - I don't think it's possible to restrict parts of your JavaScript env from a server, so even if I get minibone from a CDN, check the hash, and encrypt things clientside the unencrypted stuff lives somewhere, or the server can setup hooks to grab it before I clean it up, etc.…

> If I don't trust you with my data, why would I trust you to serve me the library I use to encrypt my data? Because trust has to be given somewhere and my business would likely fail if I'm telling you it's encrypted but actually it's not. Plus, if you were really concerned you could open up the developer tools, network tab and see the communication to the server and validate that it's only sending encrypted data tha…

> Because trust has to be given somewhere and my business would likely fail if I'm telling you it's encrypted but actually it's not.

I think in this case you'd probably want to control the keys, right?

> Plus, if you were really concerned you could open up the developer tools, network tab and see the communication to the server and validate that it's only sending encrypted data that you know the server can't decrypt.

You can't realistically do this every time; it's an opsec fail waiting to happen. That's why we hash dependencies, use TLS, etc.

> Most likely the plain text will only live in-memory in the clients browser (depends on the implementation of the software using the library though). Unless I've mis-understood your concern?

This is the "active attack" scenario, where the server is trying to get stuff from your browser you don't want it to have. The authors say that's not part of their threat model, but that's not super satisfying when companies of all types and sizes are suffering huge hacks these days.

> Why is this "generally better"?

Well for one you don't have to write and maintain a huge-ass JS encryption library.

For another, implementation and maintenance is much, much easier. You don't have to:

- (write a clientside JS encryption library, but already mentioned)

- write serverside validation that the data you're receiving is in fact encrypted the way you expect (you can only do so much here besides)

- manage clients using old versions of your library with different sets of primitives when you want to evolve

> TLS protects this from third-party observers but anyone server side - now or in the future - can access my data.

You just solve this with regular encryption. But if at any point you're trusting a server, e.g. you're loading JS from it (meaning using it at all for 99% of users) or it's storing your keys, you don't have E2EE. The whole point of E2EE is that it's secure in a hostile server scenario, i.e. active attacks.

Re: Minibone: practical end-to-end encryption for web apps

#63

Post by [deleted] »

tptacek wrote: post #53
Aachen wrote: post #47

Earlier quoted context omitted.

Server compromise is one of the threats this help manage. In your "just TLS to the server" scenario, that means all data is now instantly readable to the attacker. When all data is encrypted with keys only known to the client, the attacker first needs to take active measures and wait for everyone to log in, which may be visible to attentive clients (think reproducible builds, or the same way that someone might revers…

See above; I addressed the same claim in your sibling comment.

[deleted]

Re: Minibone: practical end-to-end encryption for web apps

#64

Post by Aachen »

tptacek wrote: post #53
Aachen wrote: post #47

Earlier quoted context omitted.

Server compromise is one of the threats this help manage. In your "just TLS to the server" scenario, that means all data is now instantly readable to the attacker. When all data is encrypted with keys only known to the client, the attacker first needs to take active measures and wait for everyone to log in, which may be visible to attentive clients (think reproducible builds, or the same way that someone might revers…

See above; I addressed the same claim in your sibling comment.

Iff you are referring to https://news.ycombinator.com/item?id=39976605 (providing a link to what you're talking about might have been more fruitful), you've not read most of my reply. They mention only data at rest or an implementation bug whereby the server stores all keys at rest in an accessible format (both a similar scenario), which I now understand you say we can still have with server-side crypto, but they don't mention and you don't seem to reply to the transparency aspect that a lot of my comment is about

Re: Minibone: practical end-to-end encryption for web apps

#65

Post by LinuxBender »

kpdemetriou wrote: post #22
tptacek wrote: post #21

Earlier quoted context omitted.

"If your users aren't targeted by active attackers" is doing a lot of work there, right? Because you can get that same level of security without an "end-to-end encryption library" --- just encrypt rows, and store the keys in localStorage, or (ick) by deriving keys from passwords, the way this seems to. All the cryptography can live on the server, and the keys can be pushed out to the client. Now you need an active at…

I'm not sure what you mean - Minibone's entire purpose is to allow you to not trust the server with users' plaintext data. Naturally, you DO need to run Minibone in an environment that's not compromised, but even if you're concerned about TLS (and there can be valid reasons to be concerned depending on your threat model), web apps can and do run in places other than the browser - that can guarantee the integrity of t…

In my opinion, if someone can break TLS such as getting your private keys then they are likely also in a position to poison your E2EE code.

I use E2EE on IRC but the code is entirely separate from the IRC server. irssi-otr using OTR Off The Record library. Provided the IRC admin does not monitor private messages and kick me off for sending text they can not read, I can have private communication with any of my friends on any IRC server knowing full well that the admin can not read it. No amount of hacks or updates to the IRC server could possibly intercept and decrypt my messages regardless of whom compels the admin to make every effort to do so. This of course makes libotr a juicy target but that's another topic similar to xz but thankfully there are not yet a significant number of people using OTR, yet.

This leaves the only remaining option of "obtaining secrets by large wrench in person" but there are countermeasures for that as well.

Re: Minibone: practical end-to-end encryption for web apps

#66

Post by camgunz »

datascienced wrote: post #42
camgunz wrote: post #27

I'm a little skeptical about this: - If I don't trust you with my data, why would I trust you to serve me the library I use to encrypt my data? - I don't think it's possible to restrict parts of your JavaScript env from a server, so even if I get minibone from a CDN, check the hash, and encrypt things clientside the unencrypted stuff lives somewhere, or the server can setup hooks to grab it before I clean it up, etc.…

This is just defence in depth. But I agree server side feels better for this. OTOH that means it is not really e2e as there is some machine with your unencrypted data on it ready to be hacked. The ideal solution would be a web api. Seems like this is only available low level with a “don’t use this to roll your own” disclaimer. What would be ideal would be a string->byte[] function in the web api that encrypts (and on…

> But I agree server side feels better for this. OTOH that means it is not really e2e as there is some machine with your unencrypted data on it ready to be hacked.

It's true this is a step up from "non-encrypted at rest", which has been pretty troublesome. But the whole point of E2EE is to defend against a hostile server. I can't understand the point of releasing an encryption toolkit, labeling it as "implements E2EE", but then ruling out the very thing E2EE is supposed to address from your threat model. The only reasonable thing to conclude is that this isn't E2EE. I'm not saying it's dangerous, or even that it's worthless, just that it's mislabeled.

Re: Minibone: practical end-to-end encryption for web apps

#67

Post by defend »

tptacek wrote: post #43
kisamoto wrote: post #37

Earlier quoted context omitted.

It's end-to-end in the fact that it's encrypted and decrypted client side with the server only seeing ciphertext. With TLS, third party observers see ciphertext but the server sees plain text. There is an attack vector that the server offers a malicious JS file (something which any web based encryptor such as Protonmail is also "vulnerable" to) however this is also possible for other types of application too. App sto…

I didn't ask an abstract question. I'm asking specifically: what can you accomplish with designs like this that you can't accomplish with TLS and serverside encryption? When you think about that, work out what the threat model is. Yes: with serverside encryption, the server briefly sees plaintext, or can record keys. But with clientside Javascript encryption, the server can exfiltrate keys and recover the same data.…

Disclaimer: I'm a minibone co-author.

A pointed question. Under threat models where you trust (or have verified) the code being executed, this allows you to use untrusted storage (e.g. cloud databases, S3, etc.) without worrying about passive attackers being able to read your data.

Using TLS and server-side encryption, a passive attacker could install a shim to intercept data.

In practice, one usecase of Minibone would be open-source electron-style web applications where you have the necessary code transparency AND signed code versioning. Another would be self-written applications (assuming you trust yourself). Another might be closed-source internal tooling (assuming you trust your company) that's hosted on cloud infrastructure.

If I've overlooked anything, please do let me know.

Re: Minibone: practical end-to-end encryption for web apps

#68

Post by tptacek »

defend wrote: post #67
tptacek wrote: post #43

Earlier quoted context omitted.

I didn't ask an abstract question. I'm asking specifically: what can you accomplish with designs like this that you can't accomplish with TLS and serverside encryption? When you think about that, work out what the threat model is. Yes: with serverside encryption, the server briefly sees plaintext, or can record keys. But with clientside Javascript encryption, the server can exfiltrate keys and recover the same data.…

Disclaimer: I'm a minibone co-author. A pointed question. Under threat models where you trust (or have verified) the code being executed, this allows you to use untrusted storage (e.g. cloud databases, S3, etc.) without worrying about passive attackers being able to read your data. Using TLS and server-side encryption, a passive attacker could install a shim to intercept data. In practice, one usecase of Minibone wou…

I have no trouble at all with libraries like this for Electron apps. In fact, I'd go a step further and say I concede the argument for Chrome Extensions and the like. It's content-controlled code that's problematic here.

Re: Minibone: practical end-to-end encryption for web apps

#70

Post by btown »

tptacek wrote: post #59
btown wrote: post #58

Earlier quoted context omitted.

It may be easier for an insider or compromised server to add a silent exfiltration functionality to server code, than to additionally compromise the frontend build, add a side channel by which the client could transmit the secret to the server or to a third party, and exfiltrate the data itself, all without detection. Defense in depth! Oh, and a deactivated account, where no client with secret access ever gets update…

I don't understand the first point as a claimed security level with a specific threat model. The second point, about deactivated points, is equally true of serverside encryption --- again, assume keys stored clientside, but encryption code run serverside (in fact, it can be true in applications that don't encrypt at all).

If I have a 0day for your backend stack, or you fail to upgrade a dependency, I might get RCE on your backend server and install an exfiltration system, but I would not necessarily be able to pivot to changing the frontend bundle on the static CDN without compromising the CI/CD and code review system, which (hopefully) uses isolated credentials and has strong audit logs. A threat model where even a persistent or long-running infection on backend servers allows user content (if not metadata) to remain opaque can be useful.
Post reply on HN