[SSL Observatory] Diginotar broken arrow as a tour-de-force of PKI fail

[Rob Stradling]

This year, we've seen 2 types of approach to revocation:

1. "Normal" revocation (CRLs and OCSP Responses published by the CAs).
2. "Emergency" revocation (Certificate Blacklists published by the Browsers).

Comodo-gate: All 9 of the mis-issued certificates were promptly marked as 
"revoked" in CRLs and in OCSP Responses within a few hours of being issued.  
All of the attacker's movements were sufficiently logged, resulting in the CA 
being confident that no other certificates were mis-issued to the attacker.  The 
compromised application-level account was quickly suspended.  The incident was 
disclosed to the major Browser Vendors promptly.
In short: The CA regained control, the CA didn't lose the trust of the Browser 
Vendors, and "Normal" revocation should have been enough to ensure that end-
users were not left vulnerable to MITM attacks.
But instead, the Browser Vendors had to resort to "Emergency" revocation 
because the "Normal" revocation mechanisms could have been subverted by the 
attacker in various different ways.

DigiNotar-gate: Numerous certificates were mis-issued, not promptly detected 
and not promptly marked as "revoked" in CRLs and in OCSP Responses.  The CA 
failed to log what happened, failed to disclose the incident for many weeks, 
and couldn't be sure that they'd identified every cert that the attacker had 
mis-issued.
In short: The CA completely lost control, lost the trust of the Browser 
Vendors, and relying on "Normal" revocation would've been like rearranging 
deckchairs on the Titanic.  "Emergency" revocation was absolutely necessary.

So I think we need both types of revocation, but they both need to work better 
than they currently do.
"Normal" revocation needs to be improved so that it is sufficient in cases where 
the CA regains control.
"Emergency" revocation needs a more coordinated, scalable approach.  (See [1] 
for some thoughts from PHB and me).

On Friday 16 Sep 2011 09:28:56 Peter Gutmann wrote:
<snip>
> For example given that an attacker who compromises a CA can add their own
> AIA to the fraudulent certs it mints that point to an attacker-controlled
> responder with another fraudulent cert that "authenticates" any response (or
> simply leave out the AIA, so there's no responder to check), it doesn't
> matter what the rest of the infrastructure does.

Perhaps this would be classed as a scenario from which the CA cannot regain 
control.  And if so, it wouldn't be a problem that "Normal" revocation would 
need to consider.

<snip>
> I would really like to see a proper threat model for this.

I realize I probably haven't achieved that with this post.

> What are we defending against?

State-level attackers.  And we should expect them to persist in their efforts.


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=685286 (the "Proposal for 
establishing an emergency response format based on OCSP and DNS/CAA" 
attachment)


Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online