Comment by losvedir | Hacker News Reader

Comment by losvedir | Hacker News Reader

Sigh, the comments on this page are abysmal. Since no one has shouted the (correct) party line yet: DON'T USE CRYPTOGRAPHY IN THE BROWSER.

This is an example of cargo cult thinking: well, cryptography is good, right? It protects me. I wish I had ENCRYPTED WEBMAIL, wow!

But seriously, think for a second what the threat model is.

Do you trust the webmail host to securely store your data and only give it up under warrants, etc? If so, then ordinary plain text communication over SSL is fine.

Do you not trust the host? Then them saying "oh, look at us, we're encrypting your emails" shouldn't make you feel any better. I mean, if you use the site to view your damn emails, then THEY'RE SITTING THERE "DECRYPTED" ON THE PAGE, and the host that you don't trust can do a simple $.post(...) of its contents, for example.

I seriously fail to see any example where this library is useful. Anyone have suggestions? In your suggestion be sure to note whether you trust the host or not, and if so why not just use SSL, and if not, why the host can't just bypass it with a line of jquery.

There are circumstances where you can trust the host. For example if you run it yourself. I myself would like to run a self-hosted gmail clone if I can find a decent one.

I could even use gmail as the pop3/smtp server, if the mails are encrypted anyway.

Anyway if you control the host, and it communicates with you through SSL using a self-signed certificate, and you make sure you have no awkward browser extensions installed then your attack vectors are dwindling fast.

If you are trusting the host, why not let it do the encryption instead and make the whole system a whole lot more secure.

That is a true point :) But keep in mind that there is something to be said for not storing encrypted data on the same machine as the key.

Ofcourse once the machine is compromised it can trick you into giving it the key, but there are also countless scenarios where that is not possible. It is really an improvement onto your security.

Lets not pretend that read-protected memory is such a secure way of storing private keys.

If JS sent by server has access to your key, then by that proxy the server has access to the key too. The security is equivalent to having key stored in encrypted form and decrypted only for the duration of the session/use and the password not being stored on the server.

"Anyway if you control the host"

In other words, if the host is sitting on your desk. Chances are good that you have more control over the computer you type your messages on than some server you set up. What makes you think that the rack mount you left in your mom's basement is not being tampered with while you are away?

"your attack vectors are dwindling fast"

Now you need to trust both the host and your client machines, while before you only needed to trust your clients.

"Chances are good that you have more control over the computer you type your messages on than some server"

Wow really? I don't think those chances are good at all.. I'm not sure how often it happens that a running server is tampered with physically but I don't think that chance is as high as my client system running any malware beyond my control.

Why haven't signed browser plugins been mentioned yet? They significantly aid with the problem of code delivery.

With Chrome, Firefox, and Safari, it is possible to deliver web apps as signed, local browser plugins, applications and extensions. This greatly helps with solving the problem. In fact, I believe that it is necessary to deliver JavaScript cryptography-using webapps as signed browser extensions, as any other method of delivery is too vulnerable to man-in-the-middle attacks to be considered secure.

http://log.nadim.cc/?p=33

You appear to threat trust as something binary; either you trust a host or not? In my world trust (as well as security in general) is always a spectrum, or something more multidimensional; that you trust various host to different degrees, in different way against different threats.

Let us for example say that I have a server which you are fairly certain that noone will compromise, but you do have a concern that someone might physically steal it. In such a case you might be more likely to trust the javascript it serves than you are to trust it with storing your actual private key.

(Yes, I realize that someone who gets physical access to the machine will be able to modify its code, etc. Yet, while it might be fairly easy for someone to physically break into a building it might be harder to do so without leaving any traces behind, alerting you of possible tampering.)

By the way, my trust example above is fairly similar to the use of ssh-agent forwarding; where you trust a machine enough not to abuse an active forwarding, but without having to trust it to actually store your private ssh key.

Neither do I understand why you appear to say that SSL would provide a comparably security. OpenPGP will definitely provide a stronger transport security than the possibly of there being SMTP StartTLS being done. Likewise might OpenPGP matter for the recepient, especially if that person are doing the decryption locally on a workstation/laptop, saving that person from having to trust his/her mail provider.

We can all agree that running PGP in the browser is sub optimal for a whole host of reasons.

Here is why it might actually be a good thing:

1. Encrypting in the browser provides a more audit-able process. You still can't audit the webmail provider's server security, you can't ensure that they won't start serving borked Javascript in a month, but you can audit your data exposure assuming they do that correctly (which you have to assume anyway). Example: you have no way of verifying that <webmail-provider-X> isn't storing backups of your email on a publicly accessible endpoint (say, a public Dropbox). With PGP in browser, you may not care about that oversight.

2. Your trust in a provider is somewhat revokable. The webmail provider is able to launch an on-line attack against you by serving different Javascript, but they may not (depending on how the code is implemented) be capable of acquiring historical user data. This could be useful if, for example, an incident occurs where you no longer trust a provider (for example, after an event occurs, like Skype being sold to Microsoft, you could change providers safely assuming that Skype pre-Microsoft was 'safe').

3. Exposing a webmail PGP interface makes it easy for less technical people to communicate with people who may not trust their provider. For example, you may believe that gmail isn't going to do anything bad, and therefore have no interest in setting up Thunderbird+Enigmail. However, you may want to send email to a person who is forced to use an untrustworthy provider (and therefore uses a 'correct' PGP setup like Enigmail).

4. Exposing a webmail PGP interface allows people to play with PGP and become familiar with it before investing the time in a more robust software configuration.

Yeah. I don't understand why people don't get this. SSL already provides end to end encryption with the server. The only issue is you have to trust the server. That said, any JS that gets downloaded to the browser for execution has the same exact issue.

I see a few threat models where its useful.

The government can subpoena your emails on gmail, but I think they might have a more difficult time convincing google to change their javascript to add a $.post to steal your decrypted emails.

Also, these attacks rely on the user actively logging in. So if you are in jail or dead , your data will be safe.

One example could be indemnification of the host. A host honestly doesn't want to be a target of subpoena for a data that some users put there. So the host honestly says: sorry, all the data is encrypted and we don't have passwords for it, only the users have them. So we have no idea what's there and can't give you anything useful.

A trusted LAN where you want protection from the (physical) theft of the storage devices.

i trust my host but I do not trust the routers to the recipient.

Reply on news.ycombinator.com