Closed Bug 1854592 Opened 2 years ago Closed 2 years ago

Thunderbird version 115 treats an S/MIME signature as invalid (e.g. from a PEC certificate) if the signature used SHA-1

Categories

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

Product:
MailNews Core
Component:
Security: S/MIME
Version:
Thunderbird 115
Type:
defect

Tracking

(thunderbird_esr115+ fixed, thunderbird119 affected)

Status:
RESOLVED FIXED
Milestone:
120 Branch
Tracking Flags:
Tracking Status
thunderbird_esr115 + fixed
thunderbird119 --- affected

People

(Reporter: stefano.baldoni, Assigned: KaiE)

References

(Regression,
URL
)

Details

(Keywords: regression)

Attachments

(3 files, 1 obsolete file)

380933509_688954456595560_8401805793201081335_n.jpg
349.38 KB, image/jpeg
Details
eml requiered.
16.17 KB, application/octet-stream
Details
Bug 1854592 - Introduce a pref to optionally accept S/MIME message signatures that use SHA-1. r=mkmelin
48 bytes, text/x-phabricator-request
wsmwk
: approval-comm-esr115+
Details | Review

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

Steps to reproduce:

Updating to version 115 the PEC (posta elettronica certificata certified electronic mail) certificates from italian providers are unkown or not recognized by the client. That it is a real issue because is used by lawyers for work anche this kind of email have legal value thanks to that certificates

Actual results:

the update to version 115 created the problem

Expected results:

Unkown

Expected reults: same beahviuor of previous versions

Can you attach a sample, as .eml?

Component: Untriaged → Security: S/MIME
Keywords: regression
Product: Thunderbird → MailNews Core
Attached file eml requiered. —

the certifacate is shown good with previuos TB versions

Any news? Did the 115.3.1 solve the problem?

It it using SHA-1? xref bug 1843526

I confirm the same behaviour, Thunderbird 115.3.1 on Linux MInt 21.2 x86_64. Italian PEC s/mime supports SHA-1 and SHA-256

Errata corrige: SHA-1 is mandatory, SHA-256 optional.... I think the problem is the same of bug 1843526 (closed).

If they don't fix the bug, as I suppose, In Italy we have to switch to other email clients at least for PEC. If thunderbird support decides that sHA-1 is not valid, they should consider that in EU Contries it is valid. Another piece of outsourcing died.

Kai, maybe we need to re-do bug 1532292. Back out perhaps.

Though ideally perhaps it should be shown as not signed, and the info page could explain the situation.

Flags: needinfo?(kaie)
See Also: → 1532292, 1843526

(In reply to Davide Vernè from comment #7)

Errata corrige: SHA-1 is mandatory, SHA-256 optional.... I think the problem is the same of bug 1843526 (closed).

Yes, it is: they're interested only in U.S. laws, perhaps... not user friendliness!

(In reply to stefano baldoni from comment #8)

If they don't fix the bug, as I suppose, In Italy we have to switch to other email clients at least for PEC. If thunderbird support decides that sHA-1 is not valid, they should consider that in EU Contries it is valid. Another piece of outsourcing died.

In https://bugzilla.mozilla.org/show_bug.cgi?id=1843526 I've suggested that TB should carry on such activities:

  1. effectively check and compare with historically valid hash algos always; then
  2. report if hashes do not match (invalid signature) or
  3. report if they match (valid sig.), and warn the user about the circumstance that used hash algo is no more considered safe (issuing a mere warning).

But this logical, clear, verbose, complete, historical and graduated approach isn't conformant to the "maximum technical security" spirit at Mozilla...

(In reply to maxpat78 from comment #11)

(In reply to stefano baldoni from comment #8)

If they don't fix the bug, as I suppose, In Italy we have to switch to other email clients at least for PEC. If thunderbird support decides that sHA-1 is not valid, they should consider that in EU Contries it is valid. Another piece of outsourcing died.

In https://bugzilla.mozilla.org/show_bug.cgi?id=1843526 I've suggested that TB should carry on such activities:

  1. effectively check and compare with historically valid hash algos always; then
  2. report if hashes do not match (invalid signature) or
  3. report if they match (valid sig.), and warn the user about the circumstance that used hash algo is no more considered safe (issuing a mere warning).

But this logical, clear, verbose, complete, historical and graduated approach isn't conformant to the "maximum technical security" spirit at Mozilla...

If the want Thunderbird be user only in the USA it's their choice, we cannot force for sure. But life is full of compromise :-)

Comment #11:

This is a good solution. see bug1847703#c7. The same applies to encryption: 3 message statuses OK (green), OK but/however/! (yellow), not OK (red). And described exactly why such a status was displayed. Very detailed information in 2 clicks.

One day, maybe some other status for AEAD (AES-GCM/ChaCha20-Poly1305). bug#1835697.

see: OpenHashTab, statuses: Unknown, Match, Mismatch, Insecure, Error.

Th. is a cryptographic program, so to speak.

Duplicate of this bug: 1859221

(In reply to Magnus Melin [:mkmelin] from comment #9)

Kai, maybe we need to re-do bug 1532292. Back out perhaps.

I'd prefer to not backout.

From https://en.wikipedia.org/wiki/SHA-1 :
"NIST formally deprecated use of SHA-1 in 2011 and disallowed its use for digital signatures in 2013, and declared that it should be phased out by 2030.[14] As of 2020, chosen-prefix attacks against SHA-1 are practical."

For an example, look at the following two documents:

If someone create a digital signature using SHA-1 on document 1, the signature could be reused with document 2, and trick people into thinking that document 2 was signed.

Though ideally perhaps it should be shown as not signed, and the info page could explain the situation.

Users are looking for a solution for 115.

While there is discussion ongoing, for potentially (in the future) no longer showing any user interface for emails with invalid signatures, we couldn't easily bring this behavior to the 115 release. Furthermore, I believe that the reporters wouldn't like the signature status to be completely dropped either.

An alternative suggestion has been suggested in this bug, something like a "weaker" signature status being shown, a combination of showing "this has a valid signature" but at the same time explaining "be careful with this signature because it is weak".

As of today, we don't have support for explaning this different "signature quality" in the user interface. It also wouldn't be trivial to bring this detail to the 115 stable releases. (It would require developing new/modified UI and strings, and backporting to 115.)

I don't want to fully reject the idea to show a different "signature quality" in the UI. However, given we don't have this implemented right now, I think it wouldn't be used as a short term solution for 115.

I could think of a different solution, that would be easier to implement.

We could introduce a preference, for users who need more time until they can distrust signatures based on SHA-1.

The preference could be called e.g. "smime_signatures_accept_insecure_sha1", by default set to false, and users could set it to true.

Flags: needinfo?(kaie)

Reporters:

You should request that the senders of messages with S/MIME signatures based on SHA1 should urgently migrate to a newer version of their software that can create SHA256 or better signatures, or make the required configuration changes to their existing software to enable its use.

Where can I find the intermediate CA certificates necessary to validate the attached sample email?

I could think of a different solution, that would be easier to implement.

We could introduce a preference, for users who need more time until they can distrust signatures based on SHA-1.

The preference could be called e.g. "smime_signatures_accept_insecure_sha1", by default set to false, and users could set it to true.

This is an interesting solution, if UI changes can't be implemented in future/backported.
Professionals needing such secured mail transports should have sufficient skills to manipulate TB prefs.

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

Reporters:

You should request that the senders of messages with S/MIME signatures based on SHA1 should urgently migrate to a newer version of their software that can create SHA256 or better signatures, or make the required configuration changes to their existing software to enable its use.

That is not so easy, since we are talking here about EU laws and legal procedures.

Secured mail or other documents digitally signed using SHA-1 in the past will survive, legally speaking, for many years after 2030... and so the need for checking them.

Acts, contracts, documents... formed in the past can't be simply swept away because of technical innovation (sure, regulators should never have imposed such mechanisms, but this is another story).

Let's clarify the scope.

Are we talking about new emails, that are sent in the year 2023 or later?
I think it's very unfortunate if software in the year 2023 still uses SHA-1 when signing,
I would hope that all maintained applications should offer the use of SHA256 or newer in their latest released version.

Or - are we talking about old emails only?
Are you concerned about emails that were sent e.g. in the year 2022, or which are even older?
Is your request to accept SHA-1 for signatures LIMITED to old emails?

In theory, Thunderbird could have a rule to treat SHA-1 signatures differently, based on the date on which an email was sent.
If an email was sent in the past (before a cutoff date), then still allow SHA-1 signatures. If the message was sent after the cutoff date, then never accept SHA-1 signatures.

With this potential approach you have the risk that an adversary could backdate a message to trick someone, and get a SHA-1 signature accepted.

Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Thunderbird version 115 not recognize PEC certificate → Thunderbird version 115 not a S/MIME signature (e.g. from a PEC certificate) because the signature used SHA-1
Summary: Thunderbird version 115 not a S/MIME signature (e.g. from a PEC certificate) because the signature used SHA-1 → Thunderbird version 115 treats an S/MIME signature as invalid (e.g. from a PEC certificate) if the signature used SHA-1

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

Let's clarify the scope.

Are we talking about new emails, that are sent in the year 2023 or later?
I think it's very unfortunate if software in the year 2023 still uses SHA-1 when signing,
I would hope that all maintained applications should offer the use of SHA256 or newer in their latest released version.

Or - are we talking about old emails only?
Are you concerned about emails that were sent e.g. in the year 2022, or which are even older?
Is your request to accept SHA-1 for signatures LIMITED to old emails?

As i suggested in my bug report #1859221:

  1. use "secure" algorithms when createing a signature

  2. if an received email has a signature made by a "secure" algorithm: behaviour as is

  3. if an email has a signature made with "unsecure" algorithms: validate the signature
    3a. if it is valid: tell the user that the signature is valid but uses an "unsecure" algorithm / adding a yellow "!" to the SMIME-icon
    3b. if it is invaild: behavious as is

Think about non it-affine users that panic whenever a "red warning" shows up. Especially when a previously "OK" email
suddenly turns "red" after an upgrade of TB.

This would also kind of be inline with RFC 8551 Appendix B where handling of historic emails is discussed.
See https://datatracker.ietf.org/doc/html/rfc8551#appendix-B

Regards Christian

PS: By the way MS Office 2019 Outlook using Exchange Online still produces SHA-1-SMIME-Signatures today.

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

Are we talking about new emails, that are sent in the year 2023 or later?
Or - are we talking about old emails only?
We are talking about both, old and new.

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

Where can I find the intermediate CA certificates necessary to validate the attached sample email?

I found it at https://github.com/AgID/ca-agid-ca1

Assignee: nobody → kaie
Status: NEW → ASSIGNED
Duplicate of this bug: 1859115

While there is discussion ongoing, for potentially (in the future) no longer showing any user interface for emails with invalid signatures...

is that discussion?

bug#1780423 comment 16

😅

Keywords: checkin-needed-tb

Magnus, do you agree this patch has no change of behavior if the pref is kept at the default value?

If we agree on that, maybe we could expedite uplifting to esr115 ?

Should we get another review to get another re-confirmation of the safety of this change, to give release management more confidence in quickly approving an uplift?

Flags: needinfo?(mkmelin+mozilla)

Correct. It's essentially a preffed backout so no risk.

Flags: needinfo?(mkmelin+mozilla)

Please note that there is a better way to get a simple pref value in C++ code:
https://searchfox.org/comm-central/search?q=mozilla%3A%3APreferences%3A%3AGetBool&path=&case=false&regexp=true

Pushed by kaie@kuix.de:
https://hg.mozilla.org/comm-central/rev/db1c15ced123
Introduce a pref to optionally accept S/MIME message signatures that use SHA-1. r=mkmelin

Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Keywords: checkin-needed-tb
Resolution: --- → FIXED
status-thunderbird119: --- → affected
tracking-thunderbird_esr115: ? → +
Target Milestone: --- → 120 Branch
Pushed by kaie@kuix.de: https://hg.mozilla.org/comm-central/rev/b1d832078b98 Fix an ambiguity warning by adding () to the if condition, and run lint. r=bustage

Reopening.

This triggers a crash in debug builds. It seems we aren't allow to query preferences from a secondary thread - still investigating.

If true, we'll probably need to query the pref from some global init code on the main thread, and set a static variable that the secondary threads can query.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---

We've decided to backout and work on a new patch.

What I had assumed as being a simple change, turned out to require more careful C++ code, because we aren't allowed to query preferences from secondary threads.

Attachment #9358897 - Attachment description: Bug 1854592 - Introduce a pref to optionally accept S/MIME message signatures that use SHA-1. r=mkmelin → WIP: Bug 1854592 - Introduce a pref to optionally accept S/MIME message signatures that use SHA-1.

Most of the work by Kai Engert. Added proxying getting pref to the main thread.

Attachment #9358897 - Attachment description: WIP: Bug 1854592 - Introduce a pref to optionally accept S/MIME message signatures that use SHA-1. → Bug 1854592 - Introduce a pref to optionally accept S/MIME message signatures that use SHA-1. r=mkmelin

You can switch this to
bool allowSha1 = mozilla::Preferences::GetBool("mail.smime.accept_insecure_sha1_message_signatures", false);

D191203: Please also switch in mimemcms.cpp.

Attachment #9359279 - Attachment is obsolete: true
Keywords: checkin-needed-tb

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/bbcbc8fb145c
Introduce a pref to optionally accept S/MIME message signatures that use SHA-1. r=mkmelin

Status: REOPENED → RESOLVED
Closed: 2 years ago → 2 years ago
Keywords: checkin-needed-tb
Resolution: --- → FIXED

Comment on attachment 9358897 [details]
Bug 1854592 - Introduce a pref to optionally accept S/MIME message signatures that use SHA-1. r=mkmelin

[Approval Request Comment]
Regression caused by (bug #): 1532292
User impact if declined: Users cannot work around Thunderbird's rejection of SHA1 in S/MIME signatures
Testing completed (on c-c, etc.):
Risk to taking this patch (and alternatives if risky): low, because there is no default change in behavior, and the optional behavior is the behavior we used in the past, and we have tests for both configurations

Attachment #9358897 - Flags: approval-comm-esr115?
Regressed by: 1532292

Comment on attachment 9358897 [details]
Bug 1854592 - Introduce a pref to optionally accept S/MIME message signatures that use SHA-1. r=mkmelin

[Triage Comment]
Approved for esr115

Attachment #9358897 - Flags: approval-comm-esr115? → approval-comm-esr115+
Duplicate of this bug: 1843526
See Also: → 1860646

A blog post has been published to inform about this issue and the new opt-in:
https://blog.thunderbird.net/2023/10/thunderbird-115-and-signatures-using-the-obsolete-sha-1-algorithm/

Duplicate of this bug: 1859633
Duplicate of this bug: 1856961
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: