CRL over HTTPS: is it really a bad practice?

Question

On the Internet, I can find several statements done over the years claiming that serving a X.509 CRL over HTTPS is a bad practice because either

1. it causes a chicken-and-egg problem when checking for the TLS certificate and
2. it is simply a waste of resources, given that the CRL is by definition signed by a CA, and a non-confidential artifact.

However:

1. The recommended alternative is OCSP (possibly combined with the various types of stapling). However OSCP responses are also signed by a revocable entity, whose status needs to be checked too, so I don't understand how that solves the chicken-and-egg problem. Perhaps, there isn't actually any chicken-and-egg problem if we assume the PKI design takes into account the need to avoid circular dependencies for status checks.

2. CRLs are signed, but they still don't provide replay protection within the period of validity of the CRL itself. In other words, you cannot reliably issue an emergency update to the CRL before its period of validity ends, because a powerful attacker can realistically manipulate all outgoing plain HTTP requests, and replace the new emergency CRL with the old one for that period. HTTPS would at least prevent that up to a point.

I read also that certain implementations simply refuse to retrieve CRLs over HTTPS (Microsoft): that might be a pragmatically good reason to avoid it. However, in that way, we are also perpetuating a questionable practice.

Am I mistaken somewhere?
Isn't it time to revisit the prejudice against distributing CRLs over HTTPS? That considering that there is a strong HTTPS-only trend ongoing and it is not unreasonable to predict that HTTP only requests might be blocked at the network level in certain environments.

Answer 1

I generally agree with Steffen Ulrich, I just want to add few cents, since OP references my own answer which I consider proper and valid.

However OSCP responses are also signed by a revocable entity

it's not a revocable entity. OCSP Signing certificates include id-pkix-ocsp-nocheck certificate extension that instructs clients to not check this particular certificate for revocation. Often, OCSP signing certificates don't include CDP (CRL Distribution Points) or AIA (OCSP access method) extensions in certificate. This trick removes egg and chicken problem for OCSP signing certificate.

CRLs are signed, but they still don't provide replay protection within the period of validity of the CRL itself.

that's correct. But this problem isn't solved within current X.509 profile. There are no means to provide immediate revocation response (i.e. immediately detect if particular certificate is revoked). Revocation infrastructure heavily relies on caching and even stappled OCSP response may not be very up-to-date, there may be newer responses, but server hasn't obtained it yet and use cached OCSP response to staple in TLS. As Steffen said, the only way to improve this experience is to use short-lived CRLs/OCSP responses and use clients that support CDP polling to detect if there is newer CRL than the one stored in local cache on a client.

I read also that certain implementations simply refuse to retrieve CRLs over HTTPS

Microsoft CryptoAPI behaves exactly this way in terms of CDP extension. It won't even try to connect to an URL with HTTPS scheme. It will fail the URL if server requests TLS negotiation. Don't know about other crypto frameworks, so this statement may not be applicable to other tools.

As a bottom line: I still don't see much useful reasons to implement CDP over HTTPS. CRLs is a publically distributable content -- no reason for content privacy. It is digitally signed -- no reason for extra signing. The fact that MiTM can modify CRL content over plain HTTP to purposely invalidate CRL signature isn't mitigated by TLS. MiTM can arbitrarily tamper TLS traffic to force client to reject tampered data. Same effect in both cases: denial of service and TLS doesn't solve this problem.

What can be reasonable -- to hide your activity history from men on a wire (e.g. your ISP), but yet questionable.

Answer 2

... chicken-and-egg problem ...

There is no real chicken-and-egg problem. Revocation (no matter if CRL or OCSP or something else) is only one part of the certificate validation, and it can still be better to do 95% (i.e. HTTPS w/o revocation check) than doing 0% (plain HTTP).

... don't provide replay protection ... you cannot reliably issue an emergency update to the CRL before its period of validity ends ...

While HTTPS helps against replay of an old CRL by an attacker it does not make sure that the new CRL actually reaches the client. An attacker can still simply deny the connection and from the perspective of the client it is fine since the old CRL is still valid. Thus HTTPS is not the method to allow emergency updates to a CRL either. Apart from that the client might not even check for an update if the current CRL is still valid. The correct mechanism here would be to use shorter expiration times.

Note: see the excellent answer from Crypt32 for a more deeper explanation with more technical details.

Answer 3

TLS/HTTPS clients do normally cache the results of OCSP/CRL requests. When a client sends a request to CA and establishes an HTTPS connection, most of the time it uses cached result of certificate validation. That's why no recursion occurs, no chicken-egg problem. Of course the client should consider the cases when cache result is not available or expired and should prevent recursion. In such case the client uses an HTTPS connection based on a certificate that was not validated. But this has absolutely the same security as a plain HTTP connection, and only in this case HTTPS has no advantage compared to HTTP.

If you use HTTP for OCSP/CRL, then any party that can read your traffic (internet provider, any proxy servers on the way) can see what certificates were requested, when, in what order, and thus can get insights about your browsing history. If you use HTTPS, then only the CA knows what certificates have you requested. Thus using of HTTPS does make sense.

TLDR:

1. Naive answer on Microsoft site is not correct. Dealing with recursion is trivial. RFC 2580 remembers to keep this in mind: Relying parties ... MUST be prepared for the possibility that this will result in unbounded recursion.
2. The chicken-egg scenario does not cause any real problem because of caching of OCSP/CRL results and because dealing with recursion is trivial.
3. Using HTTPS does make sense because it hides your browsing history.

Answer 4

I also agree with Steffen Ulrich, but I could see it from Microsoft's perspective. And no, I don't work for Microsoft nor asked any of their employees.

Suppose an attacker can be MitM. Possible attacks?

• Via HTTP: tha attacker can replay an old CRL and have the victim think that the certificate is still valid. The victim won't notice the differrence and accept a revoked certificate
• Via HTTPS: the attacker can deny connection, but the client can become aware (and suspicious) of this, but the attacker at this point cannot necessarily serve a valid old CLR
• Via HTTPS: if and only if the attacker has pwned the TLS key they can set up a MitM that responds with an old CLR. And falls again in the http case

So from my point of view https helps making the attack more complicated. A certificate gets revoked not only when the key is being actively used by someone else.

Answer 5

As root policy file is some script HTTPS URL to link to internal IIS server for copy of root certificates as crt and crl. On other according to Microsoft paperwork crt or crl must be empty. Not sure what is exactly needs to presented.