BCC leakage in encrypted mail

[alejandro-colomar]

I'll paste @flatcap 's original report (#4223 (comment)):

---

bcc leakage!

This isn't a bug in your changes, just a general feature of (Neo)Mutt.

Experimenting with both your PRs (#4221, #4227)...

I sent a signed/encrypted email to multiple recipients:

Compose

    From: Richard Russon <rich@flatcap.org>
      To: Alex Lacamoire <al@tangerine.com>
      Cc: Bing Crosby <bc@apple.com>
     Bcc: Cate Blanchett <cb@elderberry.com>
 Subject: Test

Security: Sign, Encrypt (PGP/MIME)
 Sign as: 0x69AD1D636AC292E820658C16EBC150E4B5DA63DF

Note, I have: set pgp_self_encrypt = yes

Email arrived (annotated with key owners)

Date: Fri, 5 Apr 2024 16:58:40 +0100
From: Richard Russon <rich@flatcap.org>
To: Alex Lacamoire <al@tangerine.com>
Cc: Bing Crosby <bc@apple.com>
Subject: ...
User-Agent: NeoMutt/20240329-149-6243fc

[-- Begin encryption information --]
Recipient: RSA key, ID 19D4D91AF95EE3D1 Alex Lacamoire <al@tangerine.com>
Recipient: RSA key, ID 934F123BFA86E1E9 Bing Crosby <bc@apple.com>
Recipient: RSA key, ID 7D276576DECDF4F8 Cate Blanchett <cb@elderberry.com>
Recipient: RSA key, ID 544F271C223CE792 Richard Russon (flatcap) <rich@flatcap.org>
[-- End encryption information --]

[-- The following data is PGP/MIME encrypted --]

[-- Begin signature information --]
Good signature from: Richard Russon (flatcap) <rich@flatcap.org>
            created: Fri 05 Apr 2024 16:58:40 BST
[-- End signature information --]

[-- The following data is signed --]

To: Alex Lacamoire <al@tangerine.com>
Cc: Bing Crosby <bc@apple.com>
Subject: Test

TEXT

NeoMutt effectively encrypts like gpg --recipient.
In the example above, the recipients can infer that Cate Blanchett was also sent a copy of the email.

Can we change the behaviour to mimic gpg --hidden-recipient for the bcc: field?

[alejandro-colomar]

bcc leakage!

This isn't a bug in your changes, just a general feature of (Neo)Mutt.

Hmmm!

Experimenting with both your PRs (#4221, #4227)...

I sent a signed/encrypted email to multiple recipients:

Compose

    From: Richard Russon <rich@flatcap.org>
      To: Alex Lacamoire <al@tangerine.com>
      Cc: Bing Crosby <bc@apple.com>
     Bcc: Cate Blanchett <cb@elderberry.com>
 Subject: Test

Security: Sign, Encrypt (PGP/MIME)
 Sign as: 0x69AD1D636AC292E820658C16EBC150E4B5DA63DF

Note, I have: set pgp_self_encrypt = yes

Email arrived (annotated with key owners)

Date: Fri, 5 Apr 2024 16:58:40 +0100
From: Richard Russon <rich@flatcap.org>
To: Alex Lacamoire <al@tangerine.com>
Cc: Bing Crosby <bc@apple.com>
Subject: ...
User-Agent: NeoMutt/20240329-149-6243fc

Seems good. The delivered message doesn't show the BCC.

[-- Begin encryption information --]
Recipient: RSA key, ID 19D4D91AF95EE3D1 Alex Lacamoire al@tangerine.com
Recipient: RSA key, ID 934F123BFA86E1E9 Bing Crosby bc@apple.com
Recipient: RSA key, ID 7D276576DECDF4F8 Cate Blanchett cb@elderberry.com
Recipient: RSA key, ID 544F271C223CE792 Richard Russon (flatcap) rich@flatcap.org
[-- End encryption information --]

Seems bad, but can be expected: we only encrypt once.

[-- The following data is PGP/MIME encrypted --]

[-- Begin signature information --]
Good signature from: Richard Russon (flatcap) rich@flatcap.org
created: Fri 05 Apr 2024 16:58:40 BST
[-- End signature information --]

[-- The following data is signed --]

To: Alex Lacamoire al@tangerine.com
Cc: Bing Crosby bc@apple.com
Subject: Test

TEXT

And seems good. The protected headers don't show the BCC. It's just the list of encryption recipients.

NeoMutt effectively encrypts like gpg --recipient. In the example above, the recipients can infer that Cate Blanchett was also sent a copy of the email.

Can we change the behaviour to mimic gpg --hidden-recipient for the bcc: field?

We could fix it in several ways:

• Encrypt only once, as we do, but ask gpg to hide the recipients that correspond to BCC. This would leave traces to the recipient that someone else can read it, possibly a BCC. It's not as bad of a leak, but it still leaks the fact that someone got a copy. You could argue that it's a feature.

• Encrypt several times, so that each copy is only encrypted the recipients that the recipient of the copy should see. Slower. Less leaky. But makes it easier to allow the sender to leak data without the recipient noticing (if they really want, they'll do it anyway).

The first one is what you suggest. At first glance, I agree, as I think it will be simpler to implement.

[alejandro-colomar]

thunderbird(1) is also vulnerable to this issue (but at least they show a warning). While composing such a message, it shows a warning:

When sending an encrypted message, recipients in Bcc are not fully hidden. All recipients may be able to identify them.

And a button "Understood".

---

The commit that added that warning to thunderbird(1) was:

commit f8407e33ea4e5ab075adf0815f7be2a3ef667a8a
Author: Lasana Murray <lasana@thunderbird.net>
Date:   Sat Jul 3 10:49:06 2021 +0300

    Bug 1671891 - Add warning about Bcc recipients when encyption is enabled. r=
mkmelin
    
    Differential Revision: https://phabricator.services.mozilla.com/D118951
    
    --HG--
    extra : amend_source : 181d2af149e11ad67d4eebe33e1f7c0f9e3c3553

The repository is <git@github.com:mozilla/releases-comm-central.git>.

[alejandro-colomar]

Can we change the behaviour to mimic gpg --hidden-recipient for the bcc: field?

It seems we can. I'll need to learn more about how we encrypt, and how gpgme works, but here's what I saw, which sounds like we can:

alx@debian:~/src/mutt/neomutt/main$ grep -rIho '\<gpgme_[a-z_]*(' | sort | uniq | grep encrypt
gpgme_op_encrypt_ext(
gpgme_op_encrypt_sign_ext(

The docs for gpgme_op_encrypt_ext() are here:
https://www.gnupg.org/documentation/manuals/gpgme.pdf#Encrypting%20a%20Plaintext

Which documents a way to hide recipients:

[flatcap]

Great find! That sounds perfect!

Here's an HTML version of the docs: https://www.gnupg.org/documentation/manuals/gpgme/Encrypting-a-Plaintext.html

[alejandro-colomar]

I'll prepare a patch next week. :)

[alejandro-colomar]

I've been looking at the code, and it needs some non-trivial work, compared to the other patch sets I have pending. I'll queue this after the other crypto patches. I may refactor some stuff before doing it.

The thing is that we write the key list (a string) too early, and then we don't remember what is bcc and what's not. So I need to pass two keylists: one normal and one hidden. That'll need some refactor.

[alejandro-colomar]

Can we change the behaviour to mimic gpg --hidden-recipient for the bcc: field?

It seems we can. I'll need to learn more about how we encrypt, and how gpgme works, but here's what I saw, which sounds like we can:

alx@debian:~/src/mutt/neomutt/main$ grep -rIho '\<gpgme_[a-z_]*(' | sort | uniq | grep encrypt
gpgme_op_encrypt_ext(
gpgme_op_encrypt_sign_ext(

The docs for gpgme_op_encrypt_ext() are here: https://www.gnupg.org/documentation/manuals/gpgme.pdf#Encrypting%20a%20Plaintext

Which documents a way to hide recipients:

@dd9jn reported that this approach would be problematic.
https://marc.info/?l=mutt-dev&m=171361683212226&w=2

He suggested sending separate mails to each BCC, which as a user, I agree it provides a beter UX. It will be painful to implement it, though. :-)

Any opinions?

[flatcap]

He suggested sending separate mails to each BCC

Yeah, I mentioned the same idea in #4251 / *07 Hide Bcc.

For plain emails, it'd be a piece of cake.
Both SMTP and Sendmail have a single function with a bcc parameter.

When signing/encryption is involved, it gets messy.
mutt_send_message() is second longest function in NeoMutt -- 844 lines.
It's an ugly mix of Body shuffling, UI questions, hooks, signing/encryption before finally calling invoke_mta().

It desperately needs breaking up, but I haven't investigated at all.

Feeling brave, Alex? ;-)

[alejandro-colomar]

He suggested sending separate mails to each BCC

Yeah, I mentioned the same idea in #4251 / *07 Hide Bcc.

For plain emails, it'd be a piece of cake. Both SMTP and Sendmail have a single function with a bcc parameter.

When signing/encryption is involved, it gets messy. mutt_send_message() is second longest function in NeoMutt -- 844 lines. It's an ugly mix of Body shuffling, UI questions, hooks, signing/encryption before finally calling invoke_mta().

It desperately needs breaking up, but I haven't investigated at all.

Feeling brave, Alex? ;-)

Yeah, I guess I should do it, as a punishment for making the bug shallow. :-)

It'll take some time, possibly a year, though. It'll get to the end of my queue, after I learn more about neomutt(1)'s internals.