6 ms·
Ask HN: Why doesn't someone provide JS encrypted webmail
I think there is a market for someone to provide client side passphrase encrypted webmail, that is truly secure both from intruders and the mail hosting servers. Why don't webmail companies or a startup provide that?
- zokier 16y agoA GnuPGP-extension for Firefox (or Chrome), enabling encrypting or signing any text boxes. Sounds possible, don't know how well it would react with rich editing forms. edit: complemented with a web-service storing your keys in the 'cloud'.
- pmjordan 16y agoThere's FireGPG. It's kinda meh in practice. I ended up going back to using Thunderbird for signed emails (invoices, generally) because it was so fiddly and sometimes just didn't want to work, especially with attachments.
- rwolf 16y agoFireGPG recently shut down, put used to provide this.
- hendler 16y agoThere are grease monkey scripts that do this. Maybe because there is very little demand?
- baltcode 16y agoIf more people became aware how much of their profile resides with ISP's, DNS providers, and email hosts, I think many would prefer such a thing. Google, by the way is a DNS provider, search gateway, email host, AND an advertiser. It might be popular if it was free (you can still have some advertising), and actually secure. I'd imagine at least a portion of the hacker community would gravitate to it. Are you talking about this? http://www.langenhoven.com/code/emailencrypt/gmailencrypt.php http://www.langenhoven.com/code/emailencrypt/gmailencrypt.ph... I'll check it out, though I thought it had some issues with the latest version of FF.
- retube 16y agoThat link looks like it could be what the OP is after. The _only_ caveat is you need recipients to tell you where their key is stored. It would be good if there was a service that stored public keys keyed by email.
- Tichy 16y agoI 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.
- baltcode 16y agoI think people don't use pgp because you have to install a client. People want to be able to access their mail from their home PC, work PC, laptop, friend's laptop and the library. Also, we want to remember our own pass-phrase rather than a private/public key.
- fhars 16y agoBut then the described service is useless, because you can only trust the confidentiality of your mail in so far as you can trust the honesty of the service provider not to hide backdoors in the js they send to your browser. But then you can just do away with the clunky client side cryptograpy and talk plain https with their server that does the encryption.
- baltcode 16y agoTrue, but can't there be a way to certify the complete client side source (HTML + JS)?
- tptacek 16y agoS/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).
- limmeau 16y agoWhat keeps the webmail company from supplying you with modified client-side JS code which forwards the keys you enter to $three_letter_agency?
- baltcode 16y agoExactly, and I think that's a potential problem with hushmail (but those guys are to be commended for some honesty). How about a number of independent, hacker type, or FSF type communities certify the client side JS through md5 digests on the client side code or the like?
- limmeau 16y agoBut 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).
- rwolf 16y agoTake a look at Aldo Cortesi's AppHash for one impl of verification of code right when it loads on the page.
- tptacek 16y agoCortesi 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.
- scrrr 16y agoGood question. Right now I guess from a cryptographer's point of view all our emails are basically as public as Twitter messages, if anyone cares to read them. Technically I think a purely passphrase-encrypted webmail would not be very secure, because if you used an asymmetric algorithm, the private keys would no longer be private, and if you used a symmetric algorithm you'd either have to change the pass-phrase each time or deal with a key-vulnerability. But I might be wrong. Finally the demand could probably be created if it were implemented in a user-friendly way. I think it has to, somehow, eventually. It will not be difficult to convince people to use it once it works in a simple, transparent way. After all, everyone got used to logging in everywhere, as well. In the long run, now matter how cool clients like GMail are, we should not leave our private communication to others and especially not to companies. Perhaps it requires a person similar to Mark Shuttleworth with a lot of resources and a philantropic drive to start thinking about a solution.
- baltcode 16y agoIf the private keys were stored pass-phrase encrypted it could work, and the weakest link of your private key/passphrase defines your security.
- scrrr 16y agoYes but then you'd also have to store them across all installed clients/browsers and, when accessing from another computer, first transport the keys to that computer. That's why I think public keys would be the user-friendly way. Public = Only passphrase protects the key.
- baltcode 16y agoRight, that's what I meant actually. It seems like something that should already exist.
- jessor 16y agoI rememember there was someone on HN working on that a few years back. There was a nice discussion around it. I can't find the thread, perhaps someone else has better luck?
- fauigerzigerk 16y agoProbably because it's a feature, not a viable business of its own. So existing web mail providers would have to do it, but they won't because it runs counter to their ad targeting practices.
- retube 16y agoI was thinking something similar recently. Not necessarily a web-app, but an app that encrypted message in the client, and was only decrypted on receipt. So even if the mail/message server/store was hacked, none of the messages would be readable.
- konad 16y agoOur webmail installation encrypts the password on the client side, it's never sent in plain and we never know what it is. It's not hard, various crpyto libs are available for Javascript. I've written multiple HTML based login systems that never require knowledge of the plain text Is that what you mean ? Edit: Oh, you mean we never know the plaintext of the email. You mean like this : http://www.hanewin.net/encrypt/ http://www.hanewin.net/encrypt/ http://46dogs.blogspot.com/2007/11/encrypting-to-pgp-gnupg-gpg-using.html http://46dogs.blogspot.com/2007/11/encrypting-to-pgp-gnupg-g... http://stackoverflow.com/questions/2802541/pgp-encryption-in-javascript http://stackoverflow.com/questions/2802541/pgp-encryption-in... tl;dr - too slow
- leif 16y agoNo, the OP is talking about encrypting the data (the mail), not the credentials (the password). EDIT: oh, you caught on
- leif 16y agoBecause we've already got pgp, and when we can get the people we communicate with to use it, we don't mind using a command-line program (or a browser plugin, though we don't even really trust that) to decrypt. We definitely wouldn't trust some webapp's javascript to decrypt for us, unless we'd written it ourselves. Then there's the question, which someone alluded to, of how to distribute new credentials to a browser that hasn't logged on before, and how to make sure they're deleted securely after I leave. Do you store the private keys encrypted and send them to the browser so they can be decrypted with my passphrase? I probably don't trust you to store even an encrypted version of my private keys, but I guess I can use a throwaway key for your service. What I'm most worried about is the question: who is doing the encrypting? Are people sending mail to this address required to encrypt email to me? If not, are you going to encrypt my email as soon as it hits your servers? Not good enough, you may as well leave it in plaintext and use it to serve me ads. The biggest problem with encrypted email today is that nobody uses it, and this doesn't fix that. It makes it easier (if it works, and I'm still not convinced it does) for people who already use it to do so, but it doesn't convince people that don't use the service (which is going to be a vast percentage of the people that don't use pgp now) that they should want encrypted mail.
- smarterchild 16y agoIf you make it, I'll would use it.
- epostalservices 16y agoThis already exists: www.epostalservices.com
- smarterchild 16y agoOutlook only. The original post was about webmail, sorry.
- eli 16y agoBecause if you're actually concerned about the privacy and security of your messages then webmail ain't ever gonna cut it.
- pjscott 16y agoI 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.
- eli 16y agoIt would be trivial for anyone with access to the webmail provider's server to steal your password and decrypt your mail. So you don't really gain much by having it encrypted there in the first place.
- pjscott 16y agoI was assuming that my private key would be stored locally. And the encryption code, too. As I said, doing this securely and usably would be hard.
- gojomo 16y agoThe conscientious/paranoid people who care enough to engage in encrypted correspondence will want to run their own client software. (Typing their passphrase into the hoster's provided JS/DOM, even in a browser under their own control, is essentially the same as sending it to their server. Maybe you could work out something with a bookmarklet, which scrapes ciphertext from one page but then displays the plaintext in another window entirely, but at that point, are you still enjoying the convenience of webmail?)
- baltcode 16y agoTrue, its just that the client software should be able to run on many computers etc. i.e., one should be able to use their friends laptop to check email for 5-10 minutes, AND be secure. (disregarding key loggers and the like)
- kogir 16y agoBecause crypto in JavaScript would likely be vulnerable to side channel attacks (timing, processor use analysis, power analysis, etc). Even FIPS certified java and .net libraries call into c code. There's a reason. Also, the number of people who even know what you're talking about is vanishingly small, and few of them would pay.
- baltcode 16y agoHow about advertising?
- pmjordan 16y agoI 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 window.postMessage() in some way? The plaintext could be displayed in an IFrame running in that local context. Then there's the issue of unencrypted incoming mail. You'd need to trust the SMTP server operator to encrypt any incoming mail with your public key and then destroy any record of the plaintext. Metadata is also an issue: you'd want to encrypt headers as well as the body, as knowing when you communicate with whom is almost as valuable as knowing the content of said communication. Encrypting it is easy, indexing it for efficient access less so. Still, this could exist as a self-hosted package for the more paranoid as well as SaaS.
- morroccomole 16y agoThe 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.
- david_shaw 16y agoIt'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 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?
- tptacek 16y agoI don't know why anyone would have downvoted this comment; clientside hashing is also bad, and CSRF isn't really the dealbreaker that XSS is, but it's a decent survey of the issues.
- morroccomole 16y agoWorking on this exact problem myself: https://droplettr.com 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.
- baltcode 16y agoThis looks cool. Is there a way to know that the client side code has not been tampered with? I'd like to see more people comment on this one.
- tptacek 16y agoThere 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.
- SriniK 16y agoI 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.
- tptacek 16y agoWhen you talk about "RSA, AES, HMAC", you leave me to wonder whether you're actually implementing a standard like PGP or S/MIME, or whether you've invented your own encryption scheme. I hope for your sake it's former, and not the latter. Know that most large companies do use encrypted mail, and have a standard that their partners must use.
- SriniK 16y agoYes. I am going to support OpenPGP. As you said, inventing own encryption is not a smart thing to do.
- 16y ago
- DenisM 16y agoYou can start a new startup from technology or from a market need. Start with market first, the question you should be asking is "who needs to communicate privately, wants to pay for it, and was not able to do that so far in a satisfactory manner?". Once you figure it out you might realize that most of the "it's impossible to do perfect, hence no point in doing it at all" concerns while generally valid do not apply to your target market. And from there it's perfectly doable and might be a good business too. edit: doesn't have to be about email either - the need is first and foremost. it could be well just a private messenger platform.