Why CRL and OCSP URLs use HTTP?

Why CRL and OCSP URLs use HTTP?

From Digicert
The CRL's and also the OCSP responses are signed by CA's such as DigiCert.

This means any kind of manipulation will already be detected even if the CRL or OCSP response is transferred using an insecure transport.

Thus the protection against tampering which is offered by HTTPS is not needed.

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 wasted resources; it may even prevent CRL download from working since some implementations (e.g. Windows), does not use HTTPS URL when validating certificates (be it for CRL or OCSP), because that would mean SSL, then another certificate to validate, and possibly an endless loop.

Also we can add these
There are a few reasons for this:
1. Performance: CRLs can be quite large, and downloading them over an encrypted HTTPS connection would slow down the certificate validation process and consume more network bandwidth.
2. Trust: The purpose of a CRL is to verify that a certificate has not been revoked. For this, it's sufficient to use an unencrypted HTTP connection, as the list itself does not need to be protected from eavesdropping or tampering.
3. Scalability: HTTPS requires a relatively high overhead for establishing and maintaining a secure connection, which can be a burden for large-scale deployments. 

Allowing HTTP is still more secure than not checking a certificate validation and connecting to HTTPS website which has Revoked certificate. 

There are a few risks associated with using HTTP instead of HTTPS for publishing Certificate Revocation Lists (CRLs):
1. Eavesdropping: Because HTTP connections are not encrypted, anyone who is able to intercept network traffic between the client and server can see the contents of the CRL, including the list of revoked certificates. This could potentially compromise sensitive information, such as the names and identities of revoked certificates.
Is domain name sensitive info? 
2. Tampering: Similarly, an attacker who is able to intercept and modify the CRL can present a false list of revoked certificates to the client, which could potentially allow them to bypass certificate validation and establish a trusted connection to a rogue server.
Falsely trusted if tampered (Probability?) = Never validated & override (All the time) 
Which one is worse?
3. Man-in-the-middle attacks: Because HTTP does not provide server authentication, it's possible for an attacker to impersonate the CRL server and present a fake CRL to the client. This could potentially allow the attacker to bypass certificate validation and establish a trusted connection to a rogue server.
Falsely trusted if tampered (Probability?) = Never validated & override (All the time) 
Which one is worse?
And
The reason OCSP operates over HTTP is because if it operated over HTTPS, then we'd have to check the status of the certificate used for the OCSP server, then that server, and the next one, and so on and so on. We'd end up in a forever loop of checking certificates. OCSP responses are signed to prevent tampering.


    • Related Articles

    • TeraMind (Public)

      1.      What is monitored? a.       Windows applications windows titles                                                                i.      Not the content, only window titles to determine the application class; e.g. Productive / Non-Productive ...

    • Recommended page file size in Windows

      The recommended page file size in Windows depends on the amount of RAM installed in the system. Microsoft recommends that the page file be set to 1.5 times the amount of RAM installed on the system. However, it's also suggested that the page file ...