7 ms·

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

88 points by kpdemetriou 2y ago

_dwtv 2y ago
Lack of streaming support in the API makes this DOA for many use cases. Fully buffered APIs like these are an unideal abstraction and should be avoided for any large or streamed resources.
- kpdemetriou 2y ago
  One of the authors here. Streaming is actually in the works.
canadiantim 2y ago
Seems great, but unfortunately it’s JavaScript. Would’ve loved if it were Python
- SahAssar 2y ago
  It's designed to be able to run in a web app, you can't run python there without including a lot more dependencies.
- josephcsible 2y ago
  Why? E2EE inherently needs to run on the client, and Python isn't very practical for the client side of Web apps.
- kpdemetriou 2y ago
  I'm curious, how do you imagine using it in Python?
SahAssar 2y ago
Would it be possible to use this with something like webauthn/passkeys instead of passwords?
- kpdemetriou 2y ago
  In principle, yes. In practise it's not widely supported (yet). Here's a relevant blog post: https://levischuck.com/blog/2023-02-prf-webauthn https://levischuck.com/blog/2023-02-prf-webauthn
sroussey 2y ago
Is there anything like this for yjs or similar?
- kpdemetriou 2y ago
  The team behind this project (read: we) developed an expansive SDK for multi-user collaborative apps, including realtime docs. We use it to power many of the features of https://backbone.dev/ https://backbone.dev/ The multi-user scenario is significantly harder to get right without running into nasty vulnerabilities. We plan to write more about how we built it and what to look out for.
deleted 2y ago
[deleted]
dbingham 2y ago
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 to trust the code now and into the future. For trust, transparency is key. And this project has zero transparency. For all I know, this could be a state actor trying to lay the foundation for future backdoors.
- deleted 2y ago
  [deleted]
- codetrotter 2y ago
  > 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/ https://www.wired.com/story/jia-tan-xz-backdoor/
  - nextaccountic 2y ago
    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
    - codetrotter 2y ago
      If the Minibone repo turns out to be malicious I don’t think it makes much of a difference whether they are committing as one anonymous user, or as 12 fake people.
      - nextaccountic 2y ago
        Tracking the fake people still give some information (for example, the more sock puppets, the harder it is to simulate discussions in issues, PRs, etc)
djbusby 2y ago
What about using the libsoduim JS? It seems pretty OK to me. It's from a pretty source too.
- kpdemetriou 2y ago
  It's much more bare-bones. Minibone exposes a more approachable and misuse-resistant higher-level API including support for things like opportunistic key rotations and groundwork for forward evolution!
tptacek 2y ago
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?
- kpdemetriou 2y ago
  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.
  - tptacek 2y ago
    "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.
    - kpdemetriou 2y ago
      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.
camgunz 2y ago
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?
- deleted 2y ago
  [deleted]
- sroussey 2y ago
  This would pretty much block subpoenas for user data, since the server doesn't have it.
  - camgunz 2y ago
    It sounds like they're doing serverside key management (maybe not?); if that's true they do have it.
- kisamoto 2y ago
  > 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 that you know the server can't decrypt. > the unencrypted stuff lives somewhere 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? > Apps that want "security after TLS" just encrypt it serverside, which is generally better Why is this "generally better"? With client side encryption I can see my data, the server and any third-parties cannot. With server side encryption I have to send plain text. TLS protects this from third-party observers but anyone server side - now or in the future - can access my data. There is also the possibility of future breaches as encryption at rest stops at attacker running away with a harddrive but does not stop an attacker accessing a running database and dumping all the decrypted contents.
kisamoto 2y ago
There seems to be a lot of skepticism in the comments but I can definitely see a use-case for this (I have no relationship to the project). Ultimately, plain text data should never reach the server and the server will never have access to decryption keys either. Row level encryption; encryption at rest etc. is not the same as in those cases the data arrives at the server in plain text which can end up in logs, can be directed to other parts of the business or in invisible changes the server may just stop encrypting the data. By encrypting client side, I - as a user - can be sure that my data can't be mined, analyzed or leaked. I acknowledge that there is the poisoned binary attack - serving malicious javascript files to future visitors - but this may happen somewhere along the supply chain for any application. Whether it's an app from an app store (e.g. Signal) or a desktop app (Thunderbird + PGP) at some point updates are provided to client apps and as we have seen recently, even dependencies to these apps are vulnerable. SRI and maybe clearly showing the version of encryption library being used would probably go a long way. Services such as Proton also rely on JS delivered to the browser. In short, a lot of applications could benefit from adding a layer of encryption to their data. The truly paranoid may not be happy putting their trust in a javascript blob but the vast majority of people would benefit from having a little extra privacy-by-default in their lives.
- deleted 2y ago
  [deleted]
jslakro 2y ago
How you can tranform minibone adoption into a sell point? A non technical end user is not able to verify that an specific user is using an e2e library. It's probably limited to FOSS

88 points by kpdemetriou 2y ago

Lack of streaming support in the API makes this DOA for many use cases. Fully buffered APIs like these are an unideal abstraction and should be avoided for any large or streamed resources.

kpdemetriou 2y ago
One of the authors here. Streaming is actually in the works.

canadiantim 2y ago

Seems great, but unfortunately it’s JavaScript. Would’ve loved if it were Python

SahAssar 2y ago
It's designed to be able to run in a web app, you can't run python there without including a lot more dependencies.
josephcsible 2y ago
Why? E2EE inherently needs to run on the client, and Python isn't very practical for the client side of Web apps.
kpdemetriou 2y ago
I'm curious, how do you imagine using it in Python?

SahAssar 2y ago

Would it be possible to use this with something like webauthn/passkeys instead of passwords?

kpdemetriou 2y ago
In principle, yes. In practise it's not widely supported (yet). Here's a relevant blog post: https://levischuck.com/blog/2023-02-prf-webauthn https://levischuck.com/blog/2023-02-prf-webauthn

sroussey 2y ago

Is there anything like this for yjs or similar?

kpdemetriou 2y ago
The team behind this project (read: we) developed an expansive SDK for multi-user collaborative apps, including realtime docs. We use it to power many of the features of https://backbone.dev/ https://backbone.dev/ The multi-user scenario is significantly harder to get right without running into nasty vulnerabilities. We plan to write more about how we built it and what to look out for.

deleted 2y ago

[deleted]

dbingham 2y ago

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 to trust the code now and into the future. For trust, transparency is key. And this project has zero transparency. For all I know, this could be a state actor trying to lay the foundation for future backdoors.

deleted 2y ago
[deleted]
codetrotter 2y ago
> 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/ https://www.wired.com/story/jia-tan-xz-backdoor/
- nextaccountic 2y ago
  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
  - codetrotter 2y ago
    If the Minibone repo turns out to be malicious I don’t think it makes much of a difference whether they are committing as one anonymous user, or as 12 fake people.
    - nextaccountic 2y ago
      Tracking the fake people still give some information (for example, the more sock puppets, the harder it is to simulate discussions in issues, PRs, etc)

djbusby 2y ago

What about using the libsoduim JS? It seems pretty OK to me. It's from a pretty source too.

kpdemetriou 2y ago
It's much more bare-bones. Minibone exposes a more approachable and misuse-resistant higher-level API including support for things like opportunistic key rotations and groundwork for forward evolution!

tptacek 2y ago

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?

kpdemetriou 2y ago
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.
- tptacek 2y ago
  "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.
  - kpdemetriou 2y ago
    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.

camgunz 2y ago

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?

deleted 2y ago
[deleted]
sroussey 2y ago
This would pretty much block subpoenas for user data, since the server doesn't have it.
- camgunz 2y ago
  It sounds like they're doing serverside key management (maybe not?); if that's true they do have it.
kisamoto 2y ago
> 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 that you know the server can't decrypt. > the unencrypted stuff lives somewhere 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? > Apps that want "security after TLS" just encrypt it serverside, which is generally better Why is this "generally better"? With client side encryption I can see my data, the server and any third-parties cannot. With server side encryption I have to send plain text. TLS protects this from third-party observers but anyone server side - now or in the future - can access my data. There is also the possibility of future breaches as encryption at rest stops at attacker running away with a harddrive but does not stop an attacker accessing a running database and dumping all the decrypted contents.

kisamoto 2y ago

There seems to be a lot of skepticism in the comments but I can definitely see a use-case for this (I have no relationship to the project). Ultimately, plain text data should never reach the server and the server will never have access to decryption keys either. Row level encryption; encryption at rest etc. is not the same as in those cases the data arrives at the server in plain text which can end up in logs, can be directed to other parts of the business or in invisible changes the server may just stop encrypting the data. By encrypting client side, I - as a user - can be sure that my data can't be mined, analyzed or leaked. I acknowledge that there is the poisoned binary attack - serving malicious javascript files to future visitors - but this may happen somewhere along the supply chain for any application. Whether it's an app from an app store (e.g. Signal) or a desktop app (Thunderbird + PGP) at some point updates are provided to client apps and as we have seen recently, even dependencies to these apps are vulnerable. SRI and maybe clearly showing the version of encryption library being used would probably go a long way. Services such as Proton also rely on JS delivered to the browser. In short, a lot of applications could benefit from adding a layer of encryption to their data. The truly paranoid may not be happy putting their trust in a javascript blob but the vast majority of people would benefit from having a little extra privacy-by-default in their lives.

deleted 2y ago
[deleted]

jslakro 2y ago

How you can tranform minibone adoption into a sell point? A non technical end user is not able to verify that an specific user is using an e2e library. It's probably limited to FOSS