4

I'm new to SSL/TSL and was wondering if you could walk me through the following scenario.

Scenario

Let's say I am one of a thousand websites that has a certificate signed by some certificate authority (CA).

Everything is fine.

Breach

Then, some evil hacker steals the CA's private key. Now, all of a sudden, all thousand website's certificates are untrustworthy because the hacker can issue certificates signed with the stolen private key and one can't distinguish between real and fake certificates anymore.

The CA revokes his stolen certificate, so I end up with a website that no browser recognizes as trustworthy anymore.

Mitigation

What do I do now? I've read these questions:

Now, I got to run and get a new certificate signed by a still trusted CA.

Question

Therefore, I was wondering: what should I have done in advance so that once the CA's private key is stolen, I don't have to run, but can lean back and don't have to worry about it?

Should I have a second certificate ready which was signed by another CA which I can deploy once the other one gets untrustworthy?

Can my old certificate be simultaneously signed by a second CA so that it stays valid even if one CA's private key is compromised?

What mitigation scenarios are there?

Real cases

The question came up after reading these cases:

Community
  • 1
Lernkurve
  • 1,134
  • 3
  • 9
  • 10

2 Answers2

2

A stolen CA private key is a bad situation indeed. Response depends on the extent of the breach, and the context.

First, it may be so that the CA private key was not exactly stolen, but merely used improperly. For instance, in the case of the Comodo event, the compromise was on Registration Authority accounts. The RA is the component who tells to the CA what to put in certificates; the RA is the part that actually maps physical identities to the physical world. In that case, the CA key was not stolen, and though certificates with wrong contents were issued, the CA still had reliable knowledge of all issued certificates. It thus sufficed to revoke the fake certificates themselves, not the CA. This is the good case, where damage is contained.

If the CA key was used and there is no reliable way to have an exhaustive list of the fake certificates, or it the CA private key was actually stolen and is now under control of the attacker, then the corresponding certificate will need to be revoked. This is done not by the CA itself, but by its upper CA.

Then, to repair all the honest sites who just "disappeared" through such revocation, a new CA can be installed, and automatically emit new certificates for all the previous clients (this assumes that we still have all the issued "honest" certificates somewhere). It suffices to copy the identities and names from the old certificate to the new one.

For business reasons, it may be negotiated to delay the compromised CA revocation until the new CA and new customer certificates have been created and deployed. There is not a lot of margin for that, though.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
2

A plan of action for this is to have regular monitoring and auditing performed on all requests.

A little about how SSL CAs work (source: Fox-IT Post Breach of DigiNotar)

Current browsers perform an OCSP check as soon as the browser connects to an SSL protected website through the https-protocol3. The serial number of the certificate presented by the website a user visits is send to the issuing CA OCSP-responder. The OCSP-responder can only answer either with "good", "revoked‟ or "unknown". If a certificate serial number is presented to the OCSP-responder and no record of this serial is found, the normal OCSP-responder answer would be „good‟4. The OCSP-responder answer "revoked" is only returned when the serial is revoked by the CA.

TL;DR: If no serial is found => Good, if Serial is revoked => Revoked

With proper monitoring in place this could have been identified at a much faster interval and a incident response plan could have gone in place to show a certificate as revoked when it was not found within the CA OCSP-responder.

And here is what the IR plan included (source: again from the Post Breach)

In order to prevent misuse of the unknown issued serials the OCSP-responder of DigiNotar has been set to answer "revoked" when presented any unknown certificate serial it has authority over. This was done on September 1st. The incident response sensor immediately informs if a serial number of a known fraudulently issued certificate is being misused. Also, all unknown serial number requests can be analysed and used in the investigation. All large number of requests to a single serial number is suspicious and will be detected.

More or less this says that they put in place monitoring and auditing that should have been in place from the beginning, and that it would have been identifiable through a SIEM solution as to what occurred or what was occurring.

If you want to read the whole thing: https://www.eff.org/deeplinks/2011/09/post-mortem-iranian-diginotar-attack

m3r1n
  • 171
  • 4