Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[v3] Sending PGP encrypted mails with external keys fails #320

Closed
dsommers opened this issue Dec 14, 2022 · 6 comments
Closed

[v3] Sending PGP encrypted mails with external keys fails #320

dsommers opened this issue Dec 14, 2022 · 6 comments

Comments

@dsommers
Copy link

In some cases I need to use external PGP keys, the private key is not intended to be exported and imported into Proton Mail - and it is stored on an OpenPGP hardware token (such as Nitrokey or Yubikey).

Sending PGP encrypted mails with external keys via Proton Mail Bridge (PMB) results in this error:

ERRO[Dec 14 11:24:45.455] 400: MIME body invalid, Attempt 1            

Sending only PGP signed mails via PMB using the same external key works fine. Sending the PGP encrypted e-mail via an external SMTP gateway also works fine, the mail copy stored in "Sent" can also be decrypted in Thunderbird.

Receiving a PGP encrypted e-mail needing the external key also works fine via PMB.

Proton Mail Bridge version: git - v3 branch, commit 9c10e06
Thunderbird version: 102.6.0 (64-bit)
OS: Red Hat Enterprise Linux 8.7

Side note: The received PGP encrypted e-mail from an external sender requiring the external key is can be decrypted using Mailvelope in the webmail. The copy stored in the "Sent" folder cannot be decrypted via Mailvelope, two attachements are seen: "attachment.pgp" and "encrypted.asc". The same happens with the plain PGP signed e-mails. The copy in the "Sent" folder does not process the signature at all; it's seen as an "OpenPGP_signature" attachment.

@bartbutler
Copy link

This is by design. Sending emails encrypted with external keys results in unreadable emails in other clients and is customer service nightmare, so we do not support it.

@dsommers
Copy link
Author

What do you mean with "unreadable emails in other clients"?

If sending a PGP encrypted e-mail to an external user (signed with my external private key) works fine when sending it via a standard SMTP gateway.

And if someone sends an e-mail to me, using my own external key, I can read that just fine in Thunderbird or via Mailvelope in the Proton webmail.

Or are you concerned sending an encrypted mail to a Proton user account with an expired/revoked key confuses the (Proton) recipient, not being able to read it? And that PMB will ensure the right and current PGP public key is always used when sending mails?

@bartbutler
Copy link

Sorry for being unclear, the sent messages will not be readable in other Proton clients, and yes, we also enforce the correct keys for Proton recipients so if there was a mismatch that would also be rejected by our server and that case would have to be handled by the bridge.

It seems like your use case should be able to be handled by sending mail signed by your hardware key and adding your recipient's public key to your Proton contacts so that the bridge will encrypt to it (we'd have to verify that this works). That would leave the encryption to the bridge and the only consequence would be a signature verification failure for the sent message.

@jonathancross
Copy link

@bartbutler
so that the bridge will encrypt to it

Personally, I (and I suspect other hardware key users) would like to encrypt & decrypt messages in the hardware device rather than passing plaintext through PM / bridge.

Related:

PS: I explored using the alternative hydroxide client, but that doesn't work either because email encrypted via external yubikey, etc is blocked by server:

@bartbutler
Copy link

You can decrypt messages on the hardware device however you like, Proton passes through emails encrypted to unknown keys.

Encrypting on the hardware device...why? There's no private key to protect when encrypting. And you should be able to sign on the hardware device and have Bridge encrypt as well (to be checked). Bridge is designed to be the encryption layer.

@dsommers
Copy link
Author

Okay, I get that this is not a wanted feature. To me that is disappointing, but I will then have to send mails encrypted (and signed) with external keys through an external SMTP gateway.

Btw: You are correct, encryption does not require the hardware key. Signing and decryption does.

My use case is basically sending mails already encrypted via the Bridge. The Bridge encryption opportunistic. I had to turn off the "warning" when sending mails unencrypted - a lot of my mails is going unencrypted to many users so that popup each time was just an annoyance. But I have some recipients where the mail must be encrypted, and it must be signed by an external (hardware) key; I can't export the private key and I can't take the risk of an opportunistic behaviour in the Bridge for this case - even if the Bridge could handle encrypting a pre-signed mail. In my use case Thunderbird will stop me from sending an encrypted mail when I am lacking the recipient keys.

Secondly, since there exists no way to manage the PGP keys in Proton via Thunderbird .... it gets even more tedious to ensure new recipients has the proper key setup. There does not even exist any CardDAV interface to work with. Which is why I ends up using EteSync for device synchronisation.

And finally, no, you won't convince me to move away from my Thunderbird setup I've used more than 20 years. I have tried other mail clients (including), but I always end up back because I know it's sharp corners and know how to mostly tame it. I have also not seen a single webmail interface being able to compete with the threaded mail listing Thunderbird (and many others do, including alpine and mutt). When being subscribed and interacting with many mailing list, proper thread view is a must.

I'm closing this now, as I don't expect Proton will change their opinion or see it differently. But feel free to re-open if this use case is being reconsidered.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants