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: #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 #26 (comment) and #26 (comment) (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 #26 (comment).

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

[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 #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? #26 (comment)

[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

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

:-(

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