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

[Neustradamus]

To follow this ticket.

[kortschak]

Patron: [enters restaurant] Waiter: I can bring you a menu. Would you like that? Patron: Yes. Patron: [waits] [end scene as restaurant closes — curtain fall]

[dsommers]

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.

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.

[jonathancross]

This feature is currently only available for select Proton for Business customers and Visionary users with custom domain addresses.

:-(

[dsommers]

@skrati First rule of asking questions is to ask them in the right project and in the right issue ticket related to your question.

So, ask yourself - is your question related to "Proton Mail Bridge is not able to send PGP encrypted mails using external, non-ProtonMail hosted keys"? This is the topic towards the end of the discussions here; it started a bit different - but it is the same kind of challenge, just that the problem got gradually different as newer Proton Mail Bridge releases arrived.

If you feel your question is not related this topic .... I would suggest you to try to find a better place and not just jump into a random encryption related bug report thread. Since your question touches aspects I'm not too familiar with, I cannot point you anywhere else. But OpenSC is definitely more related to your question than Proton Mail Bridge will ever be.

[skrati]

@dsommers sorry for asking this question here . I understood now, thank you for your help.

[tbm]

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.

[xet7]

@tbm

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.

[tbm]

Here is Proton CEO interview 2 days ago, it answers many questions:

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 --clearsign to sign and put in an email (no attachment). This was also rejected. I also sent a GPG encrypted mail to a friend and he received garbled/empty text.

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.

[kortschak]

@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.

[xet7]

@kortschak

Hmm. I'll try to watch that interview again. Maybe I am wrong.

[kortschak]

This is the time-stamp to see the comments about bridge.

[xet7]

@kortschak

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:

1. New Outlook from Microsoft is not fully local, they copy other email usernames, passwords, emails serverside, and may stop actually supporting locally running IMAP client https://cybernews.com/privacy/new-outlook-copies-user-emails-to-microsoft-cloud/ . That means, that because Proton can not control Outlook, Microsoft is the middle man getting all data, and it would be better to have local Proton client. Most of Proton users are Windows users, if I understand it correctly. Sure, Windows also has a lot of telemetry, copying clipboard data etc, so it's not the safest environment.
2. Using local Proton Client would in theory improve user experience, because then there is no separate configuration for IMAP ports etc, there is only need to login with username and password. But replacing standard IMAP with APIs would bring question, how to move existing email between local email client and Proton, if there is no Proton Bridge? Then it would need to convert from APIs to IMAP or mailbox or some other format? I have most of my email at local Betterbird, there is not enough storage space to keep it at Proton, all that extra storage at Proton would cost extra.
3. Thunderbird has some telemetry, that Betterbird does not have. Thunderbird is removing features, that Betterbird is adding back.
4. Using local PGP private keys to encrypt email with Proton Bridge does not work correctly, because somewhere those email headers do not keep all original information, and this is not fixed yet.
5. While Proton clients are Open Source, there is a lot of encryption etc advanced code, there is high bar to try to run code locally, understand it, contribute to it.
6. While it is good that at Proton all data is encrypted, Proton can not access that data, that is not enough, when there is not enough standard ways to import/export data with IMAP, keeping PGP headers etc as original. While Proton makes using encryption more user frieldy, when staying inside of Proton Suite, it is more like mass market encryption for Windows users, not standards compliant encryption for Linux/QubesOS security users. For those that need actual security, it still is about using local email clients with standards compatible IMAP/SMTP servers.

[TheFranconianCoder]

@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.

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.

[kortschak]

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.

[xet7]

@kortschak

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.

[TheFranconianCoder]

@kortschak

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.

[rakoo]

It's an old comment, but there is a fundamental issue in what the bridge is supposed to be

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.

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.

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.

This is incompatible with your claim in another comment:

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

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.

[exander77]

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.

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.

[ismay]

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.

@rakoo well put. This reminds me a lot of an issue that's been open almost as long for signal: https://github.com/signalapp/Signal-Android/issues/9729#issuecomment-1856040195. 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.

[Wesleycoellh0]

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

[FatalFit]

Pretty annoying that this hasn’t been fixed in 4 entire years