10 ms·

> 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

> 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/ https://www.wired.com/2007/11/encrypted-e-mai/

Sir_Cmpwn 8y ago
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).
- deftnerd 8y ago
  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 8y ago
    >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 8y ago
    Headers are not encrypted in OpenPGP and not in ProtonMail. Message and attachment content is.
- subway 8y ago
  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 8y ago
    > 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).
- bartbutler 8y ago
  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.
  - Sir_Cmpwn 8y ago
    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 8y ago
      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 8y ago
        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 8y ago
        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.
jolmg 8y ago
> 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 8y ago
  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 8y ago
    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 8y ago
      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.
      - bartbutler 8y ago
        This.
      - jolmg 8y ago
u801e 8y ago
> 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.
- yjftsjthsd-h 8y ago
  That's basically just what GPG mail is, right?
- gasull 8y ago
  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.

Sir_Cmpwn 8y ago

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).

deftnerd 8y ago
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 8y ago
  >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 8y ago
  Headers are not encrypted in OpenPGP and not in ProtonMail. Message and attachment content is.
subway 8y ago
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 8y ago
  > 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).
bartbutler 8y ago
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.
- Sir_Cmpwn 8y ago
  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 8y ago
    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 8y ago
      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 8y ago
        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.

jolmg 8y ago

> 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 8y ago
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 8y ago
  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 8y ago
    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.
    - bartbutler 8y ago
      This.
    - jolmg 8y ago

u801e 8y ago

> 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.

yjftsjthsd-h 8y ago
That's basically just what GPG mail is, right?
gasull 8y ago
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.