13

While inspecting my CA-approved cert, I noticed the following oddities:

Extensions/CRL Distribution Points:

  Not Critical
  URI: http://crl2.alphassl.com/gs/gsalphasha2g2.crl

Extensions/Authority Information Access:

Not Critical
CA Issuers: URI: http://secure2.alphassl.com/cacert/gsalphasha2g2r1.crt
OCSP: URI: http://ocsp2.globalsign.com/gsalphasha2g2

Shouldn't the OCSP information be published via HTTPS (i.e., protected with TLS), to protect against MITM? Is that field just noise that shouldn't be used by a client?

I know that Is publishing CRLs over HTTP a potential vulnerability? explains that CRLs are always signed, so it is not a vulnerability to publish CRLs over HTTP. What about OCSP?

(Somewhat related to Does any technology prevent a CA unilaterally revoking a certificate?)

Community
  • 1
Phil Lello
  • 1,122
  • 10
  • 15
  • 3
    The "chicken and egg" problem [Tom mentioned](https://security.stackexchange.com/questions/118101/why-do-some-cas-advertise-insecure-urls-for-ocsp-and-crl#comment213812_118102) in his comment on [Steffen's answer](https://security.stackexchange.com/a/118102/12) is that using HTTPS to check for CRL/OCSP responses when wiring up HTTPS connections would create an infinite loop of HTTPS connections which in turn have to check for CRL/OCSP responses. – Xander Mar 21 '16 at 15:27

2 Answers2

21

The CRL's and also the OCSP responses are signed by the CA. 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.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • After further digging, I believe RFC2459 is the current reference for this - hopefully all client libraries check that the signature is from the correct CA for the CRL. – Phil Lello Mar 21 '16 at 13:52
  • 11
    And, if they wish to use https for OCSP or CRL, they have a chicken-egg problem – Tom Mar 21 '16 at 14:07
  • "This means any kind of manipulation will already be detected even if the CRL or OCSP response is transferred using an insecure transport." - while it prevent from manipulation does it prevent against replay? I.e. is there any check that you don't get stale version of file which does not include a certificate owned by attacker? – Maciej Piechotka Mar 21 '16 at 22:49
  • 3
    @MaciejPiechotka: replay is not a problem. In fact caching is recommended and replay of OCSP is done by a server when using OCSP stapling. But CRL and OCSP have timing information to detect if the response is stale and these timing information are part of the signed response. – Steffen Ullrich Mar 22 '16 at 05:51
  • 2
    @MaciejPiechotka The security model must accept that for a period of time certificate issued by error will be treated as valid! It's an intrinsic part of "error": such certs have been considered valid by the provider itself at some point. The question is how much time is such error allowed to stay uncorrected. – curiousguy Dec 09 '18 at 18:16
6

CRL / OCSP is (in my opinion) the weak link in the CA security model; the fact that they are signed by the CA prevents an attacker from making a revoked cert appear legitimate, but they can always DOS a legitimate cert by intercepting / blocking the CRL / OCSP response. Without a valid CRL / OCSP, the cert should fail to validate.

For public CAs, there's nothing you can do about this, but for private corporate PKIs you can host your CRLs on an authenticated network share inside a VPN (and similar tricks for OCSP) making it nearly impossible for the attacker to know which return packet to block, short of just blocking your entire VPN connection.

Mike Ounsworth
  • 57,707
  • 21
  • 150
  • 207