Open Bug 1627962 Opened 5 years ago Updated 4 months ago

Support OpenPGP encrypt/decrypt filter actions

Categories

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

enhancement

Tracking

(Not tracked)

People

(Reporter: KaiE, Unassigned, NeedInfo)

References

(Blocks 2 open bugs)

Details

Enigmail supported 3 actions for message filters:

  • create decrypted copy
  • decrypt permanently
  • encrypt to key

I'd like to disable those actions for now, but we can consider to enable them at a later time.

(Not all of the dependent code has yet been ported, for example persistentCrypt.decryptAttachment).

Also, for consistency, it would be good to offer these actions for both OpenPGP and S/MIME.

Would that decrypted copy be stored locally only so that the user can do a fulltext search on them without compromising the security of the message stored on the server?

(In reply to Selek Respa from comment #1)

Would that decrypted copy be stored locally only so that the user can do a fulltext search on them without compromising the security of the message stored on the server?

Patrick, how does Enigmail implement this currently?

Priority: -- → P3

For the record, to decrypt a message permanently, Enigmail uses code originally copied from the add-on "Header Tools Lite". Basically, the a new message is written into a file, that file is added as a message and then the original message is removed. The p≡p version of this code can be found here in copyMessageToFolder(msgHdr, content, ...) where msgHdr is the header of the message to be removed and content is the MIME text of the new message:
https://pep-security.lu/dev/repos/pEp_for_Thunderbird/file/4e3ed7810783/addon/content/TbHelper.js#l23

This method has some disadvantages: The new message receives a new message header, the selection in the thread pane/message list is lost unless some additional hacks are implemented to display the "new" message, and it's visible to the user that one message disappears from the thread pane and then a new one arrives making for a rather strange behaviour. Maybe it's not that bad in the context of this bug since you plan to decrypt on filter action. There is also bug 280588 which calls for permanent decryption in local folders (due to the known search restrictions, bug 188988 and bug 1562737).

So for the benefit of all encryption solutions in the Thunderbird ecosystem, I would suggest to implement a function to replace the content of a given message in the backend. That would then trigger a re-display of the content without any unwanted side effects.

Please let us know what you think.

I am still running a pre-78 version of Thunderbird with Enigmail for the sole purpose of getting a decrypted version of my OpenPGP message so that I can search through those messages.
There are two things that Enigmail implemented that would be of great help in TB78.

  • in Filter Rules implement a new condition "OpenPGP encrypted" to match all those encrypted messages coming in
  • Create Decrypted Copy with a parameter to select a folder
    Enigmail also implements a "Decrypt permanently" but I don't consider that important (the original message can always be deleted).
Blocks: 280588
See Also: → 1693332
Severity: normal → S3

I would like to see a method of encrypting all email stored locally. The custom domain provider I use does not encrypt emails 'at rest', so having a method to encrypt email managed by Thunderbird would be a significant privacy enhancement. Further, would this not offer an alternative to email providers who make this feature a selling point (i.e. Proton and Tutanota)?

Keith, you said "stored locally", which sounds like you're referrring to "local folders" on your computer.
But then you also mention "email providers", which sounds like you want encryption for email that is stored on the provider's server?

IMHO, for encryption on your local computer, using hard disk encryption (as offered by the operating system) would be the straightforward solution.

If you're worried about the storage on the email provider's server, if an email was initially received without encryption, the provider already had a chance to make a plaintext copy of your email. And not just the provider, the admins of all intermediate transport computers, through which the plaintext email was routed, also had the ability. That means, adding encryption after transmission might not help much to keep your message confidential.

It only makes sense if you replace the mail on the remote storage with the encrypted copy via imap.
Sure the process isn't completely secure as there is still a window where the provider can get the cleartext but it is better than nothing so it becomes impossible to get data from the past and limit it to only recent incoming e-mails. Protecting data at rest and limiting exposure as best as we can is still a goal to pursue.

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

Keith, you said "stored locally", which sounds like you're referrring to "local folders" on your computer.
But then you also mention "email providers", which sounds like you want encryption for email that is stored on the provider's server?

IMHO, for encryption on your local computer, using hard disk encryption (as offered by the operating system) would be the straightforward solution.

If you're worried about the storage on the email provider's server, if an email was initially received without encryption, the provider already had a chance to make a plaintext copy of your email. And not just the provider, the admins of all intermediate transport computers, through which the plaintext email was routed, also had the ability. That means, adding encryption after transmission might not help much to keep your message confidential.

Yes, that is what I meant. Local as in on my computer. Should have been clearer.

Most of the content would be synced with IMAP to the providers servers. So while much would have never been emailed with them, the copies are there in their cloud. In the unlikely event of them being compromised, I was just wondering if Thunderbird could look after the encryption. Not quite zero knowledge encryption, but close if I could just use my PGP key.

It looks like implementing disk encryption will be the best solution at this stage for me. Going to start looking into gocryptfs for Debian 11.

(In reply to Selek Respa from comment #8)

It only makes sense if you replace the mail on the remote storage with the encrypted copy via imap.

Yes, that is what I would like to achieve, ideally.

Sure the process isn't completely secure as there is still a window where the provider can get the cleartext but it is better than nothing so it becomes impossible to get data from the past and limit it to only recent incoming e-mails. Protecting data at rest and limiting exposure as best as we can is still a goal to pursue.

Again, in an ideal situation, I would like to see some kind of "Zero-knowledge encryption" method without having to leave Thunderbird. I believe it would add significant value.

See Also: → 1836268

I am using GPG a long time and I am a little bothered that I cannot search in the last years in my emails.
I have now a lot of emails which are not decrypted. I had in 2020 the possibility in the filter to have an action that a message could be copied as decrypted message (Enigmail), which could be updated now.
My opinion is before you implement an automatic copy on getting an email there should be first a filter function be implemented to have the chance to decrypt old messages. This filter could be also be used for incoming mails.
My suggestion would be that all PGP Mails are decrypted, HTML/TXT, OPENPGP/MIME. There should be also a Condition in the filter "Encrypted Email" and "Not encrypted Email" to ease the use which wasn't available in the old implementation. The PGP Key is now in Thunderbird and no longer in Enigmail this should ease the thing.

Is there a chance to get this function and if yes when approximately? I would very appreciate this.

Flags: needinfo?(kaie)
See Also: → 135201
Duplicate of this bug: 1906781
See Also: → 297314
You need to log in before you can comment on or make changes to this bug.