They can’t do traditional IMAP/SMTP simply because they always do client-side auth rather than tradition server-side auth, which inherently makes them more trustworthy than every other provider that does offer IMAP/SMTP-based provider to whom you always send your passwords in plaintext. This has the added benefit of having at least your own mailbox always be zero access encrypted.
they always do client-side auth rather than tradition server-side auth
They must have some server-side auth as well, otherwise I could just emulate requests from the bridge an pull all your PGP encrypted email from their servers. Even though it would be mostly useless it would still be a big vulnerability issue.
IMAP/SMTP-based provider to whom you always send your passwords in plaintext
Why do you say that? What led you to believe it?
Most providers are running IMAPS (IMAP over SSL) or IMAP with StartTLS (upgrade to TLS) and the same for submission to make sure there are no passwords in plain-text. Furthermore mail clients and servers also support password hashing and some, like Google, even go further and push people into IMAP/SMTP authentication with XOAUTH2 (OAuth token unique for each e-mail client).
Non-plaintext mechanisms have been designed to be safe to use even without SSL encryption. Because of how they have been designed, they require access to (…) their own special hashed version of it. https://doc.dovecot.org/configuration_manual/authentication/authentication_mechanisms/#non-plaintext-authentication
Going back to Proton, if they do use PGP in a generic way it means all your e-mail are encrypted and whenever you want to open the website or use the bridge they’ve to decrypt them. As you described before, they do this client side and that’s okay.
Now the next question is: how do they decrypt your mailbox? Their servers hold your private PGP key encrypted with your login password, once a client wants to decrypt your mailbox it has to pull that private key from the server and then use your password to locally decrypt it. Said now plain text key can then be used to decrypt the e-mails. This is a common security practice to make PGP and other asymmetric encryption schemes work securely without forcing the user to store and mange its own private key - that’s okay as well.
For e-mail coming from external providers (and people who don’t use PGP) Proton receives the unencrypted message (over TLS) and then encrypts it with your public PGP key. After this point you are the only person who can decrypt the message because while they also hold your private key it is encrypted thus they can’t use it to decrypt the message. This is reasonable and okay.
Now the thing is, all this can be accomplished via IMAP/SMTP, with the same level of security, if you employ a few rules:
- Tell customers who want to use IMAP/SMTP that they’re required to configure PGP manually on their clients otherwise their mailbox will be encrypted / useless and they won’t be able to send e-mail;
- Submission (sending e-mail via SMPT) servers configured to refuse any e-mail that isn’t PGP encrypted;
- Only provide IMAP/SMTP authentication with SSL/TLS;
- Restrict the IMAP/SMTP authentication to a non-plaintext mechanism;
- If they don’t go for XOAUTH2, then force people into creating a specific app password for each e-mail client - like Google also allows for legacy stuff that doesn’t support XOAUTH2.
Note that their current apps/bridge also needs to authenticate itself with some hashed version of your password, otherwise I could just emulate requests from the bridge an pull all your PGP encrypted messages from their servers. Actually using XOAUTH2 tokens or unique app passwords would be even be safer than what they’re doing.
Considering their PGP implementation is standard then doing those tweaks isn’t impossible and they would provide the same level of security their apps provide but also be flexible enough for more advanced users.
The bridge does the decryption using credentials you give it locally. Sorry for mentioning “auth”. I should have mentioned encryption instead.
Regarding the rest, it comes down to the zero access mailbox encryption’s implementation details. In all described scenarios, you’re not really using your master password as the “key” for your mailbox. But in proton’s and similar services’ case like Tuta, this is true. Any “zero access” service provider offering IMAP access without a bridge is simply lying to you as IMAP (the protocol itself) requires server-side decryption of the content, even if SMTP doesn’t. (Btw, SMTP is really an artificial limitation. Just not IMAP. If they give you smtp access, it wouldn’t send encrypted mails unless specifically configured to do so but would otherwise be the same.)
What you described is encryption at rest, but not zero access encryption (which is what Purelymail does btw).
Whether all this is needed and all depends on your threat model. I think most tech-savvy folks would be happy with something like Purelymail or Migadu tbh…
The bridge does the decryption using credentials you give it locally.
Are you reading what I’m typing? I just described the full process they do on their apps and what can be done over IMAP to give you the same level of protection that Proton offers.
Besides, Proton doesn’t even provide zero access. In Proton there’s a bunch of data like e-mail headers that is NOT encrypted at all and they say it:
subject lines in Proton Mail are not end-to-end encrypted, which means if served with a valid Swiss court order, we do have the ability to turn over the subjects of your messages. Your message content and attachments are end-to-end encrypted. Source https://proton.me/support/does-protonmail-encrypt-email-subjects and https://proton.me/support/proton-mail-encryption-explained
Any generic IMAP/SMPT provider + Thunderbird with PGP provides the same level of security that Proton provides, assuming they didn’t mess their client-side encryption/decryption/key storage in some way. PGP is making sure all your e-mail content is encrypted and that’s it, doesn’t matter if it’s done by Thunderbird and the e-mails are stored in Gmail OR if it’s done by the Proton bridge and the e-mails are on their servers, the same PGP tech the only difference is the clients.