Revoked S/MIME certificate difficult to detect in received messages

RESOLVED FIXED in mozilla1.8.1

Status

MailNews Core
Security: S/MIME
P1
major
RESOLVED FIXED
11 years ago
8 years ago

People

(Reporter: Michael Hallquist, Assigned: kaie)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, {verified1.8.0.8, verified1.8.1})

1.8 Branch
mozilla1.8.1
verified1.8.0.8, verified1.8.1
Dependency tree / graph
Bug Flags:
blocking1.8.0.2 -
blocking1.8.0.8 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:high] spoof [kerh-bra])

Attachments

(3 attachments)

(Reporter)

Description

11 years ago
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

11 years ago
declassifying
Group: security
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.
Assignee: dveditz → bienvenu
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8.0.2?
Flags: blocking-thunderbird2+
Whiteboard: [sg:high] spoof

Comment 3

11 years ago
this is something we're going to be in a better position to tackle for Thunderbird 2.
Flags: blocking1.8.0.2? → blocking1.8.0.2-

Comment 4

11 years ago
Created attachment 211367 [details]
An example of an e-mail signed with a revoked cert (which has an AIA extension with reference to an OCSP responder)

Comment 5

11 years ago
Created attachment 211368 [details]
Root certificate corresponding to the message example (base64-encoded)

Comment 6

11 years ago
-> Kai for triage.
Assignee: bienvenu → kengert

Comment 7

11 years ago
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.  

(Assignee)

Updated

11 years ago
Attachment #211368 - Attachment mime type: text/plain → application/x-x509-ca-cert
(Assignee)

Updated

11 years ago
Severity: normal → major
Component: Security → Security: S/MIME
Flags: blocking-thunderbird2+
OS: Windows XP → All
Priority: -- → P1
Product: Thunderbird → Core
Hardware: PC → All
Whiteboard: [sg:high] spoof → [sg:high] spoof [kerh-bra]
Target Milestone: --- → mozilla1.8.1
Version: unspecified → 1.8 Branch
(Assignee)

Comment 8

11 years ago
this should be set mozilla1.8.1+ as dveditz had already set blocks-thunderbird-2+
Flags: blocking1.8.1?
(Assignee)

Comment 9

11 years ago
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.
(Assignee)

Comment 10

11 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Flags: blocking1.8.1?
Resolution: --- → INVALID
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.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
(Assignee)

Comment 12

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

Comment 13

11 years ago
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

11 years ago
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
(Assignee)

Comment 15

11 years ago
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?
(Assignee)

Comment 16

11 years ago
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.)
(Assignee)

Comment 17

11 years ago
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.
(Assignee)

Comment 18

11 years ago
Created attachment 227655 [details] [diff] [review]
Patch v1

This patch causes signature verification to fail if the cert is no longer valid at the current time.
Attachment #227655 - Flags: review?(rrelyea)
(Assignee)

Updated

11 years ago
Blocks: 157555

Comment 19

11 years ago
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
Attachment #227655 - Flags: review?(rrelyea) → review+
(Assignee)

Comment 20

11 years ago
fixed on trunk
Status: REOPENED → RESOLVED
Last Resolved: 11 years ago11 years ago
Resolution: --- → FIXED
(Assignee)

Comment 21

11 years ago
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.
Attachment #227655 - Flags: approval1.8.1?

Comment 22

11 years ago
Mscott - thoughts r.e. TBird for branch?

Comment 23

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

Updated

11 years ago
Attachment #227655 - Flags: approval1.8.1? → approval1.8.1+
(Assignee)

Updated

11 years ago
Keywords: fixed1.8.1
mscott: appropriate for 1.8.0.x now that there's a baked patch?
Flags: blocking1.8.0.8?
Flags: blocking1.8.0.8? → blocking1.8.0.8+
(Assignee)

Comment 25

11 years ago
Comment on attachment 227655 [details] [diff] [review]
Patch v1

this patch applies cleanly to 1.8.0 branch, requesting approval.
Attachment #227655 - Flags: approval1.8.0.8?
Comment on attachment 227655 [details] [diff] [review]
Patch v1

approved for 1.8.0 branch, a=dveditz for drivers
Attachment #227655 - Flags: approval1.8.0.8? → approval1.8.0.8+
(Assignee)

Comment 27

11 years ago
checked into 1.8.0
Keywords: fixed1.8.0.8

Comment 28

10 years ago
verified regression on TB, version 2.0.0.0pre (20070402)
Keywords: fixed1.8.0.8, fixed1.8.1 → verified1.8.0.8, verified1.8.1

Comment 29

8 years ago
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.
QA Contact: thunderbird → s.mime

Updated

8 years ago
Depends on: 482799

Updated

8 years ago
Component: Security: S/MIME → Security: S/MIME
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.