1697252 - receiver can't decrypt mail if (auto-)saved as draft before switching from PGP to S/MIME

Status: RESOLVED FIXED

(MailNews Core :: Security: OpenPGP, defect)

Description

[MD-Work]

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

Steps to reproduce:

1. Set up an email account with OpenPGP and S/MIME.
2. for "Preferred encryption technology" choose either "automatic" or "OpenPGP".
3. open a new mail
4. click "Save" (as Draft) or wait until automatic saves occurs
5. add the receivers address, a topic and some message text
6. switch "Encryption Technology" from "OpenPGP" to "S/MIME"
7. optional: chose "Do Not Encrypt"
8. send the message

You can also do step 4 before step 3.
In all cases the result is the same.

Actual results:

The message gets send encrypted with the senders OpenPGP key only.
The switch to S/MIME is totally ignored.

In none of the described scenarios the message gets correctly encrypted with the receivers S/MIME or even PGP key.
Even when choosing S/MIME and disabling encryption the message still gets encrypted with the senders PGP key.

There's also no warning if Thunderbird doesn't have a PGP or S/MIME key for the sender at all.

Only when you stay with OpenPGP everything works fine.

Expected results:

The mail should be either encrypted with S/MIME or not being encrypted at all.

Comment 1

[MD-Work]

Slightly related:

Allow saving of unsafe draft of an encrypted mail if no key of the recipient is available (S/MIME)
https://bugzilla.mozilla.org/show_bug.cgi?id=1419233

Draft saving, S/MIME, OpenPGP, identities, should be more consistent
https://bugzilla.mozilla.org/show_bug.cgi?id=1661254

Comment 2

[MD-Work]

P.S.
Also all changes made after (auto)-save will be lost!

The mail will be send the way it was when the (auto)-saving it.

Comment 3

[MD-Work]

One more thing:
In step 2 ("Preferred encryption technology") you must also enable "Require encryption by default".

Alternatively the bug also appears if you manually switch to OpenPGP and "Require encryption" before saving the email.

Comment 4

[Wayne Mery (:wsmwk)]

Christian, any ideas?

Comment 5

[Christian Riechers]

I can't exactly re-test this because I don't have a S/MIME cert. These certs aren't free anymore.
What I don't understand, why would anyone want to save a blank message, without entering a recipient email, subject, or body text?

Anyway, I did do that, and prior to saving the blank draft I manually turned on OpenPGP encryption for it.
Then entering a recipient email, turned off encryption, and sent the message without saving it again prior to sending.
The message was sent unencrypted. So this works for me.

Tested with TB 89.0b1 64-bit on Linux.

Comment 6

[MD-Work]

(In reply to Christian Riechers from comment #5)

I can't exactly re-test this because I don't have a S/MIME cert. These certs aren't free anymore.

Just create a CA yourself and import it into Thunderbird.
(That's actually what the 20 persons company I'm working for did. Because a lot of our customers require S/MIME encryption. Nevertheless, internally we prefer OpenPGP which brings up this bug for us.)

Alternatively you may try CAcert.org.
https://en.wikipedia.org/wiki/CAcert.org

 

What I don't understand, why would anyone want to save a blank message, without entering a recipient email, subject, or body text?

It's just one way to reproduce this bug. You can also put in receiver, subject and body text before saving the draft.
The important thing is to make changes after saving the draft.

 

Anyway, I did do that, and prior to saving the blank draft I manually turned on OpenPGP encryption for it.
Then entering a recipient email, turned off encryption, and sent the message without saving it again prior to sending.
The message was sent unencrypted. So this works for me.

Switching encryption off is optional.
7. optional: chose "Do Not Encrypt"

The important step is to switch from OpenPGP to S/MIME.
That's why you didn't see the bug.
6. switch "Encryption Technology" from "OpenPGP" to "S/MIME"

Comment 7

[Christian Riechers]

(In reply to MD-Work from comment #6)

Just create a CA yourself and import it into Thunderbird.

That would ultimately mean a self-signed root cert, which all correspondents need to import into Thunderbird.

Alternatively you may try CAcert.org.

Their root CA cert is not part of the Firefox (and hence Thunderbird) certificate store, so Thunderbird can't verify the entire certificate chain.
https://www.ssllabs.com/ssltest/analyze.html?d=www.cacert.org&s=213.154.225.245
Again, all correspondents need to import the root cert.
Neither of the two seem suited for either personal use or in a business environment to me, and I have no intention to try them.
Whether this is related to your problem or not I don't know.

You may want to check whether there's anything related in the error console.
Also see https://wiki.mozilla.org/Thunderbird:OpenPGP#Debugging_.2F_Tracing

Comment 8

[MD-Work]

Attachment: Thunderbird console output and enigdbug.txt

@Wayne
Sorry to bother you again.
I guess this ticket needs to be handled by someone with more S/MIME experience.

Could you direct this to someone who's using S/MIME?
Maybe someone who's doing S/MIME development for Thunderbird?

Or at least someone who is experienced in handling X.509 certificates.
For testing purposes a self-signed or CACert certificate could be imported into a testing Thunderbird profile.
(so the testers normal Thunderbird profile may not be bothered)

 
 

I also attached the output of the Thunderbird console and enigdbug.txt

The first getCryptParams parameters call in the Thunderbird console is when saving the mail as draft.

The second getCryptParams parameters call is when the mail is actually being and should be encrypted as S/MIME instead.
So the second getCryptParams parameters call is clearly wrong. But I can't get an idea why this is happening.

Comment 9

[Wayne Mery (:wsmwk)]

Hopefully one of these can help.

Comment 10

[:Cykesiopka]

Unfortunately I can't provide any useful information since I don't use PGP or S/MIME myself and at this point basically don't know anything about the Thunderbird code base.
Sorry I can't be more helpful.

Comment 11

[Christian Riechers]

I found a computer where Thunderbird is set up for both, OpenPGP, and S/MIME encryption.
I can confirm the behavior as per the description in comment #0.

Comment 12

[Kai Engert (:KaiE:)]

I can reproduce, too. Investigating...

Comment 13

[Kai Engert (:KaiE:)]

This is a regression that was introduced by bug 1683701 in TB 78.8.0

Reverting the patch from bug 1683701 fixes the regression.

Comment 14

[Kai Engert (:KaiE:)]

Your patch for bug 1683701 had missed that gMsgCompose.compFields.composeSecure may carry an object of two alternative types, either a type used for S/MIME sending, or a type used for OpenPGP sending. It seems the patch permanently overwrites the object used for sending S/MIME messages, so the message will be sent as OpenPGP, regardless of other flags.

Comment 15

[Kai Engert (:KaiE:)]

Attachment: Bug 1697252 - Fix S/MIME use after OpenPGP draft saving. Reverts most of bug 1683701, except the part that fixed the problem. r=mkmelin

Comment 16

[Kai Engert (:KaiE:)]

Attachment: 1697252-backport-esr78.patch

backported patch for esr78.

This fixes a functional regression and is reverted code, so should be safe.

[Approval Request Comment]
Regression caused by (bug #): 1683701
User impact if declined: incorrectly encrypted message sent, unreadable by recipient
Testing completed (on c-c, etc.):
Risk to taking this patch (and alternatives if risky): low

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/0e79fc3477a8
Fix S/MIME use after OpenPGP draft saving. Reverts most of bug 1683701, except the part that fixed the problem. r=mkmelin

Comment 18

[Wayne Mery (:wsmwk)]

Comment on attachment 9223533 [details] [diff] [review]
1697252-backport-esr78.patch

[Triage Comment]
Approved for esr78

Comment 19

[Rob Lemley [:rjl]]

Thunderbird 78.11.0:
https://hg.mozilla.org/releases/comm-esr78/rev/0131bc9750b0