3

If a hacker would manage to sign a certificate with a stolen (private) key of a CA and would remove or change the URL in the CRL Distribution Points extension, and later the certificate would be revoked by the CA, then how would a browser know the certificate has been revoked if the URL to the CRL is changed so that it links to an old or by the hacker generated CRL?

  • For that, you need to not only break (learn the private key) of the CA certificate, but also that of the authority which vouched for the CA. The two are the same only for self-signed (root) certificates, which are not what CAs actually use in day-to-day business. – Ben Voigt Dec 10 '15 at 21:09
  • At some point, the bad guy wins. No system is perfect. Once the breach is discovered, trust stores will be updated to exclude the exposed cert. That might take a day or two and people would be a little nervous using the internet until the patches come. This happened after Shellshock was exposed. – Neil Smithline Dec 10 '15 at 21:30
  • @NeilSmithline So, if I understand it correctly, the CRL Distribution Points extension on a certificate only really works when the certificate is obtained without the private key being compomised by the hacker, and otherwise a browser should make sure to update his root certificate list? – SWdV Dec 10 '15 at 21:36
  • I'm not an X.509 expert so I'm not 100% certain. That's why this is a comment and not an answer. If the attacker can forge a valid cert, they can set the CRL information to whatever they want so that they stay in control of it. I think that most, maybe all, popular browsers do not fail if they can't get a CRL. That is, they pass. And I'm pretty sure that Chrome totally ignores CRLs and OCSP. They have their own, IMO braindead, solution for cert revocations. – Neil Smithline Dec 10 '15 at 21:40
7

The location of the CRL for a specific certificate is embedded into the certificate itself and is visible for all which have access to the certificate, which is at least any client connecting to a server using this certificate. The location is put their by the issuer of the certificate (the CA), i.e. it is not included in the CSR (or gets replaced).

To have a different CRL in the certificate than the usual one the attacker needs to compromise the CA, i.e. the issuer of the certificate. It is true that the CA can not revoke the issued certificate then as long it has no access to the CRL location published in the certificate.

But again, making such a change to the certificate means that the attacker has compromised the CA. After such a compromise the CA itself must be revoked (or removed from the trust store in case of a root CA) which in effect invalidates all certificates issued by the CA, including the one certificate with the bad CRL location.

That's at least the theory. In practice some CA's are too big to fail and in this case fraudulent certificates actually gets inserted into the browsers trust store and explicitly marked as untrusted there. This process is outside the CRL/OCSP revocation checks.

  • Thanks for your answer! One question: why isn't the CRL Distribution Points extension on the certificate of the CA itself? Maybe a CA would be able to split op it's CRL? (I don't think this is done, though) – SWdV Dec 11 '15 at 21:06
  • 1
    @SWdV: A CA might decide to have multiple different CRL to limit the size of each CRL. Thus it might switch to a new CRL location after some number of issued certificates. – Steffen Ullrich Dec 11 '15 at 21:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.