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

21–30 of 73 posts

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

#21

Post by tptacek »

kpdemetriou wrote: post #19
tptacek wrote: post #17

This isn't actually end-to-end encryption, right? You have to trust the server not to corrupt the JS context to exfiltrate secrets. If that's the case (if I haven't misread something here), what is this buying you over just TLS?

Think of it this way: if your database gets breached, your app won't leak user data if your users aren't all targeted by active attackers. It's not a substitute for transport security. If active attackers are an important part of your threat model, you do want to assure the integrity of the payload - and you can ship Minibone in things like Tauri (or Electron) apps, like we do at Backbone.

"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 attacker in order to mass-exfiltrate the database, which is what you're going for, right?

But again my real point is just that you've misnamed it. This isn't E2EE. The whole reason we have the term "E2EE" is to capture not trusting the server to manage cryptographic secrecy.

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

#22

Post by kpdemetriou »

tptacek wrote: post #21
kpdemetriou wrote: post #19

Earlier quoted context omitted.

Think of it this way: if your database gets breached, your app won't leak user data if your users aren't all targeted by active attackers. It's not a substitute for transport security. If active attackers are an important part of your threat model, you do want to assure the integrity of the payload - and you can ship Minibone in things like Tauri (or Electron) apps, like we do at Backbone.

"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 the bundle.

In any case, for most use cases, database compromise is much more likely than active attacks from APTs that can break TLS.

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

#23

Post by nextaccountic »

dbingham wrote: post #8

This looks... Interesting and also weirdly suspicious. It's "made by Backbone". Backbone appears to be an enterprise security startup (?) but it's unclear because the website tells you almost nothing about the companies history, finances, or who makes up the company. The committers appear to be "Backbone Authors". The organizations membership is not visible. With something like this, trust is vital. I need to be able…

> The committers appear to be "Backbone Authors". The organizations membership is not visible.

This is slightly insane. How can they release something as Apache License if they aren't even giving out the name of the developers? Exactly WHO is licensing this source code?

There are many open source crypto libraries and it's probably not the wisest to use one authored by anonymous developers

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

#24

Post by nextaccountic »

kpdemetriou wrote: post #18
dbingham wrote: post #8

This looks... Interesting and also weirdly suspicious. It's "made by Backbone". Backbone appears to be an enterprise security startup (?) but it's unclear because the website tells you almost nothing about the companies history, finances, or who makes up the company. The committers appear to be "Backbone Authors". The organizations membership is not visible. With something like this, trust is vital. I need to be able…

I'm one of the authors. We built Minibone as a community contribution because we realized how unnecessarily vulnerability-prone E2EE app development is today - after seeing app after app repeatedly making the same mistakes. Minibone is an initial attempt to address this challenge in the single-user setting (that allows a concise and easily auditable implementation). This is all part of our broader work that you can r…

Do you have a name? Which commits you authored?

After the xz debacle, knowing who wrote which commits became important

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

#25

Post by nextaccountic »

codetrotter wrote: post #16
dbingham wrote: post #8

This looks... Interesting and also weirdly suspicious. It's "made by Backbone". Backbone appears to be an enterprise security startup (?) but it's unclear because the website tells you almost nothing about the companies history, finances, or who makes up the company. The committers appear to be "Backbone Authors". The organizations membership is not visible. With something like this, trust is vital. I need to be able…

> zero transparency > could be a state actor trying to lay the foundation for future backdoors idk if presence of “names” are a good signal to indicate otherwise either https://www.wired.com/story/jia-tan-xz-backdoor/

It's the contrary. It's only because we can identify Jia Tan's contributions that we can throw out just his contributions and revert to (say) xz 3.2

If xz contributors were anonymous, we would need to throw out the whole thing

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

#26

Post by tptacek »

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…

Right. But you do have to trust the server, unless you factor out active attackers, who can corrupt the JS context and exfiltrate secrets. If you do that, though, you don't need the clientside cryptography anymore; you can use standard, non-cryptographic browser mechanisms to make the client a root of trust for the data, but run all the cryptography serverside. (Apps have been doing this for decades, for what it's worth). Obviously, you have to trust the server when you do this --- but only because of the threat of active attackers!

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

#27

Post by camgunz »

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.

- Apps that want "security after TLS" just encrypt it serverside, which is generally better. This is fine because your users have to implicitly trust your servers.

I'm also unclear on how key management works; is it managed serverside?

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

#28

Post by [deleted] »

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.…

[deleted]

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

#29

Post by dspillett »

tptacek wrote: post #17

This isn't actually end-to-end encryption, right? You have to trust the server not to corrupt the JS context to exfiltrate secrets. If that's the case (if I haven't misread something here), what is this buying you over just TLS?

> You have to trust the server not to corrupt the JS context to exfiltrate secrets.

Yes, you do have to trust the web server(s) in that way so it isn't E2E in that sense. Though with native code E2E you need to trust the source of your app (and subsequent updates) similarly so it isn't entirely different.

You are still protected in cases where a third party attacker gains access to the data but not access to subvert the web server(s) so they send code to perform exfiltration, so there is more protection than with just TLS (or TLS plus plain encryption-at-rest).

Whether this is useful or pointless is going to be dictated by your threat model, though I'd agree it might be worth having some sort of disclaimer stating that the E2E promise might not be as solid as for other systems. Thought said promise may not be as solid elsewhere either: have you verified WhatApp's code at all? (not picking on them intentionally, just plucked them out as the first example that sprang to mind, the question is more valid with less well known services that are less likely to have any worthwhile independent checking/oversight).

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

#30

Post by tptacek »

dspillett wrote: post #29
tptacek wrote: post #17

This isn't actually end-to-end encryption, right? You have to trust the server not to corrupt the JS context to exfiltrate secrets. If that's the case (if I haven't misread something here), what is this buying you over just TLS?

> You have to trust the server not to corrupt the JS context to exfiltrate secrets. Yes, you do have to trust the web server(s) in that way so it isn't E2E in that sense. Though with native code E2E you need to trust the source of your app (and subsequent updates) similarly so it isn't entirely different. You are still protected in cases where a third party attacker gains access to the data but not access to subvert…

Right, I'm trying to figure out a coherent threat model that this addresses, in which the client-side cryptography really is load-bearing.
Post reply on HN