6 ms·

I keep asking, what is the threat model for end-to-end encryption in JS? Like, is there an Alice, Bob, Carol, Eve story under which E2E in JS makes sense? The

I keep asking, what is the threat model for end-to-end encryption in JS? Like, is there an Alice, Bob, Carol, Eve story under which E2E in JS makes sense? The canonical example that doesn't make sense is when Alice and Bob want to communicate privately using Eve as a webmail/chat provider who wants to snoop in on the communications. Alice and Bob can't just trust Eve to provide a copy of E2Ejs in a <script> tag on EveMail.com, because then they're trusting Eve to provide a legitimate encryption implementation, trusting Eve not to log their keystrokes in JS, etc. I can understand E2E js as a server-side library in Node (though I suspect it would be safer to run a battle-hardened library like GPG with node FFI). But, in client-side web code, how could this ever make sense?

the8472 7y ago
You can either see it as weak, best-effort security against accidental data leaks and such. Or you can follow the mega model where the hoster wants to protect itself from legal demands of monitoring user uploads that stop short of demanding encryption backdoors. It is a fairly weak and narrow security model. Nothing that should be used if you need serious security against powerful attackers.
- skrebbel 7y ago
  It might be great as an alternative to a "we store all data encrypted, pinky promise!" type of model, where eg you encrypt all messages on the backend before storing it in the DB, to reduce the potential impact of breaches, rogue employees, etc. I kind of like it for that, to be honest. There's a difference between trusting the good intentions of a company as a whole, and the good intentions and flawless skill of every single employee of it and it's subcontractors. I wonder if there's something about this approach that I'm missing. Ask HN: wouldn't you prefer that your data is browser-JS e2e encrypted than server-encrypted or not encrypted at all? In the context of "this is a web app. There's no mobile app or desktop app". I'm specifically talking about the (rather common?) case in which your threat model does contain morally misguided employees, black hat hackers and stupid mistakes, but not nation state level adversaries.
  - the8472 7y ago
    I think one issue is that for anyone with a cryptography/information security background "e2e encryption" evokes a very strong security claim where you treat the whole service provider as potential eavesdropper against which the protocol protects you, only conditional on mathematical proofs. Carving out a much more complicated boundary around various kinds of lapses on the other hand muddies the water. It can still make sense, but it is difficult to convey that clearly. More than a pinky promise, less than certifiable security. Also I would claim that black hat hackers could very well get into your production system and just inject some JS that exfiltrates cryptographic keys from users. It's blunt and far more easily caught than a targeted attack, but it can still possible and thus the system would fall short of that threat model.
    - skrebbel 7y ago
      Good point. Is there a better name for this that doesn't hint at said security claim?
      - the8472 7y ago
        Just "client side encryption", don't mention or even explicitly disavow "end-to-end" claims.
        skrebbel 7y ago
        Nice, I like it. Thanks!
blastrock 7y ago
You are right, you'd still have to trust the webmail/chat provider if you want to chat securely. Tanker still protects against data leaks from the app servers in this case. We also provide SDKs for Android and iOS. They protect against more threats as you can install an app you know the provenance and the app doesn't auto update like a website that you reload every time you open your browser. If you are concerned about security, you could even compile the apps yourself in this case.
jand 7y ago
> I keep asking, what is the threat model for end-to-end encryption in JS? Even if there were no specific attack vector guarded by client side encryption, others reasons for JS-/client-side encryption may exists. I could imagine some legal reasoning like 'The data was already encrypted when the client stored it on our servers, we had not knowledge of the illicit content.'. For a share-hoster that alone might be reason enough to feel the need for JS-/client-side encryption. Is that too far fetched?
Townley 7y ago
It could be useful in a scenario where you trust the service provider to provide a legitimate encryption implementation. If I trust Eve to provide an E2E service, in the same way I trust Whatsapp (not a given by any means), then an open source implementation of those tools lowers barriers to entry. That's a mixed bag in that it potentially enables bad security models, but overall I think access to tools is a good thing
itake 7y ago
This could be used in React Native or electronjs.
fuzz4lyfe 7y ago
Prevention of passive monitoring by commonly installed SSL interception boxes in corporate environments. This is something I would consider if I was designing a app where users complain about their employers for example. Won't stop a state level agency but it will stop the average sysadmin dead.
- AgentME 7y ago
  Cloudflare is an extremely-common service that does SSL-interception on tons of websites. If I hosted a website (with some kind of user-messaging functionality) on Cloudflare, and I trusted Cloudflare to not modify the data that went through them, but I was worried that they may be recording all the data that went through them, then using a javascript end-to-end encryption library would be perfect for my case.
y96V89C668e7Q74 7y ago
As others have posted, JS is much more than script tags in the browser. There's also React Native, Electron, Node, and many other less well known platforms for JS outside of the browser. Additionally, browser E2E encryption depends on trusting the provider just as WhatsApp or iMesssage depend on trusting Facebook or Apple. The browser is really just another delivery mechanism for code that runs on the client and you can verify the hash of code delivered from the server just as you can with desktop or mobile apps. All E2E encrypted apps will require some trust from the author except when they are open source and you can verify the hash. At a minimum, the E2E could be viewed as a best-attempt at security and would provide protection against information becoming exposed in the event of a database breach. EDIT: To be clear, the browser is a code distribution platform, just like the App Store. Both the browser and App Store can distribute both closed and open source apps, and both closed and open source apps can securely implement E2E encryption. In both cases you placing trust in the author of the code, except in the case that it is both open source AND you verify the checksum, in which you can be reasonably secure that you know exactly what code is running.
- tptacek 7y ago
  This library is very explicitly targeted to browsers and makes repeated mention of compatibility testing for them, so the parent question is on point.
  - y96V89C668e7Q74 7y ago
    No because I'm also making the argument that the browser is not much less secure than the other JS platforms.
    - tptacek 7y ago
      That argument is also quite faulty, but I'm only engaging with the other argument you made.
      - y96V89C668e7Q74 7y ago
buu700 7y ago
We aren't using Tanker, but it is possible to do this securely: https://www.cyph.com/websign https://www.cyph.com/websign
deleted 7y ago
[deleted]
z3t4 7y ago
You assume the client side code is served by the middleman. But it can also be a browser based "app" that is loaded from the hdd. Unfortunately Chrome et.al has taken a step away from this model and deprecated app manifest (? cant remember the proper name) in favour of the more convenient service worker that is able to push updates in the background. Serverless/offline web apps didnt really take off. Theres ChromeOS and FirefoxOS for feature phones. But "web apps" for desktop are currently nw.js/Electron apps. It would however be just fine to use the local browser and not ship an entire browser with the web app. Most browsers allow "chromeless" mode (without address bar etc). But there needs to be a more relaxed security mode when running code as an app. Because its almost useless now with CORS and some features requiring SSL which you cant have when loading from hhd.
ianopolous 7y ago
There are two clear scenarios where this makes sense: 1. When the client code is content-addressed, and that content addressing is enforced by the browser e.g. https://ipfs.io/ipfs/Qmfgh.. https://ipfs.io/ipfs/Qmfgh... with browsers supporting dweb protocols natively as Firefox is working on 2. When the web ui is served over localhost from an app you've downloaded and can independently verify. This could be a local only app, or it could be a p2p app.
gcb0 7y ago
Download (and check the hash, like any other application) a static one page "app" that you can open anywhere later and use to communicate/post information from any network you happen to be at?
robmccoll 7y ago
How about a different scenario? Eve is not the threat. Eve is going along serving email for Alice and Bob just fine for quite a while. Then one day Fred compromises Eve. Fred can dump data directly out of Eve's database. Depending on how Fred gains access, full disk encryption, database encryption, row-level encryption, etc. might or might not present themselves as layers of security that he must bypass. If Fred has compromised the running service, he will likely have access to the data and any keys, source material needed to derive the keys, or external decryption mechanisms (HSMs, database-side services) from within the service itself. If the messages inside of the database have been encrypted on the clients with keys not held in the server (E2E), Fred now has another layer of defense in front of him, only this one requires Fred to inject script into the clients to scrape the necessary keys. When the client is running Javascript in the browser, this is obviously easier than on clients deployed through some other mechanism, but still more difficult than being able to get everything Fred needs in memory in the server. Mainly, it's another layer of defense, and if the service is using it for other clients, a browser-based client would need to have it to function anyway (even if that weakens the security of the users choosing to use it). An alternate scenario is that Eve is also not a threat, but is instead a business that doesn't want the liability of having certain material in the plain inside of its premises ever.
- chii 7y ago
  > Eve is not the threat. But Eve is where the attacks are going to come from. Whether it's Eve's intention, or was under coersion by Fred makes no difference to the end user. Browser E2E encryption is at best marginally harder to break, but it gives the user a bigger sense of privacy than it deserves, may be to the detriment of the unlearned user.
  - robmccoll 7y ago
    I would argue that collecting keys from all of the user's browsers and dumping the database is more difficult than dumping the database alone, and that makes it worth doing. If as Fred my window of opportunity before I'm detected is small, I might only be able to get keys from users that are active within a small window. I may have to deal with CDN TTLs just to get my code to those users in the first place. The deployment setup might make it a little harder to change the code than just modifying a plaintext file on disk on the server (personally the project I'm working on right now packs static assets into the server binary making them easy enough for Eve to update, but a bit more effort for Fred). In more complex scenarios, there may be many things standing between Fred and injecting code into the browser that aren't in the way of reading the database. It really depends on the specifics of the threat that you're modeling for and how your environment works. For example, if we only focus on scenarios in which we are concerned about an attacker that has wholly compromised the service as you are describing here, we would similarly conclude that TLS serves no purpose as the attacker is already receiving the decrypted data at the other end of the pipe.
burtonator 7y ago
Here's an example... when you validate the client and run a native app. What we did was that we built out a generic datastore system which supports any storage provider backend. https://getpolarized.io/2019/03/22/portable-datastores-and-platform-independence.html https://getpolarized.io/2019/03/22/portable-datastores-and-p... But the app is downloaded. It's not just a web app that could be changed on you. If it's something that's open source and you download it you have less of an issue with people swapping out the JS on you. The idea in this situation is when you store your docs it's encrypted before we even see the data. This way you don't have to trust us. No trust required. We could even be a hostile actor and as long as your code is legit you're good to go. I like this honestly as I don't have to rely on our customers trusting us. We literally CAN NOT see your data. The main issue is getting keys between machines though. Firefox has an interesting strategy for that but I haven't had time to dive into it yet.
itslennysfault 7y ago
You can use subresource integrity in the script tag which uses a sha hash to confirm the script is what is designated in the html. However, the html could be changed in transit so the only real way this can work is if you do that AND expose the sha hash to the user who has the last known valid sha hash locally that they can manually check against. It's not pretty, but it works. https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...

the8472 7y ago

You can either see it as weak, best-effort security against accidental data leaks and such. Or you can follow the mega model where the hoster wants to protect itself from legal demands of monitoring user uploads that stop short of demanding encryption backdoors. It is a fairly weak and narrow security model. Nothing that should be used if you need serious security against powerful attackers.

skrebbel 7y ago
It might be great as an alternative to a "we store all data encrypted, pinky promise!" type of model, where eg you encrypt all messages on the backend before storing it in the DB, to reduce the potential impact of breaches, rogue employees, etc. I kind of like it for that, to be honest. There's a difference between trusting the good intentions of a company as a whole, and the good intentions and flawless skill of every single employee of it and it's subcontractors. I wonder if there's something about this approach that I'm missing. Ask HN: wouldn't you prefer that your data is browser-JS e2e encrypted than server-encrypted or not encrypted at all? In the context of "this is a web app. There's no mobile app or desktop app". I'm specifically talking about the (rather common?) case in which your threat model does contain morally misguided employees, black hat hackers and stupid mistakes, but not nation state level adversaries.
- the8472 7y ago
  I think one issue is that for anyone with a cryptography/information security background "e2e encryption" evokes a very strong security claim where you treat the whole service provider as potential eavesdropper against which the protocol protects you, only conditional on mathematical proofs. Carving out a much more complicated boundary around various kinds of lapses on the other hand muddies the water. It can still make sense, but it is difficult to convey that clearly. More than a pinky promise, less than certifiable security. Also I would claim that black hat hackers could very well get into your production system and just inject some JS that exfiltrates cryptographic keys from users. It's blunt and far more easily caught than a targeted attack, but it can still possible and thus the system would fall short of that threat model.
  - skrebbel 7y ago
    Good point. Is there a better name for this that doesn't hint at said security claim?
    - the8472 7y ago
      Just "client side encryption", don't mention or even explicitly disavow "end-to-end" claims.
      - skrebbel 7y ago
        Nice, I like it. Thanks!

blastrock 7y ago

You are right, you'd still have to trust the webmail/chat provider if you want to chat securely. Tanker still protects against data leaks from the app servers in this case. We also provide SDKs for Android and iOS. They protect against more threats as you can install an app you know the provenance and the app doesn't auto update like a website that you reload every time you open your browser. If you are concerned about security, you could even compile the apps yourself in this case.

jand 7y ago

> I keep asking, what is the threat model for end-to-end encryption in JS? Even if there were no specific attack vector guarded by client side encryption, others reasons for JS-/client-side encryption may exists. I could imagine some legal reasoning like 'The data was already encrypted when the client stored it on our servers, we had not knowledge of the illicit content.'. For a share-hoster that alone might be reason enough to feel the need for JS-/client-side encryption. Is that too far fetched?

Townley 7y ago

It could be useful in a scenario where you trust the service provider to provide a legitimate encryption implementation. If I trust Eve to provide an E2E service, in the same way I trust Whatsapp (not a given by any means), then an open source implementation of those tools lowers barriers to entry. That's a mixed bag in that it potentially enables bad security models, but overall I think access to tools is a good thing

itake 7y ago

This could be used in React Native or electronjs.

fuzz4lyfe 7y ago

Prevention of passive monitoring by commonly installed SSL interception boxes in corporate environments. This is something I would consider if I was designing a app where users complain about their employers for example. Won't stop a state level agency but it will stop the average sysadmin dead.

AgentME 7y ago
Cloudflare is an extremely-common service that does SSL-interception on tons of websites. If I hosted a website (with some kind of user-messaging functionality) on Cloudflare, and I trusted Cloudflare to not modify the data that went through them, but I was worried that they may be recording all the data that went through them, then using a javascript end-to-end encryption library would be perfect for my case.

y96V89C668e7Q74 7y ago

As others have posted, JS is much more than script tags in the browser. There's also React Native, Electron, Node, and many other less well known platforms for JS outside of the browser. Additionally, browser E2E encryption depends on trusting the provider just as WhatsApp or iMesssage depend on trusting Facebook or Apple. The browser is really just another delivery mechanism for code that runs on the client and you can verify the hash of code delivered from the server just as you can with desktop or mobile apps. All E2E encrypted apps will require some trust from the author except when they are open source and you can verify the hash. At a minimum, the E2E could be viewed as a best-attempt at security and would provide protection against information becoming exposed in the event of a database breach. EDIT: To be clear, the browser is a code distribution platform, just like the App Store. Both the browser and App Store can distribute both closed and open source apps, and both closed and open source apps can securely implement E2E encryption. In both cases you placing trust in the author of the code, except in the case that it is both open source AND you verify the checksum, in which you can be reasonably secure that you know exactly what code is running.

tptacek 7y ago
This library is very explicitly targeted to browsers and makes repeated mention of compatibility testing for them, so the parent question is on point.
- y96V89C668e7Q74 7y ago
  No because I'm also making the argument that the browser is not much less secure than the other JS platforms.
  - tptacek 7y ago
    That argument is also quite faulty, but I'm only engaging with the other argument you made.
    - y96V89C668e7Q74 7y ago

buu700 7y ago

We aren't using Tanker, but it is possible to do this securely: https://www.cyph.com/websign https://www.cyph.com/websign

deleted 7y ago

[deleted]

z3t4 7y ago

You assume the client side code is served by the middleman. But it can also be a browser based "app" that is loaded from the hdd. Unfortunately Chrome et.al has taken a step away from this model and deprecated app manifest (? cant remember the proper name) in favour of the more convenient service worker that is able to push updates in the background. Serverless/offline web apps didnt really take off. Theres ChromeOS and FirefoxOS for feature phones. But "web apps" for desktop are currently nw.js/Electron apps. It would however be just fine to use the local browser and not ship an entire browser with the web app. Most browsers allow "chromeless" mode (without address bar etc). But there needs to be a more relaxed security mode when running code as an app. Because its almost useless now with CORS and some features requiring SSL which you cant have when loading from hhd.

ianopolous 7y ago

There are two clear scenarios where this makes sense: 1. When the client code is content-addressed, and that content addressing is enforced by the browser e.g. https://ipfs.io/ipfs/Qmfgh.. https://ipfs.io/ipfs/Qmfgh... with browsers supporting dweb protocols natively as Firefox is working on 2. When the web ui is served over localhost from an app you've downloaded and can independently verify. This could be a local only app, or it could be a p2p app.

gcb0 7y ago

Download (and check the hash, like any other application) a static one page "app" that you can open anywhere later and use to communicate/post information from any network you happen to be at?

robmccoll 7y ago

How about a different scenario? Eve is not the threat. Eve is going along serving email for Alice and Bob just fine for quite a while. Then one day Fred compromises Eve. Fred can dump data directly out of Eve's database. Depending on how Fred gains access, full disk encryption, database encryption, row-level encryption, etc. might or might not present themselves as layers of security that he must bypass. If Fred has compromised the running service, he will likely have access to the data and any keys, source material needed to derive the keys, or external decryption mechanisms (HSMs, database-side services) from within the service itself. If the messages inside of the database have been encrypted on the clients with keys not held in the server (E2E), Fred now has another layer of defense in front of him, only this one requires Fred to inject script into the clients to scrape the necessary keys. When the client is running Javascript in the browser, this is obviously easier than on clients deployed through some other mechanism, but still more difficult than being able to get everything Fred needs in memory in the server. Mainly, it's another layer of defense, and if the service is using it for other clients, a browser-based client would need to have it to function anyway (even if that weakens the security of the users choosing to use it). An alternate scenario is that Eve is also not a threat, but is instead a business that doesn't want the liability of having certain material in the plain inside of its premises ever.

chii 7y ago
> Eve is not the threat. But Eve is where the attacks are going to come from. Whether it's Eve's intention, or was under coersion by Fred makes no difference to the end user. Browser E2E encryption is at best marginally harder to break, but it gives the user a bigger sense of privacy than it deserves, may be to the detriment of the unlearned user.
- robmccoll 7y ago
  I would argue that collecting keys from all of the user's browsers and dumping the database is more difficult than dumping the database alone, and that makes it worth doing. If as Fred my window of opportunity before I'm detected is small, I might only be able to get keys from users that are active within a small window. I may have to deal with CDN TTLs just to get my code to those users in the first place. The deployment setup might make it a little harder to change the code than just modifying a plaintext file on disk on the server (personally the project I'm working on right now packs static assets into the server binary making them easy enough for Eve to update, but a bit more effort for Fred). In more complex scenarios, there may be many things standing between Fred and injecting code into the browser that aren't in the way of reading the database. It really depends on the specifics of the threat that you're modeling for and how your environment works. For example, if we only focus on scenarios in which we are concerned about an attacker that has wholly compromised the service as you are describing here, we would similarly conclude that TLS serves no purpose as the attacker is already receiving the decrypted data at the other end of the pipe.

burtonator 7y ago

Here's an example... when you validate the client and run a native app. What we did was that we built out a generic datastore system which supports any storage provider backend. https://getpolarized.io/2019/03/22/portable-datastores-and-platform-independence.html https://getpolarized.io/2019/03/22/portable-datastores-and-p... But the app is downloaded. It's not just a web app that could be changed on you. If it's something that's open source and you download it you have less of an issue with people swapping out the JS on you. The idea in this situation is when you store your docs it's encrypted before we even see the data. This way you don't have to trust us. No trust required. We could even be a hostile actor and as long as your code is legit you're good to go. I like this honestly as I don't have to rely on our customers trusting us. We literally CAN NOT see your data. The main issue is getting keys between machines though. Firefox has an interesting strategy for that but I haven't had time to dive into it yet.

itslennysfault 7y ago

You can use subresource integrity in the script tag which uses a sha hash to confirm the script is what is designated in the html. However, the html could be changed in transit so the only real way this can work is if you do that AND expose the sha hash to the user who has the last known valid sha hash locally that they can manually check against. It's not pretty, but it works. https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...