Technology
This is the official technology community of Lemmy.ml for all news related to creation and use of technology, and to facilitate civil, meaningful discussion around it.
Ask in DM before posting product reviews or ads. All such posts otherwise are subject to removal.
Rules:
1: All Lemmy rules apply
2: Do not post low effort posts
3: NEVER post naziped*gore stuff
4: Always post article URLs or their archived version URLs as sources, NOT screenshots. Help the blind users.
5: personal rants of Big Tech CEOs like Elon Musk are unwelcome (does not include posts about their companies affecting wide range of people)
6: no advertisement posts unless verified as legitimate and non-exploitative/non-consumerist
7: crypto related posts, unless essential, are disallowed
view the rest of the comments
I never said PGP was closed, what I was saying is that their implementation of the access to their service is closed (not using standard IMAP/SMTP) and subsequently "their" PGP might be questionable / opaque.
If they actually do everything with open standards and PGP by the book as they say, why can’t they provide IMAP/SMTP access to everyone who wants it BUT add the disclaimer that you’ve to use a PGP compatible e-mail client and configure it to deal with the encryption… they could even configure their submission to refuse any email that isn’t PGP encrypted to improve things further. The fact that they don’t do this leads me to believe that they either a) aren’t actually doing everything as “by the book PGP” and there might be security issues or b) they’re “privacy” as a catch all excuse in order to push a bit of vendor lock-in.
Their market niche is privacy conscientious people and those same people tend be to computer savvy and I bet half of them would mind setting up PGP on Thunderbird and use Proton without a bridge. Everyone else could still use their apps, web or the bridge.
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 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.
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).
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:
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...
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:
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.
One key aspect that you seem to be missing is that Proton encrypts every mail, including those sent by or sent to unencrypted providers using your pgp key before storing them on the server. This isn't a case scenario that can be handled without using a bridge. Thunderbird or any other mail client won't know how to handle that.
What you described only solves the end-to-end encryption portion of the problem Proton is trying to solve. Not zero access.
Yes, mail headers are unencrypted. They never claim otherwise and neither did I. If it were encrypted, it wouldn't be interoperable, which is something you want it to be as well right? I've always been talking about the mail content itself. Unencrypted mail headers don't make it "not zero access".
I feel like you're just not the target audience for Proton. I just use Proton because I'm fine with the web UI and Proton Unlimited is mostly good value for me. I do also pay for Purelymail as i have a few domains and they've been wonderful too.
Yes it can, and I explained how. Maybe you're the one not understanding how Proton actually encrypts emails sent by unencrypted providers/people...
In asymmetric cryptography the public key is used for encryption, then the related private key is used for decryption. This means the server just has to know your public key to be able to safely store incoming email from unencrypted providers. The Thunderbird that has your private key can decrypt the e-mails later on. This is exactly what Proton does but the decryption part is handled by the bridge.
There's guide here explaining this in detail and providing an implementation example with Dovecot. This can be also done when a message is received by the MTA (before it is filed / stored by Dovecot) like discribed in this guide for Exim here. The process should be the same for Postfix.