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

31–40 of 73 posts

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

#31

Post by modeless »

tptacek wrote: post #30
dspillett wrote: post #29

Earlier quoted context omitted.

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

The vast majority of users have automatic updates enabled for their native apps which makes the security properties very similar IMO.

And if you turn off automatic updates then you don't get vulnerability fixes. So you're really at the mercy of the people providing your software updates even if we like to pretend that you're not. In the event of something like a world war, theoretical concerns like these would quickly turn into actual concerns.

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

#32

Post by tptacek »

modeless wrote: post #31
tptacek wrote: post #30

Earlier quoted context omitted.

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

The vast majority of users have automatic updates enabled for their native apps which makes the security properties very similar IMO. And if you turn off automatic updates then you don't get vulnerability fixes. So you're really at the mercy of the people providing your software updates even if we like to pretend that you're not. In the event of something like a world war, theoretical concerns like these would quickl…

Having automatic updates enabled is not in fact the same thing as reloading all your cryptography code every single time you make a transaction. For a very recent and clear example of why, look what happened with xz, and note how you did not in fact get owned up (I'm sure someone did, but the odds are in my favor on this guess).

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

#33

Post by akerl_ »

nextaccountic wrote: post #23
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

Why would somebody have to list their name to Apache license something?

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

#34

Post by sroussey »

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.

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

#35

Post by modeless »

tptacek wrote: post #32
modeless wrote: post #31

Earlier quoted context omitted.

The vast majority of users have automatic updates enabled for their native apps which makes the security properties very similar IMO. And if you turn off automatic updates then you don't get vulnerability fixes. So you're really at the mercy of the people providing your software updates even if we like to pretend that you're not. In the event of something like a world war, theoretical concerns like these would quickl…

Having automatic updates enabled is not in fact the same thing as reloading all your cryptography code every single time you make a transaction. For a very recent and clear example of why, look what happened with xz, and note how you did not in fact get owned up (I'm sure someone did, but the odds are in my favor on this guess).

> you did not in fact get owned up

Not by the specific xz hack that was found. But I guarantee there are a whole lot more that haven't been found. You can't declare victory because we discovered one hacker. Effectively auditing updates for malicious code is impossible both in theory and in practice. As soon as you accept updates you're vulnerable. And if you don't accept updates you're vulnerable because it's impossible to verify that your initial install had no vulnerabilities, either intentional or accidental.

I agree that more frequent updates make a difference, but that difference can easily be in the positive direction too. And I think the overall difference is really not as big as you suggest.

Perhaps it would be useful to have something like a certificate transparency log but for the application code, so it could be retroactively audited on suspicion of foul play, and attacks that supply different updates to different users could be detected by third parties. This would be useful for native apps too.

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

#36

Post by kisamoto »

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.

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

#37

Post by kisamoto »

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?

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 stores can send malicious copies of Signal (both for initial install or (auto-)updates). Future Thunderbird updates can bypass OpenPGP encryption. Dependencies can have malicious backdoors added to affect core encryption libraries.

Trust has to be accepted somewhere along the chain, it's up to you where.

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

#38

Post by saurik »

tptacek wrote: post #30
dspillett wrote: post #29

Earlier quoted context omitted.

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

Some people finally are -- and, frankly, all of them should be, though that's another argument -- building web applications where the code for the web application itself is being loaded off of a decentralized system via a newer protocol or a gateway that they can control and which verifies the hash of the site being loaded. Also: even for services like WhatsApp Web, there are browser extensions such as Code Verify that provide most -- if not "all" or even "more than" -- the benefits you supposedly are getting by having your automatic updates re-distributed via a third-party package manager.

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

#39

Post by kisamoto »

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

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

#40

Post by kisamoto »

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…

Jumping on this, I've also noticed you don't seem to have an obvious "Terms and Conditions" or "Privacy Policy" on your site.

It's also not immediately obvious to me where the company is registered or info about the people behind the company.

For a security focused company these are all things I would expect to be rock-solid and as transparent as possible for the initial due-diligence when evaluating services like this.

Post reply on HN