Closed Bug 1806161 Opened 2 years ago Closed 8 months ago

Thunderbird doesn't decrypt S/MIME encrypted message wrapped in a digital signature

Categories

(MailNews Core :: Security: S/MIME, defect, P2)

Thunderbird 102

Tracking

(thunderbird_esr128 fixed, thunderbird128 affected)

RESOLVED FIXED
129 Branch
Tracking Status
thunderbird_esr128 --- fixed
thunderbird128 --- affected

People

(Reporter: KaiE, Assigned: KaiE)

References

Details

(Whiteboard: tb-crypto-interop)

Attachments

(1 file, 1 obsolete file)

This bug is similar as bug 1594253, but for the reverse scenario.

If the second MIME layer (1.1) of an email is an S/MIME encrypted message, and the outermost MIME layer (1) is a digital signature (either S/MIME or OpenPGP), then Thunderbird doesn't decrypt.

This behavior was originally intentional (because of the EFAIL attacks), but it would make sense to allow this scenario as an exception.

However, I haven't yet seen any reports that support for this message structure is necessary, so this bug is a low priority.

Summary: Thunderbird doesn't decrypt S/MIME encrypted message wrapped in a digital signature (e.g. sent through Gmail/G Suite) → Thunderbird doesn't decrypt S/MIME encrypted message wrapped in a digital signature

I was told, this kind of message is indeed ocurring in the wild.

If a user sends an S/MIME encrypted message with the google suite, then the service adds another S/MIME signature around it.

Sigh.

Any ideas when this will be actioned on?
I am still having to kick off a VM with windows just to read those 3-4 emails that I get from those guys, and it is a tad ugly
thanks
Maurizio

I know this is a P5 but is there any update? yet as to how this could be resolved?

Hi All, any news on this?

Flags: needinfo?(kaie)

Any news on this @Kai?

See comment 0 "this bug is a low priority.", and there is no indication that this assessment has changed. Sorry, but there are higher priority issues.

Version: unspecified → Thunderbird 102

I think it would be good to get this fixed, and allow Thunderbird to access the contents.
Given that we now have confirmed these messages appear in the wild in production systems (as opposed to my initial theory that they might not), I think we should have a look.

Unfortunately I don't yet know how soon we might be able to fix it.

Flags: needinfo?(kaie)
Priority: P5 → P3
Whiteboard: tb-crypto-interop
Priority: P3 → P2

Hi All, any news on this now that it is a P2?
thanks
Maurizio

I am closing the https://bugzilla.mozilla.org/show_bug.cgi?id=1771981 as it is a clone of this, which I raised a while back but this is now in process with the right terminologies.

Duplicate of this bug: 1771981

Maurizio, I know you said in the other bug that these message contain sensitive information and that you cannot share them.

Regardless, we must find a way for me to see the specific structure of these messages.
The screenshots you had provided still leave some ambiguity.

In an ideal world, Thunderbird would implement processing and UI similar to what Kmail offers, as shown in your screenshot, but I don't think it will happen any time soon.

The best I can do is to implement an exception, similar to what has been already done in bug 1594253.

Maybe you could do the following:

  • view a sample message in Thunderbird, and use file save as, save it to an .eml file
  • open the file with a text editor
  • in the header section (before the first empty line), you may remove all lines except the ones that start with "content"
  • then you have sections that contain encoded data blocks, lots of random characters. You may remove those completely, maybe replace every block with the word {redacted data}

After these preparations, your message should no longer contain any sensitive data.
It would be great if you could share this redacted message with me, maybe be email, kaie@kuix.de (please zip it before you attach the file, to ensure it won't be corrupted by email systems).

I'm guessing that your message looks like the the following example, but to ensure I produce fix that works for you, I'll need to see the structure of your data.

Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms090309070804040602040609"

--------------ms090309070804040602040609
Content-Type: application/pkcs7-mime; name="smime.p7m"; smime-type=enveloped-data
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7m"
Content-Description: S/MIME Encrypted Message

{redacted data}

--------------ms090309070804040602040609
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

{redacted data}
--------------ms090309070804040602040609--

I have an initial experimental patch.
I'll provide an experimental test binary, based on version 115.x, later today.

Maurizio, please test the following builds. Can you use Windows 64 bit or Linux 64 bit?

Assuming you are already using Thunderbird 115, you can use these builds with your usual profile.
Execute the archive to a fresh folder, then open a terminal, then "cd" to the directory containing this build, then use
./thunderbird -P
to get a prompt on startup that allows you to select the profile you wish to use.

Please test the scenario reported in this bug, but also test other S/MIME emails you have received, to ensure they still behave as expected.

Linux 64bit:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/ATPvf7NPTNuKxF3E4Owtbg/runs/0/artifacts/public/build/target.tar.bz2

Windows 64bit:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/PxM59mnQT2a3JNeuvzn-rw/runs/0/artifacts/public/build/target.zip

(From this build:
https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=88f91f7fcd1f794209d45e28af8ba95634501e17 )

Flags: needinfo?(mgarzelli)

Hello Kai,
I am so sorry for the delay of this message! I had a huge amount of personal stuff to deal with and this went a bit in the backburner.

I have tested it and it works!! the build that you have attached here does complain about the signature BUT it works! I have compared the versions: I made sure that I opened an email that previously was giving me the smime.m7p attachment and then opened the same with the other (from your link) and it worked, it opened the email.
For your info, the 'normal thunderbird' that I use (which has the problem) is on linux and is 115.5.0 and I see that the daily is 115.4.2 (and it works).
the linux I am using now is Garuda (based on Arch)
Thank you
Maurizio

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

Maurizio, please test the following builds. Can you use Windows 64 bit or Linux 64 bit?

Assuming you are already using Thunderbird 115, you can use these builds with your usual profile.
Execute the archive to a fresh folder, then open a terminal, then "cd" to the directory containing this build, then use
./thunderbird -P
to get a prompt on startup that allows you to select the profile you wish to use.

Please test the scenario reported in this bug, but also test other S/MIME emails you have received, to ensure they still behave as expected.

Linux 64bit:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/ATPvf7NPTNuKxF3E4Owtbg/runs/0/artifacts/public/build/target.tar.bz2

Windows 64bit:
https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/PxM59mnQT2a3JNeuvzn-rw/runs/0/artifacts/public/build/target.zip

(From this build:
https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=88f91f7fcd1f794209d45e28af8ba95634501e17 )

Flags: needinfo?(mgarzelli)
Assignee: nobody → kaie
Attachment #9361460 - Attachment description: WIP: Bug 1806161 - Ignore outermost s/mime signature layer, if the second layer is s/mime encryption. → Bug 1806161 - Ignore outermost s/mime signature layer, if the second layer is s/mime encryption. r=mkmelin
Status: NEW → ASSIGNED

Thanks Maurizio for the feedback.
I was distracted by the many other things going on, but let's try to get this into the new yearly version.
I've updated the patch and asked for a code review.

Because Magnus asked questions about the general approach, I'd like to explain the approach, and the justification for the suggested implementation, in more detail here in bugzilla.

S/MIME message always use nesting (as of today), two separate MIME levels, when combining signature and encryption.
(S/MIME doesn't offer the combined encoding that's available in the OpenPGP world.)

That means, for those messages, there are two possible scenarios for structuring:
(1) outer MIME layer is encryption, inner MIME layer is signature,
(2) outer MIME layer is signature, inner MIME layer is encryption.

Using (1) is a best practice.

Using (2) is considered undesirable, there are associated risks. You cannot know if the signer really was the person who had sent the message, the signer might have been unable to read that message.

Because of the EFAIL attacks, it had been decided to simply ignore all messages with that structure.
That's what Thunderbird currently implements.
When we process such a message, we show an empty message.

In the past, we didn't anticipate that (2) could appear in legitimate scenarios.
The scenario is the one reported in this bug, where the outer signature wasn't added by the author, but by a MTA.

While the MTA signature might have some benefit in some scenarios, I think the presence of such a signature isn't a sufficient reason to block users from being able to read the message.
I think it's acceptable to make an exception, but only under the following precondition: The outer signature is completely ignored, and not reported at all.

The patch suggests to do that, and to process the message starting from the second MIME layer, completely ignoring the outermost layer.

If the author had originally added a signature using the best practice approach (1), then we'll see (and process) the signature at the third MIME layer.

Regarding Magnus' question:

We have existing tests that use messages of structure version (2).
Currently the tests check that we indeed treat those message as "not encrypted", because we reject the inner encryption layer.
For completeness, our tests check that we see a signature, because that's what we see on the outside.

With the new strategy we cannot keep those tests unchanged.
If our new strategy is to ignore the outermost signatures of messages structured like (2), then we must change all existing tests that have this structure.

My patch suggests to change the test's expectations.
In those existing scenarios, because there's only an outermost signature layer, but no further inner signature layer, the tests no longer see a signature being available (it's now ignored).
We now expect to find encrypted data, because we no longer ignore the encryption layer in those scenarios.

I've started a final try build, to ensure things still work as expected:
https://treeherder.mozilla.org/jobs?repo=try-comm-central&revision=134b22e8246ae1f31cc8f6416801e75be9b5da03

If that try build looks good, feel free to add the checkin-needed keyword.

I talked to dkg about this scenario.
He suggested it might be worthwhile to publish an RFC draft to generally describe the kind of wrapping we are experiencing in the wild, and our approach to it.
That might be a good idea, but how much time would that take me and is it worth to spend that time?
(Given there is an ever present shortage of time for the many tasks that are waiting to be done.)

I assume this will land after the merge of 128 to beta.
Can we uplift it to Beta immediately?

Flags: needinfo?(vseerror)

Comment on attachment 9361460 [details]
Bug 1806161 - Ignore outermost s/mime signature layer, if the second layer is s/mime encryption. r=mkmelin

[Approval Request Comment]
Regression caused by (bug #): no
User impact if declined: encrypted message contents cannot be accessed by user
Testing completed (on c-c, etc.):
Risk to taking this patch (and alternatives if risky): medium

Attachment #9361460 - Flags: approval-comm-beta?

Pushed by kaie@kuix.de:
https://hg.mozilla.org/comm-central/rev/deb8f3cc8125
Ignore outermost s/mime signature layer, if the second layer is s/mime encryption. r=mkmelin

Status: ASSIGNED → RESOLVED
Closed: 8 months ago
Resolution: --- → FIXED
Target Milestone: --- → 128 Branch

Comment on attachment 9361460 [details]
Bug 1806161 - Ignore outermost s/mime signature layer, if the second layer is s/mime encryption. r=mkmelin

[Triage Comment]
Approved for beta.
Noting - the patch has tests

I assume this will land after the merge of 128 to beta.
Can we uplift it to Beta immediately?

This will make next Monday's beta.

Kai, you mention medium risk. What things should we watch out for?

Flags: needinfo?(vseerror) → needinfo?(kaie)
Attachment #9361460 - Flags: approval-comm-beta? → approval-comm-beta+

The risk would be limited to people using S/MIME, with some messages being rendered differently.

Flags: needinfo?(kaie)

I hope it doesn't happen. I'm just stating that potentially it could happen, and I cannot rule it out completely.

Blocks: 1902603

Comment on attachment 9407723 [details]
Bug 1806161 - Enable prepared test files for Outer-S/MIME-sig-with-inner-S/MIME-encryption. r=mkmelin

Revision D213879 was moved to bug 1902603. Setting attachment 9407723 [details] to obsolete.

Attachment #9407723 - Attachment is obsolete: true

If this landed on 128, the status should be "fixed".

It landed on merge day, 10 June 2024 after the merge.

Target Milestone: 128 Branch → 129 Branch

Kai, do we want this in 128?

Flags: needinfo?(kaie)

(In reply to Corey Bryant from comment #29)

Kai, do we want this in 128?

yes please

Flags: needinfo?(kaie)

Comment on attachment 9361460 [details]
Bug 1806161 - Ignore outermost s/mime signature layer, if the second layer is s/mime encryption. r=mkmelin

[Approval Request Comment]
Regression caused by (bug #): not a regression
User impact if declined: cannot access the content of some emails
Testing completed (on c-c, etc.):
Risk to taking this patch (and alternatives if risky): I had explained the risk already, but we haven't gotten any negative feedback so far. I think it's worth uplifting to 128.

Attachment #9361460 - Flags: approval-comm-esr128?

Comment on attachment 9361460 [details]
Bug 1806161 - Ignore outermost s/mime signature layer, if the second layer is s/mime encryption. r=mkmelin

[Triage Comment]
Approved for esr128

Attachment #9361460 - Flags: approval-comm-esr128? → approval-comm-esr128+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: