25

I noticed that at least one major CA (Comodo) publishes their CRL over HTTP rather than HTTPS.

This seems to me to be somewhat of a vulnerability, as an attacker could hijack the HTTP connection that seeks to download the CRL and when HSTS is in use at the very least execute what effectively amounts to a DoS attack on the domain. (Because with HSTS active, browsers should not allow the user to bypass the invalid certificate warning; see RFC 6797 section 8.4 and section 12.1.)

While CRLs are normally signed, and it would seem that any sane implementation should reject a signed CRL that does not pass signature validation, I haven't seen any way to determine the signer of the CRL in any web browser, so even signing a replacement CRL with your own root certificate key appears to be a relatively low-risk operation. And this of course assumes that the browser requires that the CRL is signed in the first place; if not, you can just replace it with a non-signed CRL. (And of course, if the implementation does reject a signed CRL that fails signature validation, or even non-signed CRLs, it becomes trivial to trick the UA into using a certificate that has been revoked but which has not yet reached its expiration date.)

Is this an actual potential problem? What checks are normally performed by UAs with regards to CRLs to prevent it from becoming an actual problem?

Community
  • 1
user
  • 7,700
  • 2
  • 30
  • 54
  • 3
    And how would you verify the certificate for the server that serves the CRL? And then how would you verify the certificate for the site where you looked that up, etc? It's a chicken-and-egg problem. – Moshe Katz Nov 11 '14 at 19:50

3 Answers3

31

There is no such thing as a non-signed CRL; the signature field is mandatory, and any system that uses the CRL will verify the signature.

In pure X.509, a CRL will be deemed "acceptable" as a source of information about the revocation status of a given certificate E if it is signed by an "allowed revocation issuer": the CRL's signature must match the public key contained in an already validated certificate, whose subjectDN is equal to the issuerDN of E (you can have a distinct DN if E contains the relevant CRL distribution point extension and the CRL has a matching Issuer distribution point extension; but let's forget this additional complexity). Complete rules are exposed in section 6.3. Note that "pure X.509" is supposed to work in the context of the Directory, the kind-of worldwide LDAP server that references everything under unambiguous Distinguished Names.

Since the Directory does not really work, because it does not, as it were, exist at all, existing implementations tend to implement stricter and simpler rules. Generally speaking, a Web browser validating a certificate E issue by CA C will accept a CRL only if it is also signed by the same CA, with the same key. This rule keeps path validation simple and bounded (otherwise, you may imagine a situation where you must get a CRL for each certificate in the path, and each CRL is to be verified against another CRL issuer certificate that requires its own path validation, and so on). Therefore, producing your own CRL relatively to your own root CA is unlikely to have any actual effect.

CRL, like certificates, are thus objects which are always signed, and never used without verifying that signature(*), so they can be served over plain HTTP. Using HTTPS to serve CRL is just wasted resources; it may even prevent CRL download from working since some implementations (e.g. Windows) refuse to follow HTTPS URL when validating certificates (be it for CRL, OCSP, or extra intermediate CA download), because that would mean SSL, then another certificate to validate, and possibly an endless loop.

(*) I here exclude root CA "certificates", traditionally self-signed; these are not real certificates in the X.509 sense, but only objects that mimic the encoding rules of certificates.

Community
  • 1
Tom Leek
  • 170,038
  • 29
  • 342
  • 480
  • 6
    Very interesting answer, could you clarify one additional thing: how CRL's are protected from replay attacks? If they are not mitm attacker could provide old CRL to user and allow himself to use revoked certficates (used sees CRL from point of time when certificate was not revoke yet)? – jb. Nov 08 '14 at 23:25
  • 2
    A CRL contains a field called `thisUpdate` that documents its age. It also contains a (theoretically optional, but in practice always there) field called `nextUpdate` that specifies a date at which a newer CRL will be available; all implementations use `nextUpdate` as a CRL expiration date. – Tom Leek Nov 09 '14 at 13:56
  • 1
    Do you have reference documentation for the statement "since some implementations (e.g. Windows) refuse to follow HTTPS URL when validating certificates (be it for CRL, OCSP, or extra intermediate CA download)" ? – JRL Dec 04 '15 at 17:10
  • @JRL: I read it on some documentation on MSDN, but I do not have the reference on hand. At one point, I tested it explicitly (but such things may change over time, depending on the whims of Microsoft). – Tom Leek Dec 07 '15 at 14:39
  • 1
    @Tom: thanks for the update. Still trying to locate that documentation. If I find it I'll post it. – JRL Dec 07 '15 at 23:29
  • Might it be problematic if a domain serving a CRL over HTTP was also covered by an HTTP Strict Transport Security policy (HSTS)? For example: imagine example-ca.com uses HSTS with includeSubdomains and is in preload lists. A client could be confused by the conflicting instructions if asked to fetch http://crl.example-ca.com/a.crl over HTTP (non-TLS). A smart client should probably not comply with HSTS when fetching CRLs, but should the CA refrain from using an HSTS policy that covers a domain used for CRLs? – Andre D May 28 '16 at 00:25
  • The MS Technet post that references this, made by an MS MVP in 2009. https://social.technet.microsoft.com/Forums/windowsserver/en-US/f8a6a4f0-2b2c-4d14-b27d-f160b78d3125/http-or-https-for-external-crl-location?forum=winserversecurity – David Hergert Aug 29 '17 at 21:52
11

About the replay attack, the CRL is time stamped with the date of generation and a date for the next update. The nextUpdate date is mandatory in the PKIX profile. If a certificate is revoked, the old CRL can be replayed before nextUpdate if an unsecure channel is used.

Community
  • 1
ysdx
  • 976
  • 6
  • 15
0

I'd just like to add that some (at least) Mozilla browsers have a configuration variable: security.OCSP.require (please see IRL about:config) that is, by default, set to false.

It seems that if security.OCSP.require is set to "false", the browser should fall back to verifying the CRL at the named CRL distribution point URI, which is coincidentally the same URI used in the Authority Information Access field where presumably the signature of the CA and the CRL would be found.

Empirically (at least in in Linux) if this URL is blocked, at least Mozilla browsers (Firefox, Sea Monkey, Chrome) will pass the certificate without verification as to whether it has been revoked and replaced.

I'm having trouble understanding how this would not be a vulnerability but that wasn't the crux of the original question.

FYI: In Windows, the CRL and OCSP settings appear to be a function of Group Policy (Local Computer Policy, Computer Configuration, Windows Settings, Security Settings, Public Key Policies), and may be configured, but at least as of Windows 2003 don't seem to be configured by default. On Mac's, this could be further mitigated by Keychain, for those inclined to trust a 3rd-party with their passwords....

Eric G
  • 9,701
  • 4
  • 31
  • 59
Cookie's Staff
  • 9
  • 1