Signed emails has broken signatures after ProtonMail mangles them

[exander77]

S/MIME:

$ openssl smime -verify -in FW_\ anyconnect\ -\ ProtonMail.eml 
Error reading S/MIME message
139644724533056:error:0D0D40CD:asn1 encoding routines:SMIME_read_ASN1:invalid mime type:../crypto/asn1/asn_mime.c:469:type: multipart/mixed

$ openssl smime -verify -in FW_\ anyconnect\ -\ Bridge.eml 
Error reading S/MIME message
139802251859776:error:0D0D40CD:asn1 encoding routines:SMIME_read_ASN1:invalid mime type:../crypto/asn1/asn_mime.c:469:type: multipart/mixed

$ openssl smime -verify -in FW_\ anyconnect\ -\ Gmail.eml
...
Verification successful

[horejsek]

Can you share more details how to reproduce your problem?

[exander77]

Send signed email to ProtonMail. Import signed email to ProtonMail through Bridge. Send signed email from ProtonMail through Bridge.

Verify signatures.

An example email is a signed mail delivered to my ProtonMail account and a Gmail account as well. Gmail email is OK. Mail received on ProtonMail and Gmail email imported through Bridge have both broken signatures.

[kortschak]

This is also reported internally with ticket# 430087. This is deeper than a bridge problem though, all signature information is dropped from incoming and outgoing email. This appears to be related to a behaviour that ProtonMail has of dropping all plaintext email if any mime-encoded parts exist. I discovered the signature-dropping behaviour when investigating the plaintext dropping behaviour since dropping parts would obviously break signatures. Well played, ProtonMail, if you lose both, obviously the signature won't be incorrect.

[bartbutler]

Just to be clear, are you both talking about S/MIME signatures or PGP signatures? S/MIME signatures are explicitly not supported at this time. PGP signatures should work seamlessly in all cases.

[kortschak]

PGP in my case. It is only seamless in the sense that the Emperor's clothes were seamless.

[kortschak]

Here is an example where a signed email was sent by me from another account under my control to my PM account.

You can see in the sending client that it believes there to be a GPG signature.

When it's received by PM the web client does not believe there to be a signature.

The bridge-dependent client agrees that there is no signature.

From this it's pretty clear that the defect is in the PM's handling of the mail prior to the bridge seeing it, so the issue is probably not due to the bridge. It is however a pretty significant problem; a security focused mail service that strips signatures from incoming mail seems a little bit broken.

[bartbutler]

For incoming, do you have the remote contact in your contacts with their PGP public key? If so, if you open the mail on the web application, do you see something like this:

[kortschak]

No I don't. However, PM should not be stripping signatures no matter what. Requiring that argues somewhat against seamlessness.

[bartbutler]

We're not stripping them, we are incorporating them into a valid PGP message when we encrypt mail on ingestion. What are you signing with, and which format (PGP "inline" or PGP/MIME?). I assume PGP/MIME?

[kortschak]

Yes, it's PGP/MIME. I am signing with the mail client (evolution) which in turn shells out to gpg.

Whether you're explicitly stripping or not, the upshot is the same; they are not available when forwarded on to the desktop client via the bridge (and apparently not available to verify in the web client unless the sender's identity is known). This means that the desktop client is unable to confirm the validity (or even presence) of a signature. I'll note that a message sent from the desktop client via the bridge to an external recipient also has no signature present. Again, none of this is reminiscent of seamlessness.

I suspect (tell me if I'm wrong) this has to do with the same issue that results in plain text being lost from mails that are HTML formatted but have a plaintext fallback.

[bartbutler]

It's not the same issue as plaintext being lost from multipart/alternative. The web client not indicating the presence of a signature if you do not have a public key stored for the user is by design, as that information would be confusing to the user if there's not anything that they can do about it.

The bridge, I agree, does not have all the functionality here that we might want. That said, the idea is that bridge itself is supposed to be the encryption/signing interface here, not a pass through for third party signing software. So for signing outgoing emails, the way this should work (and it's quite possible that it doesn't work 100% at the moment), is that if you send a mail to an external Proton contact with a PGP public key attached and have configured signing, that the bridge will sign it with your keys and the recipient will receive a signed MIME email.

On the receiving side, if the public key is in your contact, it should verify the signature and show some indication of that. This I remember was really, really difficult to do in a way compatible with all clients, and it's very possible that it got tabled as a feature while other functionality was focused on, but I agree it needs to be there and we need to figure out how to make it work.

Fundamentally though I think the misunderstanding here is that the Bridge is supposed to work as a pass through for signing schemes with external keys. It is not.

[exander77]

This boils down to a fact, that ProtonMail screws with emails too much. There are several ways for them to get corrupted.

Neither server nor the Bridge should screw with email in any way: https://github.com/ProtonMail/proton-bridge/issues/18

Fundamentally though I think the misunderstanding here is that the Bridge is supposed to work as a pass-through for signing schemes with external keys. It is not.

The misunderstanding is yours. ProtonMail is marketed as follows:

The ProtonMail Bridge is an application for paid users that runs on your computer in the background and seamlessly encrypts and decrypts your mail as it enters and leaves your computer.

Proton Bridge should not fuck with signatures in any way. There is nothing it should support or did to make it work. Everything should work out of the box. The only way for signatures to stop working is that either the server or the Bridge fucked the emails up.

I would point out that decryption is the inverse of encryption. And if I encrypt and then decrypt the email I should get the original (to a single bit!). Not some mangled version of it.

By the very definition of encryption and decryption. ProtonMail does not do encryption and decryption. After ProtonMail "encrypts" the plaintext email, the plaintext email is not recoverable by any means.

I like the work you are doing. But sometimes I am sincerely horrified by what I read here. I think you have to accept the reality, that it is not acceptable to modify emails in any way. It borders on criminal behavior in my opinion. Do you understand, that you are opening emails and modifying their content including signatures inside them?

[kortschak]

The web client not indicating the presence of a signature if you do not have a public key stored for the user is by design, as that information would be confusing to the user if there's not anything that they can do about it.

I think that this underestimates the capacity of the PM user base. It is trivial to indicate that a signature exists but is from an unknown identity; this is what my mail client says when this happens. This allows me to know that there is the possibility of confirming an identity and if I sign a key locally then that mail has its origin confirmed.

The bridge, I agree, does not have all the functionality here that we might want.

Yes. In the absence of that, it would be nice if it didn't break things.

That said, the idea is that bridge itself is supposed to be the encryption/signing interface here, not a pass through for third party signing software.

This is an unfortunate model. Why replace perfectly functional cryptographic tools with tools that are newer and less reviewed? Friends don't let friends roll their own crypto. I don't want to keep keys with PM, this fundamentally depends on trust, and I am not sure I trust PM enough for that.

So for signing outgoing emails, the way this should work (and it's quite possible that it doesn't work 100% at the moment), is that if you send a mail to an external Proton contact with a PGP public key attached and have configured signing, that the bridge will sign it with your keys and the recipient will receive a signed MIME email.

Again, this is unfortunate, for the same reasons.

On the receiving side, if the public key is in your contact, it should verify the signature and show some indication of that. This I remember was really, really difficult to do in a way compatible with all clients, and it's very possible that it got tabled as a feature while other functionality was focused on, but I agree it needs to be there and we need to figure out how to make it work.

Yeah, I don't want a third party to validate signatures, I want to have access to the bytes so that I can confirm, with trusted tools, the validity of identities.

Fundamentally though I think the misunderstanding here is that the Bridge is supposed to work as a pass through for signing schemes with external keys. It is not.

I would have to agree with @exander77. This is not how it was sold. And, as @exander77 says, I really would like PM to stop touching my mail in ways that make conventional and safe approaches unworkable. (See also failing to pass through the plain text, which is something that IMHO makes mails less safe since I read - or used to - all my emails as plain text).

I really want to like PM, but I'm finding it increasingly difficult to do so.

[bartbutler]

The web client not indicating the presence of a signature if you do not have a public key stored for the user is by design, as that information would be confusing to the user if there's not anything that they can do about it.

I think that this underestimates the capacity of the PM user base. It is trivial to indicate that a signature exists but is from an unknown identity; this is what my mail client says when this happens. This allows me to know that there is the possibility of confirming an identity and if I sign a key locally then that mail has its origin confirmed.

It's something that can be considered as an opt-in feature perhaps, and would be more useful if paired with key lookup.

The bridge, I agree, does not have all the functionality here that we might want.

Yes. In the absence of that, it would be nice if it didn't break things.

We could probably pass through the PGP/MIME structure here. However, we can't do it for sending, so from a product perspective I'm not sure it makes much sense.

That said, the idea is that bridge itself is supposed to be the encryption/signing interface here, not a pass through for third party signing software.

This is an unfortunate model. Why replace perfectly functional cryptographic tools with tools that are newer and less reviewed? Friends don't let friends roll their own crypto. I don't want to keep keys with PM, this fundamentally depends on trust, and I am not sure I trust PM enough for that.

The keys are encrypted, we don't have access to them. When you get right down to it, the central problem from a crypto perspective that we are solving is automatic cross-device key distribution without server trust. And the reason we're building new tools for this is that there are real reasons encrypted email is still a niche userbase on the internet and we'd like to change that. You don't win the race with the same car that's been losing for two decades.

So for signing outgoing emails, the way this should work (and it's quite possible that it doesn't work 100% at the moment), is that if you send a mail to an external Proton contact with a PGP public key attached and have configured signing, that the bridge will sign it with your keys and the recipient will receive a signed MIME email.

Again, this is unfortunate, for the same reasons.

The main reasons we don't want to allow third-party crypto tools to do this is because if the keys aren't in your account, your drafts/sent messages won't be readable by other clients and your mails will be signed by keys that don't match those in our keyserver and thus will generate verification errors for your recipients, and as it's crypto it will be tricky to track down and impossible to fix. There are also a number of draft/sent/sending-related difficulties with how IMAP works vs. how mail sending works on our servers (for good reasons) which become even trickier if you add third party crypto to the mix.

On the receiving side, if the public key is in your contact, it should verify the signature and show some indication of that. This I remember was really, really difficult to do in a way compatible with all clients, and it's very possible that it got tabled as a feature while other functionality was focused on, but I agree it needs to be there and we need to figure out how to make it work.

Yeah, I don't want a third party to validate signatures, I want to have access to the bytes so that I can confirm, with trusted tools, the validity of identities.

It's not a third party - the bridge is doing it locally and is open source. We can consider passing through signature information here as well though.

Fundamentally though I think the misunderstanding here is that the Bridge is supposed to work as a pass through for signing schemes with external keys. It is not.

I would have to agree with @exander77. This is not how it was sold. And, as @exander77 says, I really would like PM to stop touching my mail in ways that make conventional and safe approaches unworkable. (See also failing to pass through the plain text, which is something that IMHO makes mails less safe since I read - or used to - all my emails as plain text).

I really want to like PM, but I'm finding it increasingly difficult to do so.

It was sold as something which takes care of the crypto for you, not something that you layer third-party crypto on top of. I agree that the plaintext thing is a problem and we do have a plan to fix that. In the mean time, if you'd like to preferentially have plaintext (at the expense of HTML) there is a hidden option I can turn on for you to effect that. If you want both to be saved outside of signed messages, that'll have to wait for the fix.

[exander77]

It was sold as something which takes care of the crypto for you, not something that you layer third-party crypto on top of.

Seemless? For this to work, only thing you need to do is "not to fuck the emails up".

[kortschak]

Thank you. This has been helpful. The situation is not ideal, though it looks like PM is heading at least in part towards a reasonable direction for my use. Further, I've got more out of this exchange than in the last several months of trying to get an understanding of how these things will be fixed via the support desk.

It's something that can be considered as an opt-in feature perhaps, and would be more useful if paired with key lookup.

Yes.

We could probably pass through the PGP/MIME structure here. However, we can't do it for sending, so from a product perspective I'm not sure it makes much sense.

It's not entirely clear to me how passing the signature information through will help since the body you send doesn't match the body that the original sender posts. This means it will not be possible to verify the signature. What am I missing?

The main reasons we don't want to allow third-party crypto tools to do this is because if the keys aren't in your account, your drafts/sent messages won't be readable by other clients and your mails will be signed by keys that don't match those in our keyserver and thus will generate verification errors for your recipients, and as it's crypto it will be tricky to track down and impossible to fix. There are also a number of draft/sent/sending-related difficulties with how IMAP works vs. how mail sending works on our servers (for good reasons) which become even trickier if you add third party crypto to the mix.

If a recipient has my public key (from outside PM) then they will be able to verify (notwithstanding the issue above). This is more important to me than PM verification. Alternatively, you can onion wrap the message I send including my external signature and sign that. The same hold true for encryption.

It's not a third party - the bridge is doing it locally and is open source. We can consider passing through signature information here as well though.

The definition of third party is completely context-dependent. Here, in the context that I was using it, it absolutely is third part. Party one is me, party to is my correspondent. You are party three and not though people have been doing excellent work on the golang.org/x/crypto library, Adam Langley is an outstanding cryptographer and there are strong moves to properly audit the Go crypto routines, they haven't been yet; while I have a moderate background in crypto, I would not feel comfortable doing this here.

Passing through signature information would be helpful.

In the mean time, if you'd like to preferentially have plaintext (at the expense of HTML) there is a hidden option I can turn on for you to effect that. If you want both to be saved outside of signed messages, that'll have to wait for the fix.

Thanks. I'll wait because unfortunately while I prefer to read plaintext, some mailers do not include fall-back plaintext.

[kortschak]

As a follow up, can you explain this

That said, the idea is that bridge itself is supposed to be the encryption/signing interface here

Currently, there is no user interface for this. How is it supposed to work? For signing in my use case, I want to have an indication of intention as well, this requires a pin/password access to the key. AFAICS this isn't possible at the moment with the model that PM has using the bridge.

[kortschak]

@bartbutler ping re https://github.com/ProtonMail/proton-bridge/issues/26#issuecomment-664129419 and https://github.com/ProtonMail/proton-bridge/issues/26#issuecomment-664112185 (quoted section below)

It's not entirely clear to me how passing the signature information through will help since the body you send doesn't match the body that the original sender posts. This means it will not be possible to verify the signature. What am I missing?

[bartbutler]

Hi @kortschak , sorry for the wait. The information that is missing is that, in the case of PGP/MIME, we do save the original signed body (which is how the web app can verify the signature if you pin your contact's key). My guess is that bridge is decrypting it and parsing it somehow with the MIME parser, but it should be possible to rebuild a valid signed PGP/MIME message and pass it through in this case--the original body has not been lost.

[kortschak]

Thanks, @bartbutler. That's part 1 of 2. Can you also address https://github.com/ProtonMail/proton-bridge/issues/26#issuecomment-664129419.

[bartbutler]

The idea there is that the bridge would sign mails according to your preferences and contacts settings as it does with all the other clients (you can globally choose sign everything or not, and PGP/MIME vs. Inline, and override this behavior on a per-recipient basis via editing contacts) to give a universal experience across the ProtonMail clients. Then in terms of visualization of signature verification for received mails, we'd figure out how to do this in a client agnostic way. I think the leading idea was to override the Sender header and indicate the signature verification there with an email address comment.

In any case, all of this is WIP/idea stage and got back-burnered while more pressing stability issues were prioritized, but it is important and I'd like to revisit it.

[kortschak]

OK, so the bridge would pop-up a passphrase request for non-keychained keys?

[bartbutler]

I'm not sure I follow. We could, with this scheme, support signing with third party software/keys and pass it through (not encryption, but signing would work). But it would have some nasty consequences, namely that your sent messages would fail signature validation in the other apps (because they are signed by a key other than one in your keychain) and our key server would also not serve the appropriate key for verification of these emails. So I'm not ready to say that this will be supported--it's pretty niche and has consequences that are hard to mitigate.

[kortschak]

I suspect that we are talking at crossed purposes here. Let me try to clarify.

I have a key (let's leave aside that it's the one that I want to use) which is pass phrase protected because I want the presence of a valid signature on a mail to indicate not just that the sender of mail had my key but that they had the mental state required to sign the message (thus indicating intention). At the moment AFAICS, this is not possible with the PM keys since that are purely indicative of identity (the first part of the pair above). What I'm asking is whether it would be possible to interpose a requirement for a pass phrase for signed messages. This ignores the trust model issues that I have with placing a secure key on someone else's server (notwithstanding the claims that you can't read it and that it is pass phrase protected).

I don't see this as niche; the ability to require a passphrase on a private key is part of the design of both ssh and pgp keys.

[bartbutler]

The short version is "not easily". The bridge could prompt for a password to sign messages but it would be difficult to do so on a per-message basis due to client timeout issues (the client request would remain "in flight" for this period and would probably error out. One might be able to hack around this by forcing a SMTP reauthentication and using that to indicate intention, but it's a pretty bad UX (you'd have to enter a password every time you hit send) and it's not clear how you'd enable sending without signing.

An alternative would be a setting on the bridge itself that turned on and off signing and required a pass phrase to enable/disable it, but that has its own problems.

[kortschak]

This is unfortunate and in my view a pretty significant defect. Elsewhere you've indicated that the the complete message is actually retained by you. Could you not present that message to third party mail services if the message has been signed by prior to receipt by PM? This has issues two because of the differential behaviour depending on the recipient, but currently you already have differential behaviour; their is signing within the walled garden of PM, but not outside.

[bartbutler]

There is signing to outside of PM, with the keys known to PM. What there isn't is signing "pass-through" for externally signed messages.

We could probably do this by having the bridge accept signing messages and also sign the message itself, so that the message has two signature packets and could be verified with either the key in PM or the external public key. Assuming PGP client support for this it could work and would overcome the issue identified previously. I maintain that using an external program to sign messages is a niche use case though.

[kortschak]

I maintain that using an external program to sign messages is a niche use case though.

Yeah, I disagree here. When the mail client supports signing as evolution and thunderbird do, it is integrated into the mail client. Doing it any other way adds friction, hence this issue.

[jonathancross]

One point not mentioned here would be keys on a hardware token such as a YubiKey. Having signature pass-through would be fantastic for this. Such tokens can offer much stronger security guarantees than a key that is available to software on the user's system. PM's bridge adding a second signature is perfectly fine and sounds like a good solution.

[kortschak]

@jonathancross Indeed. I can see, given adequate support, a nice meshing between the Librem5 (with its built-in support for a GPG smart card) and ProtonMail. At the moment though, that won't work.

[kortschak]

Is there any update on this?

Also @bartbutler is there any news on the plain text options you mentioned in https://github.com/ProtonMail/proton-bridge/issues/26#issuecomment-663964382?

[andrzejsza]

this is not forgotten. for now, we're focusing on the making sure that Bridge does not stripes the externally signed messages of their signatures (external to PM). for internal reference: GODT-973

[kortschak]

... and plain text options?

[andrzejsza]

pass through the text/plain is part of the same issue. as for the the preferential option for plaintext over HTML in general - let me confirm shortly, need to clarify if there are any dependencies.

[kortschak]

This appears to be partially fixed; if I send a signed mail from a desktop client to myself then the signature is noted and visible on the web client (both in the sent mail and in the inbox), but the send mail and inbox copies on the desktop client are not present (the client initially says there is an attachment, but when it examines the mail it sees it is not).

[andrzejsza]

could you check with the latest build (1.8.1)?

[kortschak]

This still appears to be broken as described in my last comment.

[tk-innoq]

I'm surprised that this issue is still open (also in build 1.8.3). There are a lot of discussions about not layering / supporting third-party-crypto in PM. This is completely valid but does not relate to the original problem (and the problem I just stumbled upon). As far as I understand, the original issue is about receiving signed mails (SMIME in my case) from a third party. In this case PM breaks the signature so that for example Thunderbird cannot verify it anymore. According to my analysis PM exchanges the original Content-Type header with a broken one:

Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="-- vs. Content-Type: multipart/mixed; boundary=

The first can be verified by mail clients (and openssl). As pointed out by several contributors to this thread, PM should not mess up the original mail headers. The behavior of PM imposes a security risk to mails not entirely sent with PM (as also already mentioned). By breaking SMIME verification the content of the received mails may have been tampered with, without any chance of noticing it.

[ShiveshM]

I have the same issue using Thunderbird: The recipient ends up with an attachment encoded in base64...

[kortschak]

@andrzejsza I'm following up on the status of GODT-973 wrt text/plain pass through.

[kjkent]

I just signed up to Protonmail and found this issue, which doesn't seem to have had any activity in over a year, and wondered if there was an update?

After reading the existing replies and those on other issues, am I understanding this right: should you not wish to trust PM to store your private key, or for instance if your private key is hardware-bound (e.g., YubiKey)... then PM is effectively incompatible with GPG? As it seems that the Bridge will mangle encrypted content and signatures and is therefore inoperable.

I've been under the impression that retaining control of your private key is a fundamental part of GPG, with many GPG-enabled packages supporting security keys via a local gpg instance. As GPG is promoted as a key feature of PM, I (seemingly wrongly) assumed it would offer an integration that doesn't involve trusting PM with your private key.

I truly do not wish to come across as combative but want to make sure I'm understanding this correctly.

[FryingPanBrock]

@kjkent You are exactly correct. In my disbelief, because of this very issue, I had to switch to another e-mail provider that did not tout “built-in encryption” as a selling point. Experience has taught me that such a feature is most likely incompatible with local encryption. Proton has made it clear they will not remedy the issue (see comments on https://github.com/ProtonMail/proton-bridge/issues/320), so the solution is either to trust Proton by uploading your private key and using their built-in encryption, or switching to another e-mail provider.

[dsommers]

@kjkent @FryingPanBrock I have ended up in an hybrid mode.

I have an SMTP gateway which I use when I want to send mails signed and/or encrypted with a non-Proton managed PGP key. Receiving mails encrypted with external keys seems work to fine now, both in Thunderbird and Proton webmail via Mailvelope. I should check signed-only mails (encrypted + signed works).

For anything which does not depend on the "external key" security level, I find Proton's key management reasonable enough and keep it there.

I do wish it would be possible to send mails encrypted using external keys via Proton Mail Bridge - that would make my setup simpler. At the same time this is more a feature for "power users" - and those users can use external SMTP gateways without compromising too much (since those mails are still PGP encrypted).

[xet7]

It seems that this issue is at Hacker News frontpage 2nd:

https://news.ycombinator.com/item?id=36639530

[yigib]

@kjkent @FryingPanBrock I have ended up in an hybrid mode.

I have an SMTP gateway which I use when I want to send mails signed and/or encrypted with a non-Proton managed PGP key. Receiving mails encrypted with external keys seems work to fine now, both in Thunderbird and Proton webmail via Mailvelope. I should check signed-only mails (encrypted + signed works).

For anything which does not depend on the "external key" security level, I find Proton's key management reasonable enough and keep it there.

I do wish it would be possible to send mails encrypted using external keys via Proton Mail Bridge - that would make my setup simpler. At the same time this is more a feature for "power users" - and those users can use external SMTP gateways without compromising too much (since those mails are still PGP encrypted).

So you are basically running your own email instance, AND paying for proton? Not to sound rude but isn't the point of paying for email hosting is so you don't have to manage it?

[dsommers]

So you are basically running your own email instance, AND paying for proton? Not to sound rude but isn't the point of paying for email hosting is so you don't have to manage it?

@yigib Well, "a man gotta do what a man gotta do" ... When you need a feature not available via the preferred approach, you look for ways solving that.

I also see e-mail as two services - incoming and outgoing. The issue I have now is with outgoing e-mails using external PGP keys. And my hybrid mode solves that, and keeps the rest with Proton. Even e-mail I send via this "outside Proton route" is using e-mail addresses hosted on Proton, so all replies ends up in my Proton account - and can be decrypted fine with external keys in Thunderbird. It is the sending part which is the issue.

Since I've also done e-mail hosting for over 15 years in a professional capacity, I kinda know the challenges related to that. Would it be better to send it via Proton Mail Bridge? Absolutely! But currently it can't be done. Recently I got the SMTP token approach enabled on my Proton account; I need to test that out properly to see if that can work.

[bartbutler]

Now that Bridge V3 is out we’ll take another look at what we can do to preserve existing signatures. It’s unlikely to be possible for internal (Proton) recipients but we may be able to do something for signed messages sent externally where the Bridge signs in addition to any existing signature.

This may help for some of the specialized use cases here and stuff like patches via SMTP.

[kortschak]

@bartbutler Can I follow up a follow up? https://github.com/ProtonMail/proton-bridge/issues/26#issuecomment-760593403

[bartbutler]

Are you referring to keeping the plaintext part of multipart/alternative? As I said before, I think we have a hidden option to switch to prefer plaintext rather than HTML that I can turn on for you. Ideal would of course be keeping both and that's where we'd like to go (the data model now supports it) but it hasn't been prioritized yet.

[kortschak]

Yes