This appears to be a PHP wrapper around OpenPGP.js. If the encryption comes from Javascript loaded by browsers from the servers every time they visit the site, the encryption isn't "end to end". It's controlled by the server and can be broken by the server.
Also: the RSA Security logo isn't the logo of the RSA algorithm; it's the logo of the company that sells RSA tokens.
I knew this is the first thing I would read. We are becoming pretty predictable.
I tire of hearing this repetitively, every time somebody attempts to take this path, but I recognize you are doing it for anybody that is new and didn't hear the other warnings.
Isn't the perfect the enemy of the good?
Can we recognize that this is a good first step, and definitely constitutes a huge improvement over gmail/yahoo type webmail solutions?
You can still quickly add a disclaimer that you hope they quickly begin the large task of development of native windows/mac/linux/ios/android apps that will remove the javascript concern.
If you spit on everything that is not perfect, you may be steering people away from taking any action to protect their privacy.
Not in this case, I don't think. If there's a way to break encryption, even in the smallest way, then it's not really encrypted, and calling it "good enough" does a disservice to people who actually expect it to be flawless.
Look at Lavabit, which was good but not perfect... everyone thought they were protected enough, and then the government came knocking and all of a sudden the little gotcha of "Well, Lavabit did have access to your data after all, even though they promised not to look and also be really careful about their encryption keys" is the crack they use to blow the entire thing open. (Though that was a pretty damn big crack, admittedly.)
If there's a way to break in, then it will be broken in to--and then "good enough" all of a sudden becomes "tragically and dangerously broken" for the kinds of people who trusted it the most: activists, whistleblowers, informants, political radicals, etc.
That's fair, and I do not want him to stop warning us. I recognize his expertise.
I just feel that these sorts of criticisms, that are not sandwiched with at least a little positive message, are keeping people paralyzed in gmail and yahoo and msn while they wait for perfection.
tptacek, can you suggest a design for end-to-end email encryption delivered through a browser?
As theboss mentioned [1], is:
(a) browser crypto theoretically impossible, is it
(b) that something's practically from browsers today (like build-in crypto code) for a practical solution, or is it
(c) that existing attempts have not attempted to do something that is theoretically possible?
If I understood you correctly, you alluded verification might be possible [2] but it seems there isn't yet a clear description or understanding of what's possible and what's not.
Then Gmail is more secure than this service, because Google's servers are pinned in browsers, so you can't compromise them by compromising any CA in the CA hierarchy.
I hear you dude but this is clearly not "end-to-end" encryption. End-to-end has a very specific meaning. End-to-end encryption means a messaging system in which one or more compromised node from node 1 to N-1 could not eavesdrop on the message. In this solution if you get access to node 1 (the server), you get access to the message. It's binary. There's either end-to-end encryption or there isn't. This one isn't.
> Can we recognize that this is a good first step, and definitely constitutes a huge improvement over gmail/yahoo type webmail solutions?
No its not. "Browser crypto" in the form of JS is broken. There are many different possible attacks. So a false sense of security is actually worse then no security at all.
If you're concerned about keep things private, having it technically sound is important. This application fails that and as a result deserves to be shot down.
There is no need for niceties when you're trying to promote something as secure when it isn't.
One can worry about making a system perfect once it solves the problem it sets out to solve. They chose to build on a platform (browsers) that has known security issues at a conceptual level, and have apparently ignored those issues while advertising an end-to-end secure service. That doesn't inspire trust. Perfect comes after working.
But but ... MIT, Caltech, Switzerland, CERN ... amirite?
No honestly, thank you for your comment and the ensuing discussion - most people get swayed by big names and such and reading sincere criticism of this sort of stuff is important and educating.
The JS doesn't appear to be compressed so it's possible to view source and see what exactly it's doing. So if it was actually backdoored, somebody will actually find out.
You can't just review "openpgp.min.js". You have to review every single Javascript input and every single DOM node, and any of them can alter the behavior of any other element of the Javascript runtime in subtle ways to subvert cryptography.
And you have to do this every time you load any page on the site, and any time any of those pages asynchronously load any content.
So, no, contrary to popular belief, this doesn't work.
Why can't browsers just build crypto primitives in that can be called from js?
I don't understand what people's obsession with browser crypto is...but I don't know enough about browser's to think of a reason this solution is bad. Any guidance?
edit: I understand that this won't solve all the problems...but at least the problem that you are constantly being served this chunk of potentially unsafe code.
edit2:
I've been doing some thinking. Even though I didn't really get a response I think the reason is that it doesn't buy you the ability to do anything new safely. You still have the old problems of other dom elements mucking with your dom elements that control the code, or whatever the site does...so it doesn't really buy you anything...it's just work for nothing.
I still think it would be a useful start to one day having safe browser crypto
Since you insist on a longer explanation, here goes:
You can have crypto primitives in the browser: AES, RSA, ECDSA, etc. So given a private key and cyphertext you can decrypt it and given a public key and a piece of cyphertext you can encrypt it. The actual crypto code is just a callout to libssl. In this regard, you can do this right now: simply wrap libssl from within Chrome's JS engine and you are done.
Now what? What can you actually do with this stuff? Well, you could create an email client: one that downloads a message over XHR and decrypts it. That's great, except the code to run this app is unsigned and downloaded from a remote server! I can pwn the server, add my own code that will backdoor the app and send me your private key as soon as it's in memory.
"BUT!" you say. "I can sign the code!". I say to that, how will you verify that signature? By downloading the piece of code from a remote server? I'll just pwn the server and add my own code to accept my signatures, then add the code to send me your private key.
"BUT!" you say. "I can have the signature verification code built into the browser. Look ma, no remote code download that's not signed!" I say to that, how do you know that the developer was not forced by the NSA or another powerful adversary to give up their private key or just coerced into created a backdoored package to own you specifically? You don't. You didn't grab the source and compile it. Instead, you downloaded and ran a code blob.
The solution to all of this already exists and it does not involve the web. It's called package management. Your distro already does this: multiple people review the source code that goes into every package and every step of the way is cryptographically signed. The binaries are built on trusted machines and distributed with yet more signatures. There is peer review through and through.
Compare this to a closed-source web application you are trying to secure. In this case the best you can do is say "if you trust me (the developer), and you trust that I know what I'm doing so my servers don't get pwn'ed, and you trust that I have not been coerced by the NSA/other gov't agency, then you can trust this code".
Except, you don't need client-side crypto for that. You already have HTTPS which provides the same guarantee without re-inventing a square wheel. QED.
Yes, having full source code is a sufficient condition for security. But you also implied that the hypothetical browser crypto primitives would allow one to do anything they want with the decrypted data, which might be too loose of an assumption.
For example, you could make the browser crypto primitives work so that you can only display unencrypted data (or a private key) but not be allowed to ship them off to servers.
The key idea is that you are still in control of the browser core, and that core has more control over the code shipped by the server. So you can make that core stricter than Javascript.
For example, about the problem of "other dom elements mucking with your dom elements that control the code" you can make the browser disallow this.
If I'm missing something, it's something related to these primitives. Can anyone help figure those out?
What exactly is theoretically impossible about browser crypto?
Funny. I typed up my edit2, hit enter, and had a reply from you basically saying the same thing. Also, I never said anything about use-cases, signing code, etc. Only "does this safely get you the primitives", not about what you can do with them. The "you say" in your explanation are not what I said.
I agree we need to move toward being able to build secure client apps in the browser. It's clearly "important", in that a lot of people want it, for meaningful and good reasons, and this is likely to continue. It's just not possible today.
Signed extensions are a decent step today (although installing an extension is potentially about as heavy as installing a client app, depending on how locked down your environment is).
CSP and some future extensions can be helpful.
There's server-side stuff which can help, too.
WebCrypto is a useful step.
The problem is it's going to be a long process involving a lot of parts, controlled by different parties. So it's responsible to say "we're going to build a webapp which is as secure as we can make it today; these are the known vulnerabilities". Some users are in a good position to evaluate the risks, others aren't. I care a lot more about things doing what they say they're doing than what in particular they say they're doing. The scary thing is when the people building something don't seem to know the well-known vulnerabilities.
The problem with browser crypto is that code is downloaded from the server ... nothing to install, so convenient. Right?
The danger is that you are back to trusting the server. If they are compromised, you could get served special crypto code that uploads your private pass phrase the next time you log in.
The crypto code needs to come from a trusted third party, and the protocol with the server must be dead simple and strictly arms-length, with no logic of any sort downloaded from the server. More like FTP than HTTP/HTML/JS.
There are a ton of other problems associated with crypto code. I'm talking about crypto primitives being provided by the browser. The rest of the problems associated with it, I'm not asking about.
You're echoing the problem that my question is asking if it solves...
Edit: Also, you definitely need more than the code to come from a "trusted third party", otherwise we would see SaaS startups on HN providing "crypto as a service" (god help us).
It is a long story and has been discussed one million times on here at least. Google the answer or just trust that crypto in JS cannot be not because the implementation is hard but because it is not possible in principle.
You can serve different JS to "special" users once. If you're smart, you run checks "for the security of the browser environment" first to make sure it's something unlikely to contain debugging capabilities, e.g. an unmodified iOS device.
The site even helpfully asks you to identify yourself with ANOTHER username and passphrase first, making it even safer for the attacker.
An attacker would have to (1) Gain access to the server in Switzerland (without the admins noticing) or (2) Break the SSL and execute a MITM attack.
It seems ProtonMail actively scans the code on the backend for unauthorized changes. It's not 100% secure against a very determined attacker (NSA), but for the citizen that wants more privacy without the hassle of PGP, it's pretty good until we can replace SMTP.
Honestly if it is a good usability service based in Switzerland with no special sauce, but well run, I would like it. The only problem I have is that the security asserted doesn't match the reality of a decent threat model.
Anyone that values their privacy should never trust a service like this. The idea of in-browser encryption and decryption is nothing new, and it always suffers from the fact that the server can replace the client side software at any time without warning. If you must use a browser, find a plugin that you trust that works with any webmail service. Better yet, use an actual mail client and encrypt/decrypt in that.
I think the idea of ProtonMail is to serve the part of the population that mostly uses the browser. Obviously if you wanted to be super secure, there are more sophisticated methods out there, but they aren't exactly accessible to the non-HN population. I don't think we should say, just because a perfect browser based solution isn't possible, this shouldn't exist at all. It's like saying, do something only if you can do it perfectly.
Even if I thought this was a sensible way to describe the value of the service (I don't): that's not remotely what this site says. It makes expansive claims about security, which it can't possibly back up. Why should ordinary people be expected to trust them with secrets?
Funny, when I hear "Switzerland" I think about how just this morning I heard that the American IRS has finally broken the long standing tradition of Swiss banking privacy, and that CreditSuisse will be paying billions of dollars in fines.
> By using a CA owned by the Swiss government, we ensure the highest security for our users because it is extremely unlikely SwissSign can be coerced into validating another website impersonating us
This is a dangerous and insane misunderstanding of the trust relationships work in the public CA system.
Any CA can impersonate any site. Your choice of CA has no bearing on your exposure to this risk.
(If this were an app or browser extension, you could plausibly pin the right certificate path to only trust SwissSign. But if you can do that, you can just pin your certificate and don't need a CA at all.)
Encryption to keys that are not properly authenticated is more unsafe than no encryption at all.
This holds up "No private / public key management." as a feature. Without key management (specifically, secure generation, storage, and authentication) encryption is worse than useless.
This is a browser addon, right?
Is everything loaded locally? If no, what prevents you from putting up some javascript that transfers the decryption password (or the plain text) to you.
Sorry, didn't bother to download and look for the source code, to find out how the inner mechanics work. The website doesn't give much information either.
No, it doesn't appear to be. They're at pains to say "nothing is installed", and when I created an account, it loaded "openpgp.min.js" from the server.
Can I view the source of the actual program? If not, it doesn't serve much purpose to say that all the cryptographic libraries you use are open-source. Let me see the source and then I'll see about trying your product.
As an aside, I see other people on this thread talking about the well-documented problems of in-browser encryption/decryption. Could someone point me to a list?
With respect to their servers' location in Switzerland, if you don't live in Europe, that will not benefit you. Even the best of laws require you to actively defend yourself. I for one cannot travel to Switzerland and represent myself in a Swiss court, at least not at a tolerable cost.
Damn. I got excited for a second that someone had put together a decent mail client that supports PGP and a hosted email service to rival GMail where the unencrypted email they store would have some semblance of protection from the NSA. Too bad this is the same old crypto in JS stuff.
From the page source:
"We only use GA on our Home and Invite pages to view where traffic is coming from as we prepare for beta. We will be removing GA and all third party sourced scripts from the site afterwards. - Jason"
Interesting that they did not choose to support TLS 1.2 for SSL encryption, and that they added RC4-MD5 as one of their (few) supported ciphers. Certainly doesn't make me feel any warmer.
Is "Based in Switzerland" relevant in this case? I know their government is historically neutral in major wars. Are they also a good place to base security-minded companies?
And whose banks are currently releasing the names of tax evaders to every country that wants to know... Not saying that's in any way unjust but it does hurt Switzerland's reputation for being that anonymous safe haven.
Switzerland is currently in a state of flux. They are adopting to "international" laws at astonishing speeds. A safe heaven for data privacy? Think twice:
You can send encrypted emails to non-protonmail users, but they have to click a link and enter passphrases, and not to mention that the emails will expires?
Also: the RSA Security logo isn't the logo of the RSA algorithm; it's the logo of the company that sells RSA tokens.