-
Notifications
You must be signed in to change notification settings - Fork 156
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
Signed emails has broken signatures after ProtonMail mangles them #26
Comments
Can you share more details how to reproduce your problem? |
Send signed email to ProtonMail. 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. |
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. |
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. |
PGP in my case. It is only seamless in the sense that the Emperor's clothes were seamless. |
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. |
No I don't. However, PM should not be stripping signatures no matter what. Requiring that argues somewhat against seamlessness. |
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? |
Yes, it's PGP/MIME. I am signing with the mail client (evolution) which in turn shells out to 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. |
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. |
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: #18
The misunderstanding is yours. ProtonMail is marketed as follows:
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? |
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.
Yes. In the absence of that, it would be nice if it didn't break things.
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.
Again, this is unfortunate, for the same reasons.
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.
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's something that can be considered as an opt-in feature perhaps, and would be more useful if paired with key lookup.
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.
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.
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.
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.
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. |
Seemless? For this to work, only thing you need to do is "not to fuck the emails up". |
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.
Yes.
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?
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.
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.
Thanks. I'll wait because unfortunately while I prefer to read plaintext, some mailers do not include fall-back plaintext. |
As a follow up, can you explain this
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. |
@bartbutler ping re #26 (comment) and #26 (comment) (quoted section below)
|
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. |
Thanks, @bartbutler. That's part 1 of 2. Can you also address #26 (comment). |
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. |
OK, so the bridge would pop-up a passphrase request for non-keychained keys? |
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. |
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. |
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. |
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. |
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. |
It seems that this issue is at Hacker News frontpage 2nd: |
So you are basically running your own email instance, AND paying for proton? |
@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. |
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. |
@bartbutler Can I follow up a follow up? #26 (comment) |
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. |
Yes |
To follow this ticket. |
Patron: [enters restaurant] |
Just to follow up on this one. The SMTP submission setup which can be enabled on many paid plans now seems to work well with external keys. It works just as expected. E-mails are passed through, encrypted with the external key. Proton Mail webmail cannot decrypt the message automatically; however Mailvelope is capable of decrypting it and displaying it inline in Proton webmail. Thunderbird seems to decrypt it fine as well. Recipients are also able to open and decrypt those mails. Would still be good that this same user experience would be possible via Proton Mail Bridge - as now I need to take care myself to enable encryption manually; where Proton Mail Bridge will do that automatically. But there is at least a viable alternative for the larger masses without needing to setup their own external SMTP gateway. |
:-( |
This comment was marked as off-topic.
This comment was marked as off-topic.
@dsommers sorry for asking this question here . |
I came came across this issue. Thanks to @exander77 for expressing the problem so clearly - Proton should not mess with my incoming or outgoing emails. I thought Proton Bridge was a way to get normal IMAP and SMTP. I don't need Proton interfering in my emails. I can't believe this issue has been open for almost 4 years. I'll move back to Gandi which provides a standard IMAP and SMTP interface. |
Here is Proton CEO interview 2 days ago, it answers many questions: https://www.youtube.com/watch?v=Dp7ght2fMR4 I have participated to translating Proton to Finnish. I also pay for my Proton account, that is my way of supporting Proton, because Proton keeps my data secure. I have seen how Proton keeps improving their services, keeping security first. For me, Proton Bridge and other services have worked great. Anyway, that is just my opinion. YMMV. |
Does the interview address this particular issue? I thought this issue is so obvious it needs to explanation but let me elaborate a bit (although I think @exander77 has done it already). Let's say I buy a hard drive to store my data. Now the hard drive promises built-in hardware encryption. Great. I probably use LUKS anyway to encrypt my data, but if there's built-in encryption in addition, why not. But when I store my data on this super-safe hard drive, I want to get it back 1:1. I don't want the hard drive to mess with my data. That would be called data corruption. Now when I send an email, I want my email provider to deliver what I sent. Sure, it can add email headers and stuff, but the contents should be exactly the same. Now if my email provider wants to add security by encrypting the email on the server or for the transport (e.g. via a bridge), sure, that sounds great. But I don't want my email provider to garble my messages. I'd call that data corruption. What's worse, it does so silently. (@exander77 above said it well: "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.") Now case in point. I moved to Proton a few weeks ago. I just want IMAP and SMTP. I don't need the web interface but ok it's nice to have just in case. It's nice they store data safely by encrypting it. This week I wanted to vote in a Debian vote by sending a GPG signed message. I was surprised to see that it was rejected as invalid. Remembering that I noticed Proton changing emails from multipart to HTML (which is a big WTF for me but was low priority so I didn't investigate), I was wondering if it doesn't like the GPG attachment. So I used This is data loss. And what's worse, it's silent data loss. I only noticed because my vote failed. I don't see any way how silent data loss/corruption is okay and how a ticket like this can be open for almost 4 years. But, ok, it seems like there are different design philosophies (although, again, I don't see how silent data loss is ok under any circumstance). I'll be moving to an old-fashioned email provider that provides standard IMAP/SMTP without garbling messages. |
@xet7 I think you were watching a different interview to the one I saw. I heard a bunch of empty garbage and an indication that an open integration like bridge is likely to go away. |
Hmm. I'll try to watch that interview again. Maybe I am wrong. |
This is the time-stamp to see the comments about bridge. |
Thanks a lot! It seems that I did not watch the end of the interview. Having watched it again, my understanding about it and related issues is:
|
I'm a bridge user, too. I absolutely agree, that supporting different clients is a lot of effort. And that's at all not the main business of Proton. Personally I still expect an API to access my data (mails, calendar, contacts). Need just something for automation. Currently I mainly use the SMTP interface. But that should be even more straight forward, compared to IMAP. |
The point in 1. buys completely in to Microsoft's approach to EEE. This is a terrible thing to do. By dropping a standard, MS wins this again and the world of open integration gets slightly worse. By foisting yet another separate client on people integrated calendar/mail/etc becomes harder for people who live across ecosystems; I span a few and use evolution with the help of the bridge. Without the bridge, Proton becomes untenable for me. |
Proton Bridge is also what I use daily with Betterbird. I often move my emails from many different email accounts to local folders, to keep emails locally, and make backups. I often need to search something from old emails. If thre were not Proton Bridge, I would need some similar software with similar features, to be able to use ProtonMail. |
They should offer just kind of a SDK for accessing all data. Maybe even open for free accounts. New bridges will be available soon. |
It's an old comment, but there is a fundamental issue in what the bridge is supposed to be
Wrong. The bridge is two things: bringing encryption to non-encrypted emails, AND an IMAP/SMTP interface to the internals of proton. Some people don't want the first, only the second because Proton is not standard; unfortunately there is no way to say "just forward it, I know what I'm doing". And this is what this, and so many issues want. One way to fix it is to offer a native IMAP/SMTP interface to your servers directly.
This is incompatible with your claim in another comment:
You want to build a system where correspondents don't require server trust to encrypt emails, BUT you also disallow all communications with peers that aren't known by Proton. You're acting as yet another centralization point here, in that I need to give you all the public keys all the people I talk to before being allowed to talk to them. This is the basis of server trust that you want to fight against. Your goal of providing encryption for all is worthy, but you're doing this at the expense of existing working solutions, and more importantly, at the expense of alternative softwares/processes that do it without you. Your solution is NOT making encryption available to all, it's capturing people's communication to provide encryption. I think you should be transparent with that. |
It is much easier than you are making it sound, 99% of the work is to just follow the standard and implement at least a minimal subset of the IMAP. Most problems with 3rd party clients lies with bad implementation in the Bridge. |
@rakoo well put. This reminds me a lot of an issue that's been open almost as long for signal: signalapp/Signal-Android#9729 (comment). It's not identical, but the discussion there reminds me a lot of your comment. I know that this is strictly speaking off topic, but in a broader sense I think there are similarities in the approach and the resulting problems. |
Pretty annoying that this hasn’t been fixed in 4 entire years |
S/MIME:
The text was updated successfully, but these errors were encountered: