4 ms·

Very cool - the issue with believing that encrypting on the client is safer then relying a secure transport and a secure server is that the code on the client d

by taf2 12y ago

Very cool - the issue with believing that encrypting on the client is safer then relying a secure transport and a secure server is that the code on the client doing that encryption, came from the server. That said, it may still be an interesting layer of security to layer into your application. After all security is more about layers then absolutes.

erikb 12y ago
Yeah but "in the browser" is not "on the client". Do we have browser internal encryption engines yet? Encrypting in the JS has the problem that someone trying to read your nodes could MITM you other JS files, that allow him to read your clear text notes.
billowycoat 12y ago
This is true. And you can't be expected to verify the code every time you use it. It's more of a self-hosting solution I think.
- leni536 12y ago
  If you selfhost then you trust the server anyway. Can it be useful for forward secrecy if the server gets compromised later?
new299 12y ago
I came across this issue when I was implementing an ssh client in browser (https://www.minaterm.com https://www.minaterm.com). It's absolutely correct of course, but interesting that it's an issue in 2015. There should be a way of having the browser (outside of the JS) verify the hash/signature of a page against an external repository which would verify that this page had been independently audited. It's interesting that it's relatively easy to do this with native client software (hash/signature, manually check it), but less so with browser based applications.
skrebbel 12y ago
This is the usual argument in HN when client-side encryption comes up, and I have a question about it. Doesn't virtually all encryption on user computers come from servers? I mean, Chrome updates itself from a server, and I first downloaded it from the same server. Google (or anyone breaking in to Google) could maliciously break the SSL code in my browser and I'd never even know it had been updated. Likewise, I downloaded dropbox and putty and ssh.exe from servers, all apps I installed on my phone came from a server and were put there by people I don't know at all. Why is in-browser encryption considered so different that even smart people like tptacek get all worked up about it? Is it that browser apps get "reinstalled" on every use, and not "only" when an autoupdater or user detects a new version? If so, can I use appcache to achieve the same and enjoy the exact same security as I'd get in an installed app(lication)? In short, what am I missing? (note to the angry security people: I'm not dissing you, I really don't know. I'd appreciate non-snarky replies)
- captainmuon 12y ago
  Right, whether you use a native or a web app, you have to trust two things: The developer of the app, and the SSL infrastructure (assuming of course you use https). A rouge developer or a compromized CA can harm you in any case. The problem with in-browser encryption is when it replaces https. In that case, you have no insurance that the key hasn't been seen/touched by a man-in-the-middle attacker. What in-browser-encryption on top of https does is it protects you in the case that the (honest!) app provider has a data breach. They never had your plaintext to begin with.
  - handsomeransoms 12y ago
    Whether or not this is acceptable depends on your threat model. If you believe your adversary might compromise or coerce the service operator, then you cannot trust in-browser encryption even if it is served over https - the code sent to you could be modified to be malicious, and you have no way to prevent or even detect that this is happening. See the Tor Freedom Hosting [0] incident for an example of how LEA already do this. So, the inability to guarantee integrity of a web application remains a problem. TLS helps, but falls short if your adversary can MITM TLS or compromise/coerce the service operator. Web applications unfortunately make this a very convenient attack vector, since their code gets reloaded from the server so frequently and remote code execution (RCE) is trivial to achieve on the web platform (XSS, browsers are full of exploitable bugs). [0] http://www.wired.com/2013/09/freedom-hosting-fbi/ http://www.wired.com/2013/09/freedom-hosting-fbi/
fiatjaf 12y ago
Having the client page hosted at something like IPFS would solve this problem. The content of the webpage (and all its javascript references) would be the same whenever you had the same address, so you could be sure the code was safe.
davidbanham 12y ago
The point is that the web is very geared towards "Seamlessly get the latest content from the server without bothering the user". That's not necessarily what we want in the land of crypto. We want something more like "Offer to get the latest code from the server, but ask the user for permission first, because maybe the server has been compromised."

by taf2 12y ago

erikb 12y ago

Yeah but "in the browser" is not "on the client". Do we have browser internal encryption engines yet? Encrypting in the JS has the problem that someone trying to read your nodes could MITM you other JS files, that allow him to read your clear text notes.

billowycoat 12y ago

This is true. And you can't be expected to verify the code every time you use it. It's more of a self-hosting solution I think.

leni536 12y ago
If you selfhost then you trust the server anyway. Can it be useful for forward secrecy if the server gets compromised later?

new299 12y ago

I came across this issue when I was implementing an ssh client in browser (https://www.minaterm.com https://www.minaterm.com). It's absolutely correct of course, but interesting that it's an issue in 2015. There should be a way of having the browser (outside of the JS) verify the hash/signature of a page against an external repository which would verify that this page had been independently audited. It's interesting that it's relatively easy to do this with native client software (hash/signature, manually check it), but less so with browser based applications.

skrebbel 12y ago

This is the usual argument in HN when client-side encryption comes up, and I have a question about it. Doesn't virtually all encryption on user computers come from servers? I mean, Chrome updates itself from a server, and I first downloaded it from the same server. Google (or anyone breaking in to Google) could maliciously break the SSL code in my browser and I'd never even know it had been updated. Likewise, I downloaded dropbox and putty and ssh.exe from servers, all apps I installed on my phone came from a server and were put there by people I don't know at all. Why is in-browser encryption considered so different that even smart people like tptacek get all worked up about it? Is it that browser apps get "reinstalled" on every use, and not "only" when an autoupdater or user detects a new version? If so, can I use appcache to achieve the same and enjoy the exact same security as I'd get in an installed app(lication)? In short, what am I missing? (note to the angry security people: I'm not dissing you, I really don't know. I'd appreciate non-snarky replies)

captainmuon 12y ago
Right, whether you use a native or a web app, you have to trust two things: The developer of the app, and the SSL infrastructure (assuming of course you use https). A rouge developer or a compromized CA can harm you in any case. The problem with in-browser encryption is when it replaces https. In that case, you have no insurance that the key hasn't been seen/touched by a man-in-the-middle attacker. What in-browser-encryption on top of https does is it protects you in the case that the (honest!) app provider has a data breach. They never had your plaintext to begin with.
- handsomeransoms 12y ago
  Whether or not this is acceptable depends on your threat model. If you believe your adversary might compromise or coerce the service operator, then you cannot trust in-browser encryption even if it is served over https - the code sent to you could be modified to be malicious, and you have no way to prevent or even detect that this is happening. See the Tor Freedom Hosting [0] incident for an example of how LEA already do this. So, the inability to guarantee integrity of a web application remains a problem. TLS helps, but falls short if your adversary can MITM TLS or compromise/coerce the service operator. Web applications unfortunately make this a very convenient attack vector, since their code gets reloaded from the server so frequently and remote code execution (RCE) is trivial to achieve on the web platform (XSS, browsers are full of exploitable bugs). [0] http://www.wired.com/2013/09/freedom-hosting-fbi/ http://www.wired.com/2013/09/freedom-hosting-fbi/

fiatjaf 12y ago

Having the client page hosted at something like IPFS would solve this problem. The content of the webpage (and all its javascript references) would be the same whenever you had the same address, so you could be sure the code was safe.

davidbanham 12y ago

The point is that the web is very geared towards "Seamlessly get the latest content from the server without bothering the user". That's not necessarily what we want in the land of crypto. We want something more like "Offer to get the latest code from the server, but ask the user for permission first, because maybe the server has been compromised."