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
Receiving plaintext PGP message to key other than ProtonMail mailbox key causes message to be modified (and undecryptable) #128
Comments
@jameshoulahan This is a bug, not an enhancement. ProtonMail is mangling my inbound messages when it should not. |
I ran into another issue with the Bridge today: I am copying 75000 messages from one IMAP provider to ProtonMail (via the Bridge) and it fails to encrypt and upload messages that have PGP encrypted messages in their bodies: proton-bridge/pkg/pmapi/messages.go Line 364 in 2d8a676
This is the flipside of this coin: Bridge won't encrypt messages to the mailbox that should be (because they're already encrypted with some other key, which it should ignore and encrypt them like anything else). |
I do not think it should double encrypt them. But it should not wrap them in HTML when it can't decrypt them. |
Agreed, it should just pass them through unchanged. |
The key to which they are already encrypted might be published/compromised, or there may be unencrypted message data after the PGP message part, or it could be symmetrically encrypted to a weak passphrase. This means ProtonMail is then more liable to be compelled to release message data via legal process. Imagine a case where someone sends you an PGP encrypted message with their email signature on the bottom with a phone number or street address in it. I imagine PM doesn’t want to store PII unencrypted. All inbound messages (whether uploaded via bridge/imap or inbound via smtp) should be encrypted to the mailbox key in exactly the same way, regardless of content. They should all be decrypted exactly the same way on the way out, regardless of content. Whether that content is already PGP encrypted or not (or contains any other strings or data) should not cause Bridge or the smtpd to branch in any way. This fixes the bug, as well as ensures ProtonMail doesn’t have any plaintext or weakly encrypted/obfuscated data sitting on disk. |
So for mixed content I agree, we just encrypt the whole thing again. However, if the message is already encrypted and is a single PGP message (modulo whitespace), we should pass it through so as to enable people adding their keys later and not break third-party decryption unnecessarily. This is exactly the rule we use for incoming mail server-side. |
Small correction -- if the message begins with a valid PGP message modulo whitespace we take the message and we drop everything after it, as this case is overwhelmingly signed or encrypted replies to mailing lists with a footer added by the list. |
I really think that the mail receipt process shouldn't be dropping anything. Editing incoming mail is a bright line that should not be crossed. Not re-encrypting messages that contain only PGP pre-encrypted content makes sense for the later-key-import use case. |
I just thought of a security consideration: an attacker could embed confusing/phishing HTML inside of a Bridge probably needs to do some sort of parsing on the ascii-armored PGP to ensure that not escaping it is safe, e.g. verifying that it's just the ascii armor character set and not |
Could the Bridge be extended with an "Advanced PGP mode (for experts)" mode, where the bridge itself does not touch the PGP block at al, it just passes it directly to the IMAP client as-is. Then the IMAP client needs to be properly configured with PGP and the private PGP keys used by ProtonMail. The bridge could probably also have a "export private key" feature for various identities and import them directly into a local gnupg instance, so you don't need to log into the webUI to retrieve them and manually import them into gnupg. This would give the best flexibility without extending the complexity of the bridge itself as much. |
this is done in 1.8.x (bodies). outstanding issue is about properly receiving signatures, which is tracked in #26. As for the 'advanced PGP mode' - as nifty as it sounds, it would required too many significant changes to Bridge itself to be feasible so it's a no-go for now. |
When I receive a PGP encrypted message to a key not known to ProtonMail, the Bridge application erroneously converts this message to HTML, which HTML-escapes the ascii-armored PGP encrypted message.
It also shows an error of
openpgp: incorrect key
, which is false - it's not an incorrect key, it's just not encrypted to a key ProtonMail has ever had access to secrets for. There is significant trust involved in the js/html key generation application (I cannot easily inspect it at generation time, for one) and I prefer to use other PGP keys not known to ProtonMail to receive some mail.The offending code is:
proton-bridge/pkg/message/utils.go
Line 51 in bfdfc81
proton-bridge/pkg/message/utils.go
Lines 69 to 73 in bfdfc81
Using Go's
html/template
performs this escaping, and themessage.CustomMessage
function wraps it in HTML styling.proton-bridge/pkg/message/utils.go
Line 64 in bfdfc81
proton-bridge/pkg/message/utils.go
Line 77 in bfdfc81
Expected Behavior
If a plain text PGP encrypted email is sent to my mailbox, I expect to be able to receive that same plain text PGP encrypted email, even if the Bridge is unable to decrypt it.
I imagine that it should be encrypted to my mailbox key at SMTP receive time, and decrypted by Bridge (using the mailbox key) to reveal the existing PGP-encrypted message inside of it, unmodified, like any other inbound message (PGP or not).
This bug may be able to be resolved by modifying the ProtonMail
smtpd
to always encrypt to the mailbox key, even if the inbound message is determined to be a PGP email. It would appear it's not encrypting to the mailbox key if the message is determined to already be PGP encrypted, which causes Bridge to be unable to decrypt it and thus convert it to HTML and escape it, which is incorrect behavior.Current Behavior
The Bridge wraps it in HTML, encodes the entities, changes the mime type, and mangles the message, rendering it un-decodable in my client, as the PGP ascii armoring standard does not decode HTML entities in a mail message first.
Possible Solution
Please don't modify my inbound mail if you can't decrypt it. Just provide the unmodified message.
Steps to Reproduce
Context (Environment)
This is preventing me from switching all of my email accounts to ProtonMail; I'm specifically moving because my previous provider was mangling my messages without consent. If you don't fix this, I will have to maintain a separate patch/fork of the Bridge to fix it myself, and that's a mess.
Possible Implementation
I really think that if the ascii armored PGP message comes in as plain text, the "unable to decrypt" imap message it delivers to the IMAP client should also be plain text. It's not reasonable to change the format of the email, even if you wish to prefix the PGP message with some explanation or error (in plain text).
Now that I've thought about it a bit more, though, I think that perhaps modifying the ProtonMail
smtpd
to encrypt already-PGP-encrypted messages to the mailbox key (like any other plain text message) at message receipt time would be the correct move. Bridge can then just decrypt it like any other message encrypted to the mailbox key, and present the inner PGP message, unmodified, to my IMAP client.The text was updated successfully, but these errors were encountered: