482799 - S/MIME email that I received >1 year ago shows invalid signature, although it's valid

Status: NEW

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

Description

[Ben Bucksch (:BenB)]

Followup from bug 324474.

Reproduction:
1. Receive fully valid S/MIME email with valid signature.
2. Wait a year or two (or just take an old mail in step 1)

Actual result:
In step 1, signature is shown by Thunderbird to be valid.
After step 2, signature is shown by Thunderbird to be invalid.

Expected result:
Result matches in step 1 and 2. Signature stays valid.

Problem description:
This bug is a consciously accepted regression from bug 324474, but was only meant as short-term solution.
There are 2 problems here:
1. expiry
The sender's cert expired in the time between my email was sent and I am reading it again now a year later. Still, the signature was valid and therefore should still be shown as valid even a year later. The fact that the email was sent by the sender (which the signature is supposed to show) is now just as true as it was a year before.
2. Secure timestamp for send time.
To avoid the attacker getting around a revocation or reusing an old, long expired and meanwhile insecure cert for sending messages with valid certs now, we need a secure timestamp when the mail was sent.
The Date: RFC822 header can trivially be forged.
The signature can't provide this security, because we haven't yet established that the signature is valid.
So, we need to rely on Thunderbird recording the received time, and allow for a certain transmission time (a few seconds up to a 7-10 days), and assume a send time from that. This would prevent an attacker from reusing an insecure cert from 1998.
Only problem is to reliably keep that timestamp in face of computer and email program transitions, given that we're talking about years and decades here.

Importance:
Being able to verify signatures later is an important criteria for anything related to business, law, courts and taxes. People seriously using PKI are very concerned about such matters.

Comment 1

[Ben Bucksch (:BenB)]

Note: I have not tested this myself, as I don't have much testcases. The description is based on bug 471732

Comment 2

[Ben Bucksch (:BenB)]

Correction: bug 471723 comment 13.

Comment 3

[timeless]

could we do this:
when we download a message, create an envelope w/ our own signature, our own date stamp from now, the evidence that we used to authenticate the message, and enclose the message?

for imap, this'll only work if we can write back to the imap server....

that way we're signing the message w/ the data we have, using a signature we control and a format we control.

this seems to encapsulate the information we're trying to cover.

of course, it doesn't work when someone steals the user's signing key, but well..., that's kinda like the case where the thief breaks into an evidence room, you can't really trust anything anymore.

Comment 5

[Adriano Santoni]

It's quite worrying that this bug, open 10 years ago, is still unresolved and unassigned.
Does that mean that you believe this bug to be un-important?

Comment 6

[Ben Bucksch (:BenB)]

It's a design problem of the S/MIME standard and inherently very difficult to fix.

Comment 7

[Adriano Santoni]

Would you mind explaining what you believe is a design problem of the S/MIME standard, and why? 
Or, if you or anyone else already provided an explanation of such claim, please provide references.

Comment 8

[Joshua Cranmer [:jcranmer]]

There are a few issues with computing retroactive validity:

1. You need to know the actual date for which validity can be calculated. Getting a trusted date for the message origin can be difficult, as headers and other date fields can be forged. (The final Received header is known to be unforged, if you trust your MTA, which is a dubious entity to trust in the realm of S/MIME trust model; you can also have the MUA compute the first seen date, but we don't store this information at present).

2. CAs are empowered to drop mention of a revoked certificate from CRL or OCSP responses after the ValidBefore date. So you no longer know certificate revocation status, which massively opens up security holes, especially if the date-valid field can have some validity slack in it.

The only real solution is you have to cache the certificate validity check somewhere and keep displaying valid unless the failure reason shifts to "revoked certificate." We don't really have the architecture to store that validity check any place where we can reasonably guarantee that it will not be dropped, particularly for long-term archival scenarios which are the main motivation in the first place.

Comment 9

[Ben Bucksch (:BenB)]

> The only real solution is you have to cache the certificate validity check somewhere

Yes.

Thunderbird would validate on reception, then store the data and validity status and a hash of the message.

Then, Thunderbird would sign this store with a cryptographic key. The key doesn't need to match the user's public key, but can be a key created locally in the background specifically for this purpose. It may also have a longer validity period, given that no part of it is ever leaving the machine.

It becomes a problem when you migrate to a new machine. If you copy the Thunderbird profile, it should continue to work. But if you set up Thunderbird and your email account anew on the new computer and re-fetch messages from the IMAP server, then we lost that information.
We could theoretically store the database in a hidden folder on the IMAP server somewhere, but if you put your private key there, then there's not really any point, because the crypto is supposed to protect you against evil servers. So, that's a no-go.
Basically, once you set up a new Thunderbird profile, you've lost the history data that we need here for this bug.

Even if we accept this limitation, it's still a lot of development effort to create this signed database.

Comment 10

[Magnus Melin [:mkmelin]]

From bug 1509336 comment:
"The signing time is found in the standard 'signingTime' (OID 1.2.840.113549.1.9.5) authenticated attribute which is part of the signed information (along with the contentType and messageDigest)"

But regardless, since there can be corner cases as listed above, perhaps best that for old messages we'd show a status of "signed by now revoked|expired certificate" if you click open the security details. It could just show as unsigned in normal views. 

How often do anyone care about signatures in ancient mails? I'd assume that is quite unusual. I think it's important not to teach users that the errors can sometimes lie though. They should be able to trust that if it says invalid signature, it is an invalid signature and one one that may have been valid at one point in time.

Comment 11

[Ben Bucksch (:BenB)]

> The signing time is found in ... the signed information

Chicken and egg. The signing verification is there to check whether the signed information is authentic.
"You can trust me, I'm honest", says the fraudster.

> How often do anyone care about signatures in ancient mails? I'd assume that is quite unusual.

How often do you care about signatures on old paper? Quite often, e.g. for legal documents.
So, it depends on your use case why you use S/MIME in the first place. Private users, probably not. Business users, quite possibly. Lawyers and people working with contracts: All the time.

Comment 12

[Magnus Melin [:mkmelin]]

Doesn't sound like the lawyer/contract case is very supported now though (that's this bug). 

My point was that if you have a use case where you really need to verify the signature from an old mail, it seems reasonable that you would be willing to go through some more dialogs to see those details.
For a recently received message, the signature should protect you from acting on a fraudsters instructions, or sending them privileged info. Here the signing status is more important to show up front.

Comment 13

[Ben Bucksch (:BenB)]

> it seems reasonable that you would be willing to go through some more dialogs to see those details.

It's not a UI problem. The problem is an inherent problem of the security scheme, namely expiry. See above.

Comment 14

[Magnus Melin [:mkmelin]]

Wouldn't the parts that can be feasibly resolved be solved by the proposition in comment 10?

Comment 15

[Adriano Santoni]

(Replying to comment #13)
It's also an UI problem, as the message shown to the user when validating a once-valid signature totally misleading: "The certificate used to sign the message was issued by a certificate authority that you do not trust for issuing this kind of certificate" (see capture of the relevant dialog window in https://bugzilla.mozilla.org/show_bug.cgi?id=1509336). That message is totally wrong and confusing. If TB developers are not going to fix the real problem, please at least change the message to something reasonable such as "This signature was made with a certificate that is now expired". It would be bad to say "revoked|expired certificate" as the expiration is quite obvious to tell from revocation.

But, since it's so easy to extract the signing-time attribute from the S/MIME signature itself (always present when the signature is created by TB itself or by MS Outlook), it would be a small effort to use it for validating the signer's certificate even when it's expired, therefore being able to show a significant message as to the validity of the signature at the signing time.

Comment 16

[Ben Bucksch (:BenB)]

> It would be bad to say "revoked|expired certificate"

Magnus meant this to mean: Either "Revoked certificate" or "Expired certificate", depending on circumstance.

> as the expiration is quite obvious to tell from revocation

As Joshua explained in comment 8 point 8, it's not so easy (or even impossible) to tell apart.

Comment 17

[Joshua Cranmer [:jcranmer]]

(In reply to Magnus Melin [:mkmelin] from comment #10)
> From bug 1509336 comment:
> "The signing time is found in the standard 'signingTime' (OID
> 1.2.840.113549.1.9.5) authenticated attribute which is part of the signed
> information (along with the contentType and messageDigest)"

There is no requirement that signingTime be correct or even present. CMS and S/MIME both say that it's up to the client to decide how much to trust it, but both tend to hint that the client shouldn't trust it without out-of-band information.

Another way to look at the problem is to ask what the trust model is and what the consequences are for trusting signingTime. I suspect most people would agree that the general goal of (signed) S/MIME is to certify authorship of a message as being an individual rather than someone with access to the purported author's email account. A revoked key essentially means (among other possibilities) that an attacker can forge messages with the key. If the attacker waits until just after the certificate expires (and therefore no longer fail a revocation check), he can backdate the message slightly to give it the appearance of being valid, those failing the trust model. So signingTime cannot be trusted without other information.

(In reply to Ben Bucksch (:BenB) from comment #9)
> Thunderbird would validate on reception, then store the data and validity
> status and a hash of the message.
> 
> Then, Thunderbird would sign this store with a cryptographic key. The key
> doesn't need to match the user's public key, but can be a key created
> locally in the background specifically for this purpose. It may also have a
> longer validity period, given that no part of it is ever leaving the machine.

In my mind, Thunderbird's local store is considered trusted in terms of the threat model, so I don't think the cryptographic key is necessary. Unless someone were to configure an option to actually encrypt most of the backend data, which would include message contents and these kinds of security-critical databases.

Otherwise, this is basically the sort of scheme I had in mind. And, yeah, it has all the problems you mention… but there isn't any way to solve this problem without putting users in a worse security situation.

> Even if we accept this limitation, it's still a lot of development effort to
> create this signed database.

Hence why this bug is still around. :-)

Comment 18

[Ben Bucksch (:BenB)]

> In my mind, Thunderbird's local store is considered trusted in terms of the threat model, so I
> don't think the cryptographic key is necessary.

The Thunderbird profile contains executable XPIs with system rights, which can do whatever they want, including changing the signature display, so I guess what you say is true and signing the local store is not necessary. That makes implementation a lot easier. The database is still necessary to avoid the problems you mentioned.

I concur with the systemic problems you mentioned in comment 8 and comment 17 (right above). That implies that this needs more than just a little UI change. I was thinking of the same attack vectors. Thanks for explaining it nicely.

Comment 19

[Adriano Santoni]

Let me please remind that, to date, TB shows a misleading message upon an expired S/MIME certificate. If you have not noticed, when looking at an expired S/MIME certificate TB says that the signer's certificate was issued by a CA that the user does not trust. That is grossly wrong, and should be fixed right away with a more sensible message, regardless of any further considerations.

Second, although of course the signing-time cannot be regarded as reliable "a priori" (as it is not attested by a trusted third party), nonetheless is no less reliable than the email message's sending time, since both times can be manipulated by a malicious sender (but they are not, most of the times, otherwise email at large would not be The killing application). Therefore, there is no reason for TB to regard the signing-time with suspicion any more than there is reason to treat the same way the email message's sending time. Just clarify to the recipient, at UI level, that the validity of the signature is checked based on a presumptive signing date declared by the signer itself. Nobody is suggesting that TB should say anything more or different to the user. 

As to revocation checking: it would make sense to worry about the difficulty if today TB already did revocation checking on a not-yet-expired certificate - but it does not! (OCSP is disabled by default in TB). So why bother about how to check revocation of an expired certificate?

Comment 20

[Adriano Santoni]

Dear TB developers: any intentions to fix this bug?

Comment 21

[leszek.zablocki]

I created a test case with messages signed with an expired and renewed certificate. I have not tested messages signed with a revoked certificate. I investigated the behavior of the latest Thunderbird (version 128.0.1esr). Certificate expiration dates and message signing dates:

Certificates:
-------------
  ROOT
   Issued:  2000-01-01 00:00:00
   Expires: 2100-01-01 00:00:00
  |
   USER EXPIRED
    Issued:  2000-01-01 00:00:00
    Expires: 2024-01-01 00:00:00
  |
   USER RENEWED
    Issued:  2024-01-01 00:00:00
    Expires: 2048-01-01 00:00:00

Messages S/MIME:
----------------
 * signedData/expired_cert_01.eml
   signingTime: 1999-01-01 12:00:00

 * signedData/expired_cert_02.eml
   signingTime: 2000-06-21 12:00:00

 * signedData/expired_cert_03.eml
   signingTime: 2025-01-01 12:00:00

 * signedData/renewed_cert_01.eml
   signingTime: 2023-01-01 12:00:00

 * signedData/renewed_cert_02.eml
   signingTime: 2024-06-20 12:00:00

 * signedData/renewed_cert_03.eml
   signingTime: 2049-01-01 12:00:00

expired_cert_02.eml and renewed_cert_02.eml are technically correct. In this ticket, the problem is to display the correct status of the signed message when expired_cert_02.eml is opened. Th. now displays the following status:

The certificate used to sign the message was issued by a certificate authority that you do not trust for issuing this kind of certificate.

To add something relevant to this report, my suggestions:

• [expired cert expired_cert_02.eml] status [WARNING], see: bug#482799#c10, bug#482799#c15
• [revoked cert] status [INVALID], see: gpgsm ticket

See related ticket: bug#1912613, and package: smime_time_tests.tar.gz.

I also placed test emails from The Bat!, which are signed by external TSA. When Th. will handle timestamps the above statuses could look like the following (timestamped messages):

• [expired cert] status [VALID],
• [revoked cert] status [WARNING]

rfc5652 CMS

   No requirement is imposed concerning the correctness of the signing
   time, and acceptance of a purported signing time is a matter of a
   recipient's discretion.  It is expected, however, that some signers,
   such as time-stamp servers, will be trusted implicitly.

Of course, the time stamps are signed by TSA private key, TSA cert also have a validity period.

Comment 22

[leszek.zablocki]

Attachment: yellow_king.png