Closed Bug 1671891 Opened 4 years ago Closed 3 years ago

BCC use is blocked with OpenPGP Encryption while there should be a warning only

Categories

(MailNews Core :: Security: OpenPGP, enhancement, P2)

enhancement

Tracking

(Not tracked)

RESOLVED FIXED
91 Branch

People

(Reporter: a.gruenewald, Assigned: lasana)

References

(Blocks 1 open bug)

Details

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Firefox/78.0

Steps to reproduce:

Try sending an PGP-encrypted message using BCC recipients.

Actual results:

A message is displayed, informing that BCC is not supported for PGP encrypted Messages and CC should be used instead.

Expected results:

There should be a possibility to use BCC even in encrypted Messages, after receiving a warnig (as in Enigmail)
It is known, that standart PGP-Encryption breakes the "secret" of BCC recipients. This is logical, as the the BCC will be "listed" in the used encryption keys, so every recipient will be able to look up these recipients.
But while this is a problem for some use-cases of BCC (where the recipients should remain secretly), in other use-cases this would not be a problem. We use BCC, for example, to archive send email on a second mailbox. We do not want to use CC, because the recipient should not think about wether or not including our archive mailbox in his replies (by using "Reply to all") we do not even want to publish our archive encryption keys only to avoid that an "Reply to all" from someone will be sent unencrypted.
There should be a way to allow BCC in encrypted mails, may be even "hidden" in the advanced configuration of Thunderbird.

Status: UNCONFIRMED → NEW
Component: Security → Security: OpenPGP
Ever confirmed: true
Product: Thunderbird → MailNews Core

I agree we should fix this. Many times you don't care about revealing the identity, you just want to bcc to get someone out of the loop, or bcc yourself for archival or debugging purposes.

Priority: -- → P2
See Also: → 1655088

It is known, that standart PGP-Encryption breakes the "secret" of BCC recipients.

This is partially true. A naive implementation of bcc does indeed leak the bcc recipients to the other recipients. However, a better implementation sends the message N+1 times where N is the number of bcc recipients.

Assignee: nobody → lasana

Magnus, implementing Neal's suggestion would probably require a lot of code changes. Currently the flow of the OpenPGP TB code assumes that just one message is sent, and has global tracking flags for the message. We'd require a wrapper that routes through the composer sending multiple times, but only does the sent-folder-saving once, and keeps track of any failures that happen. For example, sending of the to/cc message might succeed, sending to the first bcc message could fail (e.g. destination server rejects), and sending to additional bcc messages might work.

Further complication is an OpenPGP digital signature. If the user has requested that the message is signed and encrypted, we'd have to sign only once - for consistency and efficiency, and then use that signed message multiple times, encrypting for each recipient.

I'm not convinced it's worth the work on that complicated model.

It might be more reasonable to warn the user.

I'll add another comment with a suggestion.

Yes, I agree sending separate messages is out of scope and not the same thing: then you don't see who else (To/Cc) it's addressed to (or you'd send them multiple messages).

Suggestion:

  • as part of the process that creates recipient "pills",
    we check if there is at least one BCC recipient that isn't the sender email address

  • the first time the above check is true, we add a notification bar
    to the current composer window

  • the notification could contain this text:
    "Please note: In encrypted messages the BCC list isn't hidden.
    All recipients may be able to identify the BCC recipients."

If we do the above, it could be considered sufficient information for the user, and we could allow the use of BCC for encrypted messages.
(We'd still require that we can encrypt for each recipient, including BCC recipients.)

Alessandro, any thoughts from your perspective on this suggestion?

The technical explanation is: The encoding of an encrypted message contains the key ID of each message recipient. Because we prefer to send a single message (not send multiple different messages), this will include the key IDs of the BCC recipients.

Flags: needinfo?(alessandro)

(In reply to Kai Engert (:KaiE:) from comment #5)

  • the first time the above check is true, we add a notification bar
    to the current composer window

Clarification: "The first time" applies to each composer window.

I'd prefer to remind the user every time the user opens a new composer window and the above check is true (for the first time in that composer window).

I'm okay with using a notification in the composer window if the condition specified above is required.
Something very similar to what we do when detecting the "attachment" (and similar) keywords in the message.

Should we maybe consider adding a button to have a "Don't show this again" option for users that have to deal with sending encrypted Bcc almost daily?

Flags: needinfo?(alessandro)

I don't think we'd need a "don't show again" button. Perhaps word it as

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

Status: NEW → ASSIGNED

Hot off the press and ready for a test.

Attachment #9229332 - Attachment description: Bug 1671891 - And warning for Bcc recipients when using openpgp. r=mkmelin → Bug 1671891 - Add warning for Bcc recipients when using OpenPGP. r=mkmelin
Attachment #9229332 - Attachment description: Bug 1671891 - Add warning for Bcc recipients when using OpenPGP. r=mkmelin → Bug 1671891 - And warning for Bcc recipients when using openpgp. r=mkmelin
Attachment #9229332 - Attachment description: Bug 1671891 - And warning for Bcc recipients when using openpgp. r=mkmelin → Bug 1671891 - Add warning about Bcc recipients when encyption is enabled. r=mkmelin

Thanks for working on this. You have successfully removed the blocking of BCC sending.

However, the phab patch is still incomplete. The message that is sent cannot be read, because it isn't encrypted with the keys for the BCC recipients.

I'll work on an additional patch in a separate bug.

Blocks: 1718987

(In reply to Kai Engert (:KaiE:) from comment #11)

Thanks for working on this. You have successfully removed the blocking of BCC sending.

However, the phab patch is still incomplete. The message that is sent cannot be read, because it isn't encrypted with the keys for the BCC recipients.

I'll work on an additional patch in a separate bug.

Sounds good, thanks.

Target Milestone: --- → 91 Branch

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/dddfa1d24896
Add warning about Bcc recipients when encyption is enabled. r=mkmelin

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Blocks: 1740355
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: