Open Bug 1790736 Opened 2 years ago Updated 2 months ago

PGP Mails are forwarded without encryption

Categories

(Thunderbird :: Filters, defect)

Thunderbird 91
defect

Tracking

(Not tracked)

People

(Reporter: wicki, Unassigned)

References

Details

User Agent: Mozilla/48.0 (X11; Linux x86_64; rv:48.0) Gecko/20100101 Firefox/48.0

Steps to reproduce:

Create new Local-Folder
Copy a PGP-Mail into it
Create a n filter with forwarding to foo@bar.de
Execute filter for folder
Look into mail of foo@bar.de

Tested with:
Thunderbird/91.8.1 and ​91.11.0 (64-Bit) - Linux

Actual results:

The Mail is received without any encryption!
The Subject is "Fwd:..." - but mail-content is plain
unencrypted text.

It does not matter, if foo@bar.de PGP-key is known or not.

Expected results:

A warning before sending - or send should be
done encrypted.

Thanks for your report.
I agree it's not ideal. But I'm not sure it's a security issue, because it's the user's own's decision and action that triggers the forwarding.
I'd agree this problem as an incomplete implementation that doesn't warn the user about all possible, potentially problematic consequences of configuring automatic filter actions.

Fixing the scenario you describe will have larger consequences, I think.

Sending the message with encryption might not be possible. This means that a filter action could fail for some messages. How would we handle that? A filter could run on many messages, so it isn't as simple as showing a popup for each failure. We'd have to ensure the user can learn about all failed filter actions.

I think this is a difference from today, because today all filter actions are expected to always succeed, right?

Hi Kai,

thanks for your response.

Of course, it is a security issue:

When I set the sending-defaults of TB to "send only encrypted mails", mails should not be sent
as unencrypted plain text. never
(Even mails form a PGP-source and even without telling the user that exactly this is happening now).

What has happened:
A (inexperienced) new TB-user would like to get a notice at his non-PGP-adress when a mail
reaches his PGP-account. So hi configured a forwarding-filter.
And we were all shocked (and cant believe it), when he hold us:
"I got my forwarded PGP-mail without encryption".

because today all filter actions are expected to always succeed, right?

I see the problem - but as TB, configured with "send only encrypted mails"
must not be able to send a non-PGP-mail without encryption and without
informing/asking the user.

I need only 1 minute access to the TB of a TB-user to configure such a forwarding-filter.
And from this moment on, I will get all of his PGP-Mails in clear unencrypted form.
And the user will not know this.

" This means that a filter action could fail for some messages."
May be, should be....
But: It's better, to block a filter than sending confidential information unencrypted.

Yes, I think this is really a security issue.

regards

wicki

A way for the user to shoot themselves in the foot is not necessarily a security issue. This mostly seems like a usability issue to me.

Not sure what the easiest solution would be. Trying to automatically send encrypted emails without user interaction and failing if they can't be sent sounds like a mess to me. Maybe it should be as simple as encrypted emails are never sent externally by filters, unless you uncheck a default security preference.

Of course, if we did that, we still need some sane way to warn users that that is what's happening, and not just silently ignore emails that should be filtered...

If the user has configured that all new emails should have encryption enabled by default, then I agree it's a security issue.

Alex, do you have thoughts? How could we inform the user that that we cannot apply filters to emails safely, because the processing would result in an unacceptable downgrade of the email's existing protection level? Informing the user would have to cover the scenario that many messages are affected, and the non-filtering may also happen while the user is not actively sitting in front of Thunderbird.

Flags: needinfo?(alessandro)

Isn't it possible, to send the already encrypted content as a file-attach?

Status: UNCONFIRMED

sorry, but still as "unconfirmed" - after one month ?

If a filter action needs to fail, it should just fail. Failure will be shown in the filter log.

This failure (at least theoretically) applies only to fwd inline though. If we forward the message intact as .eml attachment, there is no problem.
If the identity is configured to send encrypted, we could just force forward as attachment mode instead.
https://searchfox.org/comm-central/rev/ed470fa3a2af7c566cc9befec8d56c429d8b9c50/mailnews/compose/src/nsMsgComposeService.cpp#992

I don't think this bug needs to be hidden: it's a bug that relates to security but not a security issue per se and not really exploitable.

Status: UNCONFIRMED → NEW
Ever confirmed: true

I agree with my team members here, this is primarily a UX issue rather than a security issue.
This can happen primarily (and probably exclusively) after a user action, most likely the owner of the account.

Not to be confrontational, but we should really stop using the "if a user access my computer and sets up a filter..." type of narrative. If someone access your computer with the ability to edit things, you got way bigger problems than a TB filter.

If the identity is configured to send encrypted, we could just force forward as attachment mode instead.

I think this sounds like a good solution, so we don't mess with trying to automatically send encrypted messages, and we don't arbitrarily fail to run the filter.

We should also add an extra layer of awareness for those users that end up in this situation.

  • If the user sets up a forwarding filter on an account where "always send encrypted" is configured, we should prompt them with an alert to explain that encrypted messages will be forwarded as attachments.
  • In the same message we should also recommend to not set a forwarding filter at all.
Flags: needinfo?(alessandro)
Group: mail-core-security
Duplicate of this bug: 1874354
See Also: → 1629368

I think a solution should not only be applied when "always send encrypted" is configured. Encrypted mail should never be automatically forwarded unencrypted.
Would it be possible to simply change the order in which incoming mail is processed? Apply any filters first, then decrypt encrypted content. Even better: Decrypt only when the mail is actually viewed.

You need to log in before you can comment on or make changes to this bug.