Comments (9)
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 <[email protected]>
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 <[email protected]:mozilla/releases-comm-central.git>.
from neomutt.
Great find! That sounds perfect!
Here's an HTML version of the docs: https://www.gnupg.org/documentation/manuals/gpgme/Encrypting-a-Plaintext.html
from neomutt.
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? ;-)
from neomutt.
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 ofBody
shuffling, UI questions, hooks, signing/encryption before finally callinginvoke_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.
from neomutt.
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 <[email protected]> To: Alex Lacamoire <[email protected]> Cc: Bing Crosby <[email protected]> Bcc: Cate Blanchett <[email protected]> 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 <[email protected]> To: Alex Lacamoire <[email protected]> Cc: Bing Crosby <[email protected]> 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 [email protected]
Recipient: RSA key, ID 934F123BFA86E1E9 Bing Crosby [email protected]
Recipient: RSA key, ID 7D276576DECDF4F8 Cate Blanchett [email protected]
Recipient: RSA key, ID 544F271C223CE792 Richard Russon (flatcap) [email protected]
[-- 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) [email protected]
created: Fri 05 Apr 2024 16:58:40 BST
[-- End signature information --][-- The following data is signed --]
To: Alex Lacamoire [email protected]
Cc: Bing Crosby [email protected]
Subject: TestTEXT
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 thatCate Blanchett
was also sent a copy of the email.Can we change the behaviour to mimic
gpg --hidden-recipient
for thebcc:
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.
from neomutt.
Can we change the behaviour to mimic
gpg --hidden-recipient
for thebcc:
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:
from neomutt.
I'll prepare a patch next week. :)
from neomutt.
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.
from neomutt.
Can we change the behaviour to mimic
gpg --hidden-recipient
for thebcc:
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?
from neomutt.
Related Issues (20)
- Compose Menu - top bar not updated after attaching files from file browser HOT 3
- Subject with non-printable characters or new line is shown with `?` HOT 30
- `Today` conditional date broken HOT 4
- Lag on half-down/half-up scrolling on macOS HOT 5
- Do we need to handle <stddef.h> specially? HOT 1
- conditional format strings broken in 2024-04-25 HOT 8
- Duplicate gpg keys in key selection menu for message encryption HOT 18
- segfault while opening a mailbox in from the sidebar HOT 2
- Doubts about paranoic defensive programming style HOT 3
- C dialect HOT 2
- tag-prefix doesn't show-up in attach HOT 5
- Doubts about some `*const` pointers HOT 5
- How to use the notmuch command <modify-labels> to tag emails with tags containing spaces?
- Is it possible to edit the automatic title when forwarding or replying a message? HOT 1
- Progress for postponing a message with remote (IMAP)
- autocrypt breaks command line argument `-e "push foo"` HOT 4
- How to forward an email thread to someone else together with attachments ? HOT 3
- `delete-thread` does not support `tag-prefix` operator
- split outgoing email into batches to work around max number of recipients limit in some SMTP providers (infomaniak) HOT 3
- save-message from GMail over IMAP to local box doesn't delete original HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from neomutt.