[MrBingley]

> They excuse this nonsense by saying that it's necessary for encryption, which is blatantly false.

I don't see how this is false. Protonmail encrypts all user emails on the server, which can only be unlocked by the user's password. SMTP and IMAP would require transmitting the password to the server for decryption, which makes it prey to interception a la HushMail [0]. This is why they have the bridge, which runs its own IMAP server on the client and performs all authentication and decryption locally. Of course, the bridge isn't open source yet, so we can't be sure it isn't sniffing your password anyway, but that is orthogonal to the issue of supporting SMTP.

[0] https://www.wired.com/2007/11/encrypted-e-mai/

[jolmg]

> Protonmail encrypts all user emails on the server

You can't verify that. As a rule of thumb, I think no one should trust a service provider to prevent themselves from doing something that benefits them and that their clients have no way of verifying that they're not doing.

If you want a server to only hold a file encrypted, don't provide it unencrypted and trust them to encrypt it. Encrypt it before giving it to them.

[bartbutler]

I agree that providing it encrypted is better, which is what all of our APIs require. That said, you are mistaken that saving the cleartext for unencrypted mail benefits us at all. It most certainly doesn't--the incentives between the provider and users are well-aligned here.

[jolmg]

You must certainly know that emails provide a lot of valuable data (in aggregate) that can be sold for purposes such as advertising. Also, it's entirely possible for governments to require keeping plain texts for their own use (like law enforcement investigations) and force providers to keep hush about it like the United States does. Not that I know if Switzerland does something like that, in the case of Protonmail.

I must say, it's surprising to see a comment like yours here on HN. Where've you been?

[cube2222]

This would be blatantly illegal (especially with GDPR) and if exposed, would be the end of their company. (As security is their main focus)

I'm not using protonmail myself, but I'm sure they're not playing around with your data.

[jolmg]

Switzerland is not part of the EU, though. Enforcement of GDPR on them depends on how well the EU can force their laws on non-EU nations, something which I hope cannot be done. Who wants to abide by the laws of others in their own home without even the chance to somehow vote or otherwise affect them?

[cube2222]

The US isn't either. GDPR applies to all companies doing business in the EU and handling EU user data.

I'm not saying if it's good or not, but if they wouldn't abide, they'd be blocked from doing business in the EU.

They have a gdpr section on their webpage by the way.

[bartbutler]

This.

[nickpsecurity]

"It most certainly doesn't--the incentives between the provider and users are well-aligned here."

This might be true but we dont know that. Offering fake security or selling people out for money are a recurring theme in markets for "private" services. You're expecting us to believe nobody on your team would take a payout from or be coerced by US LEO's or spooks. That's crazy. It's better to not put you in that position of us having to trust you like that.

To drive it home, Crypto AG in Switzerland backdoored stuff in the past, RSA was paid $30 million IIRC, and US ISP's got in $100 million range. The NSA was spending several hundred million a year with FBI helping on domestic coercion and CIA using tradecraft against foreign targets. Even Swiss have Onyx system now. There's a real, even if slim,chance people in the company get paid off, legally coerced, or hacked at some point in future. So, it's better if those of us that might be affected push for as little 3rd-party access to secrets and closed implementations as possible plus maximum rigour and review in design/implementation.

[bartbutler]

> You're expecting us to believe nobody on your team would take a payout from or be coerced by US LEO's or spooks. That's crazy.

No, we're saying that we don't store the data partly so that such a scenario isn't available because historical data simply doesn't exist.

> It's better to not put you in that position of us having to trust you like that.

Look, we freely admit that you can't verify that we do this. If we are part of your threat model, you probably shouldn't rely on us doing it. If we aren't, then it's an additional layer of security relative to other providers who explicitly don't. If you receive unencrypted email, which is virtually everyone, those are your two options. Regardless of whether you believe us, we're still going to do it, because it's better for us and its better for users. There is no 'third way' that allows us or anyone else to receive unencrypted mail on your behalf and verifiably not save a copy. The only solution is to not have unencrypted mail, which is part of the reason we spent a year developing easy-to-use PGP interoperability.

[nabla9]

Protonmail takes a big financial and legal risk if it's not encrypting the email immediately when it comes in.

They get steady stream of law enforcement inquiries. The best way for them to operate is to do just what they say. Encrypt incoming encrypted mail with users's public key and throw unencrypted mail away.

[u801e]

> SMTP and IMAP would require transmitting the password to the server for decryption

Why? There's nothing in the SMTP or IMAP specification that I'm aware of that requires that the email be in a decrypted form when stored in a mailbox. When a client fetches the email via IMAP, it can then be decrypted on the client side.

On the SMTP side, I could do the following over telnet

    EHLO test
    AUTH PLAIN XXXX
    EHLO test
    MAIL FROM: <my@address>
    RCPT TO: <your@address>
    DATA
    <encrypted ascii armor text>
    CRLF.CRLF

On the IMAP side I can log in and run

    . SELECT Inbox
    . FETCH 1 (BODY[])

which should retrieve that ascii armor text. Then I can decrypt it locally.

[gasull]

As I understand it, you can already use ProtonMail this way with their IMAP bridge. I think their concern is UX, since many people don't know how to set up PGP locally, while opening a ProtonMail account and using the web interface is easy.

[yjftsjthsd-h]

That's basically just what GPG mail is, right?

[Sir_Cmpwn]

No, they could just transmit PGP encrypted emails down IMAP and the user could decrypt them with any number of popular PGP implementations. Your IMAP/SMTP password doesn't necessarily have to be the same as your PGP key password, nor should you even need to give Protonmail your PGP private key (password protected or not), nor does IMAP/SMTP even have to be authenticated with a password (GMail notably pioneered an OAuth-based extension to both).

[bartbutler]

This is completely ignoring key management as a barrier to using encryption, not to mention manually syncing local keystore with the server, not being able to provision keys across devices, etc. In other words, why PGP and email encryption in general has largely been a failure over multiple decades. It's too complex and too difficult.

[snorremd]

I think you hit the nail on the head here. Using PGP/GPG has a lot of upfront cost in learning how to create keys, syncing them, getting them signed, storing them securely, etc. To be absolute certain that the private key is not stolen you even need to create them on an air-gapped machine and use a hardware device like a yubikey when using keys on online machines.

I think in the end most computer users will sacrifice a bit of security for convenience. PGP signature and encryption for email will most likely never take off. Encrypted chat services like Signal seems to have done much better, likely because of how convenient they are to use.

[dane-pgp]

You're right about the usability difficulties of syncing local keystores across devices and with the server. Fortunately some good work has been done in this area recently:

https://autocrypt.org/

This stores the private key as a password-encrypted file in a specified location on the IMAP server. It already has multiple interoperable implementations, by the looks of things.

[Sir_Cmpwn]

None of these difficulties prevent you from making the access available. It has no bearing on users who already choose not to use IMAP. This is a pretty bad excuse.

[bartbutler]

Only if you completely discount the related costs of building and maintaining such an additional API as well as the customer service impact of basically allowing users to screw up their own key management.

[Sir_Cmpwn]

Even if I concede this to you (and I don't), you've already written an IMAP/SMTP bridge that solves these problems. Open source it and make it available to free users and the problem disappears (well, is reduced. Most non-technical users don't know how to run a daemon after all, and making them put it on their own infrastructure is lame as hell).

[bartbutler]

Because running PGP software and handling key management locally is way easier than double-clicking on an installer? I don't concede that for a second. Remember that the alternative you want is ciphertext directly via IMAP, which is not at all user-friendly, which is exactly why we didn't do it.

As for the bridge, that is exactly what we'd like to do, as I've said before.

And customer support time and developer time devoted to this would cost money and represents an opportunity cost as well and that's a fact, not a point to be conceded.

[subway]

Is there a way to encrypt message headers while using IMAP?

My understanding of Protonmail's argument (not that I agree with it) is they encrypt the full message, including headers upon accepting it. Based on my understanding of IMAP, you're effectively looking at a new protocol once you do everything needed to decrypt headers on the client-side.

[u801e]

> Is there a way to encrypt message headers while using IMAP?

Other than the Received, Delivered-To and Return-Path headers added by the intermediate MTA servers, every other header in the original message could be encryped, along with the message body when it's delivered to the server (or appended via IMAP).

[deftnerd]

Protonmail's method of encryption allows them to encrypt the entire message, including headers/metadata. It also encrypts the messages received that weren't encrypted when they weren't first sent.

Your suggested method basically is no different from any other provider. You rely on the sender encrypting the message and header information is entirely unencrypted on the disk.

[Sir_Cmpwn]

>Protonmail's method of encryption allows them to encrypt the entire message, including headers/metadata

I would prefer to see them promote standards to extend PGP rather than invest that time in a new, proprietary system with no buy-in from the email-related-software development community. I can follow the logic but I can also see their eyes lighting up when they realize this is a great excuse for having a proprietary, locked-in platform.

>It also encrypts the messages received that weren't encrypted when they weren't first sent

This could be done with PGP

[bartbutler]

Headers are not encrypted in OpenPGP and not in ProtonMail. Message and attachment content is.