Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ProtonMail's encrypted email is now available to all

engadget.com

Post reply on HN
Print view View original

81–90 of 111 posts

Re: ProtonMail's encrypted email is now available to all

#81

Post by Scea91 »

vabmit wrote: post #61
moxie wrote: post #24

Some bad signs: 1. Hosted in Switzerland is advertised as a security feature. The point of e2e is that the servers are untrusted. If you need a "good jurisdiction" for your servers, it means they must be trusted. That's a problem, because sadly there are no good jurisdictions in today's world, and your jurisdiction doesn't help you if your servers are hacked. 2. It's webmail. That means the security of whatever e2e t…

Disclosure Note: I'm with ProtonMail. Please note that I don't officially speak for the company. But, I'm a crypto guy and this is Hackernews so... 1. While historically advertising a hosting location was a bit of a red flag for snake oil, the Snowden disclosures changed things for SaaS providers. Jurisdictional arbitrage is indeed a security feature of the service. I think you're missing the point a bit in that it g…

I have a simple maybe stupid question. Why is is necessary to have 2 passcodes for ProtonMail? Wouldn't it theoretically provide the same level of security if the password used to access the email would be also used for encrypting the messages?

Re: ProtonMail's encrypted email is now available to all

#82

Post by e12e »

buu700 wrote: post #59
tptacek wrote: post #57

Earlier quoted context omitted.

Look, it's clever. I mean it. I'm not saying the people that came up with that insane scheme were dumb to do that. It would be a good research project! But I can't imagine relying on that janky set of side effects for my own personal safety, and I can't recommend that anyone else do that either. If you want to use continuity (aka 'TOFU') for security and you insist on getting your crypto in the form of a browser Java…

Fair enough! I'm comfortable with it in terms of security given that HPKP is at least a security feature that makes certain guarantees, but I fully acknowledge that: 1. A future update to browser implementations and/or Web standards could hypothetically break this in terms of availability, DoSing/bricking Cyph for all of our users; and 2. If the server were to violate users' trust by not actually deleting the old TLS…

> 1. A future update to browser implementations and/or Web standards

For some reason I hadn't really considered that all modern browsers are self-updating, so in a standard setup, all web apps are fundamentally insecure. All it takes is for an agency to steal a code-signing certificate (or get one somehow) - and all efforts are defeated.

While bootstrapping based off of gpg-signatures has its own problems (how do you verify the install iso, if you can't know that you have a correct version of gpg/pgp on hand, if you can't (and should not) trust the CA system (SSL/TLS is out)) -- at least you can narrow things down a lot. All of the same issues and more apply to all other software. Mozilla can backdoor your Firefox, Google can backdoor your chrome, Microsoft/Apple can backdoor your IE/Safari and your kernel ... now of course Debian can backdoor your kernel too - but with an open system, it's much easier to control updates -- even if it might be beyond most people to actually verify each and every update themselves. (And to be fair, someone could steal Debian's signing keys at least as easily as they could steal Microsoft's -- and in case of a targeted attack, I find it unlikely that a kernel backdoor in a signed Debian/RedHat/etc update sent to only a handful of machines would be discovered).

[ed: I guess the reason to put less trust in browsers than other OS updates, might be a) it adds a second set of things to worry about (the browser runtime etc) beyond the kernel and other userspace, and b) Browsers are very frequently updated, so the opportunity to install a backdoor is quite frequent (assuming one wants to install it subversively, sending a custom update to a handful of clients at the same time as a general update is out) ]

Re: ProtonMail's encrypted email is now available to all

#83

Post by e12e »

ohthehugemanate wrote: post #66
x1798DE wrote: post #65

Earlier quoted context omitted.

There are secure channels for delivering installable client software that allows protection of content even without transport layer security, and you only need to do it correctly during installation and intermittent updates, not at every access.

what are the secure channels that don't require an uncompromised server and uncompromised client? I can't think of any. It's a good point that you only have to trust both environments at install and update... but you can do the same thing for javascript in a browser: set a long cache time, and browsers will use their local copy until the remote is updated. Use a module loader pattern, and you can compare md5 hashes o…

> what are the secure channels that don't require an uncompromised server and uncompromised client? I can't think of any.

Assuming you trust your hardware: I could hand you a bootable CD.

In practice, there's a bootstrap problem: the general way is to trade the insecure CA system (will always be insecure, there are too many trusted parties, all the CAs) with a web of trust and/or widely distributed hash'es of ISO images/install files.

While surely your cd writer software theoretically could be backdoored so that it will compromise all bootable iso's (all bootloaders?) that contain a gpg executable - that is something quite different from having a rouge CA sign a cert, allowing the individual replacement of js code on a single connection.

Ultimately, one can only trust people, web-of-trust is an attempt at widening that network geographically with the help of technology. It's not perfect, but I think it's hard to argue that it's not better and more flexible than the CA system.

[ed: Note that getting an iso file over an insecure channel; bittorrent, ftp, http -- isn't a problem if you can verify a signature. Now, you still need to have a way to trust the signature (by way of well-known, trusted, cross-signed keys). But compromising the server and the transport now becomes a denial of service, not a compromise of the client. And again, yes there are some bootstrap issues here too.]

Re: ProtonMail's encrypted email is now available to all

#84

Post by Flimm »

ohthehugemanate wrote: post #42
chatmasta wrote: post #41

The fundamental problem with e2e encrypted email, outside of the many technical limitations, is that the encryption is only as strong as the weakest link. Every member of an email chain must support the e2e encryption in order for it to work. One unencrypted sender/receiver is sufficient to break the whole model. So if you want encrypted email, you can only communicate with other people using the same encrypted email…

The way Protonmail and co try to solve this problem is by sending the non-protonmail recipient a notification email, with "click here to read". From https://protonmail.com/security-details : "We support sending encrypted communication to non-ProtonMail users via symmetric encryption. When you send an encrypted message to a non-ProtonMail user, they receive a link which loads the encrypted message onto their browser,…

At that point, you might as well send people invites over email to switch to using a completely different messaging system that is more secure.

Re: ProtonMail's encrypted email is now available to all

#85

Post by Flimm »

LeoPanthera wrote: post #64
runn1ng wrote: post #46

Earlier quoted context omitted.

"Even we cannot read your e-mails!" Exactly what those guys said 10 years ago, and exactly what Proton is saying now. What is different?

The difference is that they are lying. Hushmail encryption is not end-to-end. https://en.wikipedia.org/wiki/Hushmail

You're correct. It can't possibly be end-to-end, since they have the keys, and they can provide webmail. They use OpenPGP but they give themselves the private key! This is dishonest, in my view.

Re: ProtonMail's encrypted email is now available to all

#86

Post by Freak_NL »

ohthehugemanate wrote: post #66
x1798DE wrote: post #65

Earlier quoted context omitted.

There are secure channels for delivering installable client software that allows protection of content even without transport layer security, and you only need to do it correctly during installation and intermittent updates, not at every access.

what are the secure channels that don't require an uncompromised server and uncompromised client? I can't think of any. It's a good point that you only have to trust both environments at install and update... but you can do the same thing for javascript in a browser: set a long cache time, and browsers will use their local copy until the remote is updated. Use a module loader pattern, and you can compare md5 hashes o…

The benefit of installable client software is that the encryption software and the relaying party (your e-mail provider) are completely unrelated and separate. So if I use GMail and encrypt my messages to Bob with GnuPG, than no matter what GMail does with the encrypted message, it either gets delivered securely (and is verifiable by Bob as having been written by me) or not. Any adversary would have to compromise the source of my operating system's GnuPG version (or Bob's), and have access to the messages themselves.

The browser model explicitly trusts the remote server to provide whatever JavaScript code it sees fit, so if your e2e webmail provider is compromised, you get a backdoored crypto library that works as far as your browser and you can tell.

It all comes down to trust of course, but the separation of concerns adds a very real layer of security, and I trust Debian and its maintainers (and the experts who scrutinize these things) more than a single commercial e-mail provider.

Re: ProtonMail's encrypted email is now available to all

#87

Post by buu700 »

e12e wrote: post #82
buu700 wrote: post #59

Earlier quoted context omitted.

Fair enough! I'm comfortable with it in terms of security given that HPKP is at least a security feature that makes certain guarantees, but I fully acknowledge that: 1. A future update to browser implementations and/or Web standards could hypothetically break this in terms of availability, DoSing/bricking Cyph for all of our users; and 2. If the server were to violate users' trust by not actually deleting the old TLS…

> 1. A future update to browser implementations and/or Web standards For some reason I hadn't really considered that all modern browsers are self-updating, so in a standard setup, all web apps are fundamentally insecure. All it takes is for an agency to steal a code-signing certificate (or get one somehow) - and all efforts are defeated. While bootstrapping based off of gpg-signatures has its own problems (how do you…

That isn't exactly a Web-app-specific problem. If you have native software running malicious code with user-level access (whether it's in your browser or any other random update from your package manager), you should consider the whole machine compromised.

Re: ProtonMail's encrypted email is now available to all

#88

Post by e12e »

forgotpwtomain wrote: post #78
zimbatm wrote: post #76

Earlier quoted context omitted.

> 2. This is true. However, it's true about every web service. It is also true about any software that is either distributed over the web/TLS or has security updates distributed over the web/TLS. While some may say that non-web apps have code signing or application signing keys, the fact is that most of either the signing or verification keys for those application code signature schemes are distributed over TLS. If y…

> If you install Debian you have to make sure that the ISO was not compromised. You can do that by calling a third-party and compare the published checksums or any out-of-band solution. Once this base of trust is established you are good to go. In fact updates are fetched over plain HTTP because all the updates are signed using GPG. It's hard to take this seriously - do you really call a third-party every-time you re…

> It's hard to take this seriously - do you really call a third-party every-time you rebuild a Dockerfile and run update with your package manager?

It's best practice for all these kinds of develop/deploy processes to (automatically) verify gpg signatures. If you verified your initial iso, then you know (to a certain extent) that you have a known-good gpg binary. There are ways to attack web-of-trust, and each time you add/update a trusted key there are issues -- but compare this to the number of shifty CAs all browsers trust out-of-the box. Any single one of them is enough to trick the client.

Attack scenario: disrupt client access to the Internet. Send what looks like the webmail page. On user entering the passphrase, log it, replay login details to actual webmail service (get the private key). If you're a normal attacker: download email, decrypt it. If you're a state agent, get encrypted email from intercept logs (this is assuming TLS is broken - lets hope it isn't. Or assuming that there is some way to intercept the non-tls traffic (eg: between loadbalancer and disk storage).

How would this compare to the air-gapped laptop used for traditional email? You would need to physically attack the laptop - not just have access to the ISP. That's the difference between economical (targeted or not) mass surveillance and "boots on the ground".

How does this compare to traditional non-airgapped gpg encrypted mail: in order to compromise a client that is updated via gpg-signed updates, you'd have to get a signing key, or implant one. Not simply bully any old CA out of hundreds to give you one. Then you'd have to trigger an updated somehow, or intercept one. Given the above, if you can own the clients net access this shouldn't be too hard. But the client needs to install those updates. With a web service, the client just needs to access the app.

Re: ProtonMail's encrypted email is now available to all

#89

Post by Freak_NL »

duaneb wrote: post #75
tptacek wrote: post #56

Earlier quoted context omitted.

"PGP is hard to use" is more memetic than accurate. What makes PGP hard is that it has a million options, and its vocal users (and detractors) seem insistent on availing themselves of as many of them as possible. In reality, 80% of PGP's value (which is more value than you'll get out of any webmail system), you can get with three command lines: gpg -sear recipient@addr document.txt Encrypt and sign a document, ASCII…

If those commands are so simple, why are they not built into chrome? Honest question. It's where I actually write my emails.

If a browser provides an OpenPGP API, than how would I know whether or not a website uses it properly? What is to stop a compromised webmail provider from serving me a web page that claims to use this API to encrypt my message before sending it, but also simply sends the plain text message captured from the mail composition page along?

You are typing your sensitive message right there in the browser, in the web page provided by them, with JavaScript provided by them, which can simply send whatever you type directly to their (compromised) server.

This means OpenPGP in the browser is technically feasible, but very insecure because a third party can access the data before it is encrypted. To make a browser provided OpenPGP API work, it would have to provide the input area where you type your confidential message in a way that makes it clear it is the browser that provides it, and the web page JavaScript cannot access it before encryption. This is of course exactly what stand-alone e-mail clients do, so why implement it in the browser?

Re: ProtonMail's encrypted email is now available to all

#90

Post by e12e »

waffl wrote: post #79

Apart from the discussion surrounding the crypto side of all this, one thing that ProtonMail has really succeeded in doing is making encrypted mail finally an accessible thing to a non-technically inclined user. I've spent well over a year trying to get my team to properly gpg encrypt sensitive files only to constantly find them sending plain unencrypted files over slack, dropbox and even simply gmail. At least now,…

I'll say this, a service like this is great from the network effect alone. While I might not think it's secure, it'll allow me to set up a traditional email-client+gpg and send encrypted email to people. And it'll provide a way for people to migrate to secure email, at a later point.

Much like I could for a brief moment actually talk to people over XMPP until Facebook and Google cut off the limited support they had for it. Most of those I talked to used the horrible web interface of Facebook/Google talk -- but I could use something that made sense. And I could even talk securely to some people on Facebook, as OTR worked fine over Facebook XMPP chat (while obviously breaking the web interface).

Post reply on HN