Comment by gst | Hacker News Reader

Comment by gst | Hacker News Reader

> Just as important as what we do do is what we don’t. For example, we don’t do full message encryption (e.g. PGP) in the browser. In theory it means you “don’t have to trust us”. However in reality, every time you open your email you would be trusting the code delivered to your browser. If the server were compromised, it could easily be made to return code that intercepted and sent back your password next time you logged in; it could even just do this for specific users. It is very unlikely that a user would notice.

I don't agree.

I don't want full message encryption because I'm afraid that my email provider is reading my messages, but because I'm storing years worth of emails in my mailbox. With a provider such as ProtonMail that encrypts incoming messages with my personal key I know that if someone manages to get unauthorized access to my mailbox that person would only be able to read new emails, but none of my already archived mails. Of course it's possible that the intruder also manages to change the JS code returned to the client, but that's not the case for all of the possible scenarios where someone gets access to my mailbox. Full message encryption does not provide perfect security, but is able to significantly raise the provided level of security.

It would be fine if apps with in-browser crypto only made this sort of claim, but many/most of them are either stating or implying that users don't need to trust the service.

This is a dangerous mismanagement of expectations, and it can be argued that the risk of creating a false sense of security far outweighs any of the benefits you mention.

For most providers, like Protonmail, the decryption password is the same as your login password. I'm curious what scenario you see allowing someone other than the provider to get access to your mailbox but not also your decryption key.

That could happen via a breach of the provider's servers, or through dumpster diving for a discarded drive that the provider didn't properly wipe (in the case the data wasn't also encrypted at rest).

Email at FastMail is encrypted at rest in this sense (full drive encryption).

It's not encrypted with a separate password per-user. We don't see any security benefits there, given that every user logs in almost every day, and if they have linked a device (many of our users use IMAP from mobile clients) they will connect and sync every time there's an update.

Which changes the vector to "hack server, passively monitor for a couple of hours, gain access". The logical backflips and single-minded security outlook required to consider that significantly different from "hack server, gain access" are the kind of security theater we studiously avoid.

Full disk encryption is a clear win with no significant downsides (slightly higher CPU consumption). Per-user encryption while still providing a full email service is not a clear win, and it has significantly higher downsides.

For proton mail you could set different passwords for decryption and login

ProtonMail doesn't have access to the decryption password as it is not transferred to the server. Instead the client sends a password that's derived from it: https://protonmail.com/blog/encrypted_email_authentication/

The "client" is a webpage that exists as one of many assets delivered to your browser by the ProtonMail webmail server. The server has access to the password at any time if it wants it.

The decryption password is not the same as the login password for ProtonMail. Logging in at minimum requires entering your username, your login password, and your mailbox password.

The result is security at rest, which fastmail does not have. ProtonMail's web app is open-source, and can be deployed locally if you wish to remove the chance of an evil app deployment.

If you use the official deployment, an evil update can obtain your mailbox password, in which case the the adversary (that is, the one capable of pushing the update) observe a security level equivalent to if security at rest was not implemented. However, even in this case, the data on the mail-servers is still protected from everyone else, so while a single adversary has observed a security level identical to that of fastmail (i.e. no security at rest), everyone else still observes a secured mailbox.

Not having security at rest is, in my opinion, dangerous.

That's wrong. You no longer need a third password in protonmail. All you need to have, in order to login, is the username and a password. If you've 2FA enabled, you need the 2FA code of-course.

I think you mean second password rather than third, but as a user of ProtonMail, I need one username, two passwords and one 2FA token to get in, with only login username/password being kept in a password manager (and all password managers get confused by multiple passwords, so I couldn't keep them all even if I changed my mind and wanted to).

ProtonMail may have the option (I am not aware of this) to have login password and mailbox password set the same (and not prompt you twice if this is the case), but they are still separate passwords. You, as user, control whether you want them to be the same or not. If you chose this, the application then has an option for convenience to use the same input for both tasks. This is opposed to a service where they are always the same, so that the password send to the backend is the same used to decrypt your data.

That's definitely not the default with Protonmail. They'll allow you to change it to that if you really want to though.

On mine at least, proton prompts me for username and password, then 2 factor auth, then the decryption code.

One password is now the default for new ProtonMail accounts. For accounts that were created before this authentication was released, you will remain on 2 password until you update it in your settings.

You can use PGP then. However using PGP well turns out to be hard. You can to have the client local (and built by a trusted source), not a web client. You have to ensure you didn't forget your private key. You have to understand how it works and what the limits are to ensure that you don't accidentally break something.

For what fastmail is doing providing PGP is the wrong answer: there is no way they can provide it safely. In particular a government can force them to replace their web PGP with a hacked version. (and some hacks can be very subtle such that you are unlikely to notice in a code review - remember we have a government's resources created it)

That isn't to say PGP is bad. PGP is better than what they offer when you use it correctly. However there are many ways to use PGP wrong which make it seem like your messages are secure, but they are in fact not. This is probably worse than not using PGP at all, at least if you know your messages are not secure you won't do anything that requires security.

All of my email is encrypted using PGP on the way in. I can read it on my laptop, desktop and phone because I use Evolution, Mutt and K-9 Mail, all three of which support PGP and all three of which I can use with my Yubikey.

If you compromise my mailbox, you can't read any old or new email, and you can trigger as many password reset emails as you want, you wont be able to read them.

ProtonMail's web client is open source, and can be deployed locally if you wish to avoid scenarios where an evil application is deployed.

Their native apps are unfortunately not open source, though.

Deploying a browser Javascript application locally does not automatically protect you from serverside malicious Javascript; you have to know a lot more about how the application is structured to know whether it's even helpful.

Deploying any application locally puts you entirely at mercy of whoever wrote it, and those that know how to abuse it. That holds true for any type of application.

However, in this context, deploying this particular self-contained application locally protects against the hypothetical attack where a genuine application is later modified to turn malicious. It is relatively easy to look for and identify any execution of server-side content.

To prove that an application is not intentionally malicious, you would have to inspect the source. To prove that an application cannot be malicious, directly or indirectly, intentionally a not, you will need full formal verification of the application. And that verification only holds if you have formal verification of what it runs on.

No, it does not. You've missed my point. Deploying a browser JS application locally would help you if you could be sure that the application never loaded any additional Javascript from the server during execution. But browser JS applications can in fact do that, and so local deployment does not help as much as you think it does.

Yes you would probably need to play with headers.

You missed my point. In multiple ways. I already accounted for remotely fetched JS in my previous comment.

It is relatively easy to find JavaScript execution points (there are only so many ways to parse and execute text string from a server in JavaScript—eval, new Function, script element, on... DOM attributes, ...), and thus it is quite easy guarantee that an application does not intentionally execute remote code (intentional is what is inside the control of the source code—an image decoding bug in the browser causing code execution is outside the scope here).

A local deployment (with proper protection of the deployment) guarantees that an application remains static, and cannot be changed arbitrarily for malicious intent. Combined with a relatively easy inspection for intentional remote code execution, you can conclude that there is no direct way for the application to turn malicious.

If you do not inspect the source, a local deployment still reduces the chance of a malicious modification being possible from "100% guaranteed" to "maybe, if the application is written in a specific way, or if there is an unintentional code execution bug somewhere in the browser".

You will of course never be able to reduce the chance of any application turning malicious to 0 without full verification of the application and platform it runs on (including all other applications running with permissions to interfere).

I don't follow, since you said none of those things --- eval, script elements, DOM attributes --- in any previous post.

I also don't understand why you think it's straightforward for people ("relatively easy", in fact) to verify that a browser JS app is server-proof. As table stakes, you'd need a comprehensive understanding of every way in which the server gets to update the DOM of the client.

They were implied as "execution of server-side content" in the sentence: "It is relatively easy to look for and identify any execution of server-side content."

It is correct that it would be complicated to do for an arbitrary hosted app that may inject server-side rendered content with scripts in them, but this is not the case here.

There are very few places where "external" content is inserted into the DOM (decrypted mailbox content that may be HTML, account info), and those should all employ proper script stripping techniques. Finding DOM append or assignment (including attribute assignment) points is relatively easy.

With the DOM out of the way, you only have places where the application intentionally executes JavaScript through eval and new Function (potentially wrapped in whatever frameworks they use).

It really isn't very hard. And yes, I have done it before—and no, I couldn't have missed something when I did it, as only interaction I had found would succeed in my sandbox.

Not to endorse the argument that a local app written in JS is inherently any more worrisome than one written for, say, .NET or GTK+ (because it's not), but this statement really sticks out:

> It is relatively easy to find JavaScript execution points

Have you ever been tasked with actually trying to guard against these things in security-critical situations? Because even with a deep understanding of the ECMA/W3C/WHATWG specs, years of experience with the arcane internals of a specific browser and JS engine, those engines' quirks wrt the way those specs are implemented, and the way they extend the specs, this was really tough even 5 years ago. The fact that JS is now an even faster moving target with yearly updates to the spec means that it's harder now. I don't think anyone who's worked on browsers would get behind the statement you made there.

Yes, I have. The list is not very long, and it is comprehensive.

At a previous place of employment, we implemented a full in-JS sandbox. The project was nasty, but as it hooked all JS execution, I do in fact have the fairly short list—what was not hooked would fail, so we were 100% sure that the list was comprehensive. Some of the entries do surprise slightly, mainly due to arcane APIs accepting both strings and function objects. New ECMAScript revisions didn't result in new execution points, although they did complicate the project in other ways.

The project also means that I could whine for ages about browser engine quirks, terrible APIs, awful specs and the likes, and will absolutely never look positively on browsers ever again.

A strict content security policy in an http-equiv meta tag is a much simpler and more effective way to accomplish this.

That will break the app if it wasn't written for it.

It doesn't change the argument, though. I'm arguing that it is relatively easy to deal with within the limits of what can be dealt with. If a strict content security policy can be applied, it just gets even easier.

I'd say that a csp is the only reasonable way to verify for a non-trivial app. A deep audit of every line of the app plus the whole dependency graph (that must be repeated on the diffs for every update) is not how I would define 'relatively easy'.

And yes, I know it will break if not written for it--I'm saying that coding to fit a strict csp is the only way to have a verifiably secure js app. Without it, you're in the jungle.

I don't mind the CSP approach, I was just stating that with it, the app either works, or everything breaks.

However, two things:

1. Nothing here requires a deep audit. Finding every execution point can be done with a bit of patience and "git grep". Some terrible frameworks, such as jQuery, can obscure things a bit, in which case knowledge of them speeds things up.

2. This may be a simple slip of words, but CSP does not in any way make your app verifiable secure. Coding towards a strict CSP is more about responsible coding and risk reduction/threat containment, by making foreign JavaScript execution non-trivial. There is nothing in a browser that lets you make something verifiably secure.

1 - Theoretically yes, but this is highly error prone and needs to be repeated on every update. Taking human factors into account, it's not a reliable strategy imho.

2 - My point isn't that a strict CSP makes the app magically secure, just that without it there's realistically no hope, and there's no point in wasting energy on trying to run a nontrivial app that doesn't have a strict CSP locally with the hope of getting around the security concerns of remotely hosted html/js.

If you load a local html file with a strict CSP into Chrome with no extensions installed, that's actually a pretty darn secure execution environment. It's much easier to verify than a native app, for example, and it can do a lot less damage. Based on a single line at the top of the file, you can be certain that the app doesn't load remote js or css, doesn't use eval, only communicates with specific domains, etc. It isn't magic, but it can get you a long way and it does offer numerous clear, concrete benefits vs. a remotely hosted app.

Reply on news.ycombinator.com