
Ask HN: Why doesn't someone provide JS encrypted webmail - baltcode
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?
======
tptacek
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._

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

This cannot be a serious answer: Some chinese already compromised Google a few
months go - they stole the "Gaia" source code. Gaia is the single-sign-on
solution for all Google services! Just because they are not unsing it on a big
scale you can be sure there are people using exploits found from the source
code to log into Google accounts.

2) "People who care about mail security but don't trust Google just VPN to a
private mail server."

A VPN in general can be considered secure. If configured properly. Same for a
mail server and for the network behind the VPN. In general: I would recommend
a secure file sharing environment focussed on security & encryption. And no,
that´s not Dropbox or box.net.

There is no better solution than GnuPG/PGP client encryption. Or at least
partially secured file sharing offers like datainherit.com or cloudsafe.com

~~~
tptacek
You think I trust "DSwiss.com", the "Swiss bank for information assets",
founded in 2006, more than I trust the largest technology company in the world
--- and presumably one of the top 10 spenders on software security worldwide?

Sorry, no, I don't. Maybe you can name one person I'd have heard of who has
assessed any piece of their source code?

------
david_shaw
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?

~~~
tptacek
I 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.

------
leif
Because 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.

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

~~~
baltcode
I 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
But 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
True, but can't there be a way to certify the complete client side source
(HTML + JS)?

------
gojomo
The 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
True, 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)

------
limmeau
What keeps the webmail company from supplying you with modified client-side JS
code which forwards the keys you enter to $three_letter_agency?

~~~
baltcode
Exactly, 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
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).

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

~~~
tptacek
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.

~~~
baltcode
Yes, but a firefox add-on is easier than a mail client. Cortesi's solution
still leaves out the problem of asymmetric encryption, and storing private
keys though.

------
scrrr
Good 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
If the private keys were stored pass-phrase encrypted it could work, and the
weakest link of your private key/passphrase defines your security.

~~~
scrrr
Yes 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
Right, that's what I meant actually. It seems like something that should
already exist.

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

~~~
baltcode
This 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.

------
kogir
Because 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
How about advertising?

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

~~~
pjscott
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.

~~~
eli
It 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
I 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.

~~~
eli
If it's impossible to check your secure mail from a friend's computer, what's
the point of having it web-based?

~~~
pjscott
The ability to check it without leaving your browser? Automatic roll-out of
new features? That warm, happy feeling of Web 2.0 shininess?

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

~~~
tptacek
When 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
Yes. I am going to support OpenPGP. As you said, inventing own encryption is
not a smart thing to do.

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

------
DenisM
You 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.

------
fauigerzigerk
Probably 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
I 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.

------
hendler
There are grease monkey scripts that do this. Maybe because there is very
little demand?

~~~
baltcode
If 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.ph...](http://www.langenhoven.com/code/emailencrypt/gmailencrypt.php)

I'll check it out, though I thought it had some issues with the latest version
of FF.

~~~
retube
That 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.

------
zokier
A 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
There'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.

------
jessor
I 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?

------
rwolf
FireGPG recently shut down, put used to provide this.

------
smarterchild
If you make it, I'll would use it.

~~~
epostalservices
This already exists: www.epostalservices.com

~~~
smarterchild
Outlook only. The original post was about webmail, sorry.

------
konad
Our 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://46dogs.blogspot.com/2007/11/encrypting-to-pgp-
gnupg-g...](http://46dogs.blogspot.com/2007/11/encrypting-to-pgp-gnupg-gpg-
using.html)

[http://stackoverflow.com/questions/2802541/pgp-encryption-
in...](http://stackoverflow.com/questions/2802541/pgp-encryption-in-
javascript)

tl;dr - too slow

~~~
leif
No, the OP is talking about encrypting the data (the mail), not the
credentials (the password).

EDIT: oh, you caught on

