7 ms·

Show HN: A note taking application that encrypts in the browser

58 points by billowycoat 12y ago

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."
deleted 12y ago
[deleted]
jacques_chester 12y ago
You may have seen this: http://matasano.com/articles/javascript-cryptography/ http://matasano.com/articles/javascript-cryptography/ The brief problem statement is: Either you're on SSL, in which case, you have encryption from the client to the server. Or you don't have SSL, and a MITM attack can substitute your javascript with anything, rendering the scheme unsafe.
- ionwake 12y ago
  but cant you perform a MITM on SSL anyway?
  - leereeves 12y ago
    It's possible, but usually prohibitively difficult. (Superfish was scandalous because made MITM attacks easier on affected computers.) TLS and SSL use X.509 certificates[1] to identify who you're talking with. They're cryptographically signed by a Certificate Authority (CA), who must be one of a list of CAs stored on your computer. A MITM attack requires something rather difficult, like breaking the cryptography algorithm, access to the CA's private key, access to install a new CA certificate on your computer, or an insecure CA already on your computer (like Superfish). Edit: As jacques_chester reminded me, it's not difficult for the owner of computer to set up a MITM server, but I don't call that an "attack". 1: http://en.wikipedia.org/wiki/X.509 http://en.wikipedia.org/wiki/X.509
    - jacques_chester 12y ago
      I'm working on a client project right now. Their corporate firewall MITMs all SSL traffic. Their standard OS images all have SSL and root CA certificates installed to make this happen invisibly. The client staff we're working with had no idea this was happening.
      - leereeves 12y ago
        Yeah, not many people know about the CA store, and even if you do, and check it, there are so many pre-installed certificates that it's easy to miss a new one. No one at the company had tried to use the network with a computer they bought for themselves?
steakejjs 12y ago
In case people are interested in the under-the-hood. I just dug in a little bit and it looks like a library is used that automatically generates IV for each encrypt, and automatically uses your passphrase, passed through EvpKDF as the key. SHA3, Rabbit, and whatever EvpKDF does, I don't actually have time to look at that.
- colept 12y ago
  On binbox.io, we use a similar library called Stanford Cryptograph JavaScript Library. It's fast enough that small files decrypt and encrypt within reasonable times, but it scales poorly to large files.
ivanhoe 12y ago
Turning the client-side code into a browser extension would lessen the chances of MITM attacker tampering with the code.
billowycoat 12y ago
Ask me anything about the implementation. I'm no expert on encryption / security so there could be holes.
gojomo 12y ago
Could be interesting to allow multiple pre-existing wiki/CMS systems to serve as backends. (Potentially, then, you only bring the overlay JS from a trusted source, and your encrypted notes can live in many places, as visible-but-uninterpretable 'noise' in other systems.)
avyfain 12y ago
"This note is about a fizzy buzz that went away to become a knight. No one shall now what the rabbit ate tonight."
meesterdude 12y ago
cool! I did something similar with my side project. Users could encrypt/decrypt text in an editor, and would have to provide a password to decrypt it on the display page. Yes, its not 100% secure - you have to trust the JS, which with enough targeted effort could be swapped out for something malicious. But this does mean your data at rest is encrypted, which can be very beneficial. A bullet proof vest doesn't stop all bullets, nor does it protect everywhere. But people still use them all the time in addition to other solutions. Still, with all that if you end up with a keylogger on your machine it means nothing. Air gaping helps a lot but really nothing is totally foolproof - one can only make it exponentially more difficult to bypass.

58 points by billowycoat 12y ago

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

deleted 12y ago

[deleted]

jacques_chester 12y ago

You may have seen this: http://matasano.com/articles/javascript-cryptography/ http://matasano.com/articles/javascript-cryptography/ The brief problem statement is: Either you're on SSL, in which case, you have encryption from the client to the server. Or you don't have SSL, and a MITM attack can substitute your javascript with anything, rendering the scheme unsafe.

ionwake 12y ago
but cant you perform a MITM on SSL anyway?
- leereeves 12y ago
  It's possible, but usually prohibitively difficult. (Superfish was scandalous because made MITM attacks easier on affected computers.) TLS and SSL use X.509 certificates[1] to identify who you're talking with. They're cryptographically signed by a Certificate Authority (CA), who must be one of a list of CAs stored on your computer. A MITM attack requires something rather difficult, like breaking the cryptography algorithm, access to the CA's private key, access to install a new CA certificate on your computer, or an insecure CA already on your computer (like Superfish). Edit: As jacques_chester reminded me, it's not difficult for the owner of computer to set up a MITM server, but I don't call that an "attack". 1: http://en.wikipedia.org/wiki/X.509 http://en.wikipedia.org/wiki/X.509
  - jacques_chester 12y ago
    I'm working on a client project right now. Their corporate firewall MITMs all SSL traffic. Their standard OS images all have SSL and root CA certificates installed to make this happen invisibly. The client staff we're working with had no idea this was happening.
    - leereeves 12y ago
      Yeah, not many people know about the CA store, and even if you do, and check it, there are so many pre-installed certificates that it's easy to miss a new one. No one at the company had tried to use the network with a computer they bought for themselves?

steakejjs 12y ago

In case people are interested in the under-the-hood. I just dug in a little bit and it looks like a library is used that automatically generates IV for each encrypt, and automatically uses your passphrase, passed through EvpKDF as the key. SHA3, Rabbit, and whatever EvpKDF does, I don't actually have time to look at that.

colept 12y ago
On binbox.io, we use a similar library called Stanford Cryptograph JavaScript Library. It's fast enough that small files decrypt and encrypt within reasonable times, but it scales poorly to large files.

ivanhoe 12y ago

Turning the client-side code into a browser extension would lessen the chances of MITM attacker tampering with the code.

billowycoat 12y ago

Ask me anything about the implementation. I'm no expert on encryption / security so there could be holes.

gojomo 12y ago

Could be interesting to allow multiple pre-existing wiki/CMS systems to serve as backends. (Potentially, then, you only bring the overlay JS from a trusted source, and your encrypted notes can live in many places, as visible-but-uninterpretable 'noise' in other systems.)

avyfain 12y ago

"This note is about a fizzy buzz that went away to become a knight. No one shall now what the rabbit ate tonight."

meesterdude 12y ago

cool! I did something similar with my side project. Users could encrypt/decrypt text in an editor, and would have to provide a password to decrypt it on the display page. Yes, its not 100% secure - you have to trust the JS, which with enough targeted effort could be swapped out for something malicious. But this does mean your data at rest is encrypted, which can be very beneficial. A bullet proof vest doesn't stop all bullets, nor does it protect everywhere. But people still use them all the time in addition to other solutions. Still, with all that if you end up with a keylogger on your machine it means nothing. Air gaping helps a lot but really nothing is totally foolproof - one can only make it exponentially more difficult to bypass.