- it causes a chicken-and-egg problem when checking for the TLS certificate and
- it is simply a waste of resources, given that the CRL is by definition signed by a CA, and a non-confidential artifact.
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.
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.