Ask HN: Why doesn't someone provide JS encrypted webmail • Hacker News Board

Re: Ask HN: Why doesn't someone provide JS encrypted webmail

#31

Post by david_shaw » Mon, Oct 04, 2010, 5:08 PM UTC

It's hard to implement securely.

Think about this: if encryption/decryption is performed client-side (JavaScript), then any cross-site scripting (XSS) or cross-site request forgery (CSRF) could potentially leak sensitive information to an attacker. (Where are private keys stored? How can Javascript prevent client-side attacks from leaking keys/passphrases?)

That said, client-side hashing and sending of passphrases is not a new concept. This HN post (http://news.ycombinator.com/item?id=1750468) from a few days ago goes over some of the intricacies and possible security implications of client-side hashing.

As far as actual client-side crypto (meaning the algorithm itself): Javascript is simply too prone to tampering. The problem is that, let's say the user is phished or man-in-the-middled. They will then implement (edited and flawed) crypto that will appear to them to be genuine, while in fact their passphrase and ciphertext were probably just leaked all over the Russian hacker underground.

Now, I'm not saying that it's impossible to implement client-side crypto or even that those that do will immediately get hacked... I just think this is why someone hasn't really provided it as a service yet.

Oh, and one more thing--if it's client-side encrypted email, how does the plaintext get from the email server to the client? Over the web in plaintext or HTTPS?

Re: Ask HN: Why doesn't someone provide JS encrypted webmail

#32

Post by morroccomole » Mon, Oct 04, 2010, 5:15 PM UTC

Working on this exact problem myself: https://droplettr.com - the encryption uses Firefox Sync crypto module in an extension, so the crypto is done by the browser outside the scope of content JS. The rest of the app is pure JS and HTML, with a Python/Django REST-style server.

Re: Ask HN: Why doesn't someone provide JS encrypted webmail

#33

Post by morroccomole » Mon, Oct 04, 2010, 5:25 PM UTC

pmjordan wrote: post #30

I have thought about this, and I would pay for a well engineered solution for which the operators are open about the inevitable limitations. The issue of JavaScript being manipulated by the operator to steal your passphrase/key is tricky, as mentioned by others. You might be able to do the crypto part in a separate scripting context via code stored in HTML5 local storage after you've reviewed it once, and using windo…

The encryption should really take place in a scope that content JS cannot access. I also think a system like this should be built completely parallel to email systems. Email is crap and needs to be re-invented as a web app with pseudo-anonymity and Public Key Encryption on by default. Users should not even know they are using encryption.

Re: Ask HN: Why doesn't someone provide JS encrypted webmail

#34

Post by tptacek » Mon, Oct 04, 2010, 5:54 PM UTC

There are two very good reasons why nobody should bother doing this.

First: browser Javascript is the most hostile possible environment in which to implement cryptography. From actual experience: you are better off trying to implement crypto in a microcontroller, with kilobyte-denominated space for code storage, no cold-start entropy, and a few tens of bytes headroom for negotiation. Seriously: do that first, before trying (and inevitably failing) to run the Javascript gauntlet[1].

Second: the security economics of mail drastically favor Google over anything you come up with, even if you're really good. That's because the cost of a sitewide compromise at Google is stratospheric. Google is maximally incented to protect their service and has the resources and mindshare to do so. Nobody cares about someone else's bespoke mail service. People who care about mail security but don't trust Google just VPN to a private mail server.

Incidentally, Fortune 500 companies grappled with this problem many moons ago, and have adopted the strategy of "things that need to be sent over secure email will instead send links to an HTTPS web application we run onsite and call 'secure email' even though it's really just 'private file sharing'". Which makes it doubly hard to pitch this as a product idea: most of your market has already rejected the model you're considering.

This is a bad startup idea. Avoid it.

[1] For starters: in browser JS, every function call can be redefined arbitrarily many times before it gets key material, web content is allowed to influence or even rewrite that code, there's no effective way to verify code before running it, code is pulled from multiple sites, there are browser "chrome"-level security flaws still being discovered, there's no solid secure random number generation, functions are timeable, there are solid implementations of only a very few algorithms, and what remains to be implement is hazard-prone. Writing crypto code in JS is hubris, pure and simple.

Re: Ask HN: Why doesn't someone provide JS encrypted webmail

#35

Post by tptacek » Mon, Oct 04, 2010, 5:56 PM UTC

Tichy wrote: post #3

I suspect because nobody can be bothered to encrypt mail anyway? I've tried to establish pgp links with friends several times, but eventually we always fell back to unencrypted mails. Of course some super-companies might require encrypted mail, but that might not be a good enough use case to base a business on.

S/MIME encryption on Mail.app is pretty close to transparent, once you grab a personal cert. It's what I'd recommend to a small team that wanted the easiest secure mail solution.

(We use PGP).

Re: Ask HN: Why doesn't someone provide JS encrypted webmail

#36

Post by tptacek » Mon, Oct 04, 2010, 6:00 PM UTC

rwolf wrote: post #19

limmeau wrote: post #15

Earlier quoted context omitted.

But how do I verify that the JS code being served to me in this moment is the version audited by the trusted party? AFAIK, mainstream browsers have no button to compute a hash over the contents of a website. (And it's not just reusable JS libraries one would have to audit and checksum; the HTML code of individually rendered message pages could also contain JS code to subvert the security).

Take a look at Aldo Cortesi's AppHash for one impl of verification of code right when it loads on the page.

Cortesi doesn't have a solution to this problem for unmodified browsers. If you get to modify the browser, you're no longer talking about "web mail"; you might as well just write a real secure mail client, and use HTML5 for your cross-platform UI.

I find Cortesi's promotion of his web crypto tools pretty close to the "dishonesty" line. He's not dishonest. But whether he knows it or not, he's coming as close to the line as he can. People keep telling him, browsers can't safely do the things he's telling people they do. He keeps disregarding them.

Re: Ask HN: Why doesn't someone provide JS encrypted webmail

#37

Post by [deleted] » Mon, Oct 04, 2010, 6:10 PM UTC

tptacek wrote: post #34

There are two very good reasons why nobody should bother doing this. First: browser Javascript is the most hostile possible environment in which to implement cryptography. From actual experience: you are better off trying to implement crypto in a microcontroller, with kilobyte-denominated space for code storage, no cold-start entropy, and a few tens of bytes headroom for negotiation. Seriously: do that first, before…

[deleted]

Re: Ask HN: Why doesn't someone provide JS encrypted webmail

#38

Post by astine » Mon, Oct 04, 2010, 6:21 PM UTC

tptacek wrote: post #34

There are two very good reasons why nobody should bother doing this. First: browser Javascript is the most hostile possible environment in which to implement cryptography. From actual experience: you are better off trying to implement crypto in a microcontroller, with kilobyte-denominated space for code storage, no cold-start entropy, and a few tens of bytes headroom for negotiation. Seriously: do that first, before…

Not that I have any interest in this as a startup idea, but could the issues with Javascript be avoid by using Flash instead?

Re: Ask HN: Why doesn't someone provide JS encrypted webmail

#39

Post by SriniK » Mon, Oct 04, 2010, 6:27 PM UTC

I have been working on this for few months now. It is a CR/FF/SF browser extension which should work with gmail/yahoomail/hotmail. Please get in touch with me if you like to be notified - skommoori (at) gmail.com

Recently, I have pitched the idea to few people both in angel community and some of my friends and tc disrupt visitor friends that I met. As few users have mentioned in the comments, it really boils down to people having awareness. People who are familiar with the encryption see the value immediately and people with no knowledge start to question why they need security. I have decided to go release the product. It is encouraging to see someone really cares about this stuff.

When I saw the gmail/china hacking fiasco, it is so much frustrating to see how dumb found we as users are left even though matured standards (rfc822, SMIME, OpenPGP)exist. Hopefully, what I am working would solve the exact issue we have been facing and no one is working on this non sexy item.

On the technical/details side, not just encrypting the text, it is more important to encrypt the whole message including attachments. Rightnow I have the prototype which works for text message and trying to expand it to cover attachments. The problem with FireGPG or few other things that I tried include how painful it is to setup and maintain - I also think, that being the reason for not getting popularity. There are already quite a few libraries for RSA, AES, HMAC(pick your language of choice). Implementing the plugin with Javascript has serious performance and security (good luck supporting OpenPGP). So core items need to be implemented in compiled language - for me they are in C/C++. I would love to share more details about the core crypto stuff if you want to.

Re: Ask HN: Why doesn't someone provide JS encrypted webmail

#40

Post by pjscott » Mon, Oct 04, 2010, 6:27 PM UTC

eli wrote: post #26

Because if you're actually concerned about the privacy and security of your messages then webmail ain't ever gonna cut it.

I don't care at all about the privacy and security of the already encrypted and signed blobs that I would be sending to webmail, in this hypothetical scenario. Why would I? They're already encrypted and signed.

The trick is getting encrypted webmail that's actually secure, without also being so hard to use that almost nobody actually does it.