An example of an e-mail signed with a revoked cert (which has an AIA extension with reference to an OCSP responder)
5.75 KB, text/plain
1.56 KB, application/x-x509-ca-cert
1.71 KB, patch
Robert Relyea: review+
Mike Schroepfer: approval1.8.1+
|Details | Diff | Splinter Review|
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.
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.
this is something we're going to be in a better position to tackle for Thunderbird 2.
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)
Created attachment 211368 [details] Root certificate corresponding to the message example (base64-encoded)
-> Kai for triage.
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.
this should be set mozilla1.8.1+ as dveditz had already set blocks-thunderbird-2+
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.
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.
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.
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.
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
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?
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.)
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.
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.
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
fixed on trunk
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.
Mscott - thoughts r.e. TBird for branch?
Yeah, we're interested in this on the branch for tbird. The code itself may be built by Firefox too though...
mscott: appropriate for 1.8.0.x now that there's a baked patch?
Comment on attachment 227655 [details] [diff] [review] Patch v1 this patch applies cleanly to 1.8.0 branch, requesting approval.
Comment on attachment 227655 [details] [diff] [review] Patch v1 approved for 1.8.0 branch, a=dveditz for drivers
checked into 1.8.0
verified regression on TB, version 184.108.40.206pre (20070402)
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.