324474 - Revoked S/MIME certificate difficult to detect in received messages

Status: RESOLVED FIXED

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

Description

[Michael Hallquist]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

When I receive an email message from an individual who has used a revoked S/MIME certificate to sign the message (in this case, I have Thunderbird download the CRL from Thawte's Freemail Issuing CA), Thunderbird indicates that the message contains a valid signature. I recognize that a valid signature also signifies that the content of the message hasn't been changed, which may be how Thunderbird determines a signature validity. Nevertheless, I would like Thunderbird to give a clear indication that the certificate has been revoked, which should cast doubt on the authenticity/security of the message.

At this point, the only way to see information about revokation is through the certificate manager or by clicking the signature icon in the message window and then clicking "View Certificate" in the Message Security window.

Reproducible: Always

Steps to Reproduce:
1. Import relevant CRL into Thunderbird (e.g., http://crl.thawte.com/ThawtePersonalFreemailIssuingCA.crl)
2. Receive message from individual using a revoked S/MIME certificate
3. Message displays as validly signed.

Comment 1

[timeless]

declassifying

Comment 2

[Daniel Veditz [:dveditz]]

Could you attach such a message here? It would make it easier to test for volunteer QA who don't have access to their own CA service. You can copy the message to a new mail folder, and then attach the whole folder to the bug.

Comment 3

[Scott MacGregor]

this is something we're going to be in a better position to tackle for Thunderbird 2.

Comment 4

[Peter Lind Damkjaer]

Attachment: An example of an e-mail signed with a revoked cert (which has an AIA extension with reference to an OCSP responder)

Comment 5

[Peter Lind Damkjaer]

Attachment: Root certificate corresponding to the message example (base64-encoded)

Comment 6

[Bob Lord]

-> Kai for triage.

Comment 7

[Bob Lord]

Overall, I was able to reproduce the problem after I added a From header to the example email. The message was shown as valid after I trusted the test root.

However, someone needs to run the ocsp client to make sure that the cert in question really is revoked.  

Comment 8

[Kai Engert (:KaiE:)]

this should be set mozilla1.8.1+ as dveditz had already set blocks-thunderbird-2+

Comment 9

[Kai Engert (:KaiE:)]

I can reproduce this bug.
Our NSS ocsp client tools report this cert as being revoked.
The UI must not report this message as having a valid signature.

Comment 10

[Kai Engert (:KaiE:)]

I no longer think this is a bug.

OCSP responses contain a revocation timestamp.

The cert used to sign the attached message has been revoked, indeed.

But the signature of the attached message has been produced earlier.

Ww check whether the cert has been valid at the time the signature was made. At that time the cert was valid.

Comment 11

[Daniel Veditz [:dveditz]]

Thought experiment:
 - bad guy steals my cert (trojan key logger?)
 - bad guy sends forged mail on my behalf
 - two weeks later I discover the forged mail and revoke my cert
result:
 two week's worth of forged mails are still valid?

I don't think that's what people expect to happen when they revoke their certs. Now it does suck that all my old mail would suddenly be suspect, but I'm not really sure how long the forgeries have been going on.

Do OSCP services let you back-date a revocation, or is the revocation time the time you notified the CA? Reopening pending clarification of this scenario.

Comment 12

[Kai Engert (:KaiE:)]

cc'ing crypto people for opinions on comment 9 and comment 10.

Comment 13

[Bob Lord]

Revocation takes place as of a specific time.  So if you go to your issuer and say "my key was stolen last week", the issuer can choose to mark the cert as revoked as of last week, or as of now.  If it revokes the cert as of last week, all real email (and spoofed email) sent afterwards will show up as invalid. 

Comment 14

[Julien Pierre]

Unfortunately, we don't have a secure timestamp source to authenticate the email signature time.
The most reliable timestamp we have is the time that the email client downloaded the message. We know that the signature can't have been created after that. But generally post-dating isn't the issue - back-dating is.
The client could also make some assumptions about transit time, and assume that the email couldn't have been in transit more than, say, a week before receiving it, and therefore any timestamps older than that are suspicious.

Without the addition of secure timestamps or the above logic based on receiving date, the email client could consider the revocation reason and treat some cases differently.
 
If no trusted timestamp is available, and the reason for the cert revocation is that the key has been compromised, it may be preferable to treat the certificate as revoked from day one, since anybody would be able to created backdated messages.

For other revocation reasons, the risk of receiving backdated messages is lower, and thus it might be OK to just trust the email timestamp. 

The main problems with the above are :
- lack of secure email timestamp today
- how to implement the proposed logic based on receiving time
- the fact that our OCSP client just gives a binary yes/no response to its caller, and doesn't expose the revocation reason through the current API

Comment 15

[Kai Engert (:KaiE:)]

Short term (ff/tb 2) I don't think we'll be able to implement the smarter UI.

My conclusion is, there is currently room for our application to display false positives (signature shown in UI as good, although produced by an attacker).

One could argue that showing false negatives is better (showing invalid status for good signatures, because the signature could potentially have been produced using a timestamp fake).

If we decide to switch to false negatives, the mail application could treat all signatures of revoked certs as invalid, regardless of revocation/signing time.

Should we stop doing potentially false positives, and switch to potentially false negatives?

Comment 16

[Kai Engert (:KaiE:)]

We would like to switch the behaviour short term for TB 2.

We would like to switch to the "false negatives" approach as explained in the previous comment.

(At a later time we might want to present smarter UI, explaining the doubts.)

Comment 17

[Kai Engert (:KaiE:)]

Now that we decided what we want, we need to discuss: At what code location should this be changed.

It appears, the Mozilla application code (PSM) is not able to influence the good/bad S/Mime signature decision.

We call NSS API function NSS_CMSSignedData_VerifySignerInfo, which goes on to NSS_CMSSignerInfo_VerifyCertificate, which always uses the message signing time for it "already revoked" decision.

So one approach could be to introduce new APIs that offer the caller to ignore the signing time, and let any revocation time indicate an invalid signature.

But introducing new NSS APIs is not an appropriate short term solution for FF 2.

So let's if we have sufficient exported functionality to do something else at the PSM level.

Comment 18

[Kai Engert (:KaiE:)]

Attachment: Patch v1

This patch causes signature verification to fail if the cert is no longer valid at the current time.

Comment 19

[Robert Relyea]

Comment on attachment 227655 [details] [diff] [review]
Patch v1



I'm not sure we have the semantics right on the corner cases.

Validating against the message time Seems most reasonable. For Email we can be our own time stamp validator (did we receive this email close to the current time? then accept the email's time).

Revocation time should be marked from the point of loss, as bob lord pointed out.

Summary. We do not do any time validation when we receive the email currently, so we can't implement the above.

since revocation is rare, having false negatives is better then not getting revocation notice on a spoofed email with a back time stamp.

r=relyea

Comment 20

[Kai Engert (:KaiE:)]

fixed on trunk

Comment 21

[Kai Engert (:KaiE:)]

Comment on attachment 227655 [details] [diff] [review]
Patch v1

I propose to land this patch on the branc, we just check an additional scenario that causes signature verification to end, and it suppresses a potential spoof.

Comment 22

[Mike Schroepfer]

Mscott - thoughts r.e. TBird for branch?

Comment 23

[Scott MacGregor]

Yeah, we're interested in this on the branch for tbird. The code itself may be built by Firefox too though...

Comment 24

[Daniel Veditz [:dveditz]]

mscott: appropriate for 1.8.0.x now that there's a baked patch?

Comment 25

[Kai Engert (:KaiE:)]

Comment on attachment 227655 [details] [diff] [review]
Patch v1

this patch applies cleanly to 1.8.0 branch, requesting approval.

Comment 26

[Daniel Veditz [:dveditz]]

Comment on attachment 227655 [details] [diff] [review]
Patch v1

approved for 1.8.0 branch, a=dveditz for drivers

Comment 27

[Kai Engert (:KaiE:)]

checked into 1.8.0

Comment 28

[Tony Chung [:tchung]]

verified regression on TB, version 2.0.0.0pre (20070402)

Comment 29

[Ben Bucksch (:BenB)]

According to comment 16, the solution here was only short-term, but no follow-up bug was filed. See also bug 471723 comment 13. I filed that now as bug 482799.