Error 504 when fetching OCSP response via HTTPS


#1

I have a script to refresh OCSP responses once a day for “stapling”. The script is based around this OpenSSL command… ($certs_directory is the absolute path to where the Let’s Encrypt certificate and key are, used for brevity.)

openssl ocsp -no_nonce \
    -respout      "$certs_directory/ocsp.resp.new" \
    -issuer       "$certs_directory/chain.pem"     \
    -verify_other "$certs_directory/chain.pem"     \
    -cert         "$certs_directory/cert.pem"      \
    -url          "http://ocsp.int-x3.letsencrypt.org"             \
    -header HOST  "ocsp.int-x3.letsencrypt.org"                     \
    ^&1 | tee "$certs_directory/ocsp-reply.txt"

I feel like the -url flag should use HTTPS, but when I try that, I get error 504 “Gateway Time-out”. Am I missing something?


#2

OCSP doesn’t typically use HTTPS. The OCSP data itself is signed – hence all the certificate options you pass to the ocsp command – so the transport doesn’t need to be secured. Plus, how would you do an OCSP check on an OCSP server’s own certificate, if it was using the same CA?

I don’t know if Let’s Encrypt’s OCSP servers are supposed to be available over HTTPS or not, but i know the OCSP URLs embedded in certificates are HTTP, and it wouldn’t surprise me if HTTPS was unavailable.


#3

Huh. I’d been speculating that a cleartext connection would mean that an attacker could theoretically add a poisoned OCSP response, or something. But maybe it’s more like PGP-encrypted email? I think anyone who tried to tamper with the email in transit could only break it, make it fail to validate and decrypt, but couldn’t change the original message without access to one (or both?) of the involved keys… Right?


#4

Only if they have access to the private key for the certificate which signed the response :slight_smile:


#5

Exactly. :smile: And if an attacker has access to Let’s Encrypt’s critical private keys, stored securely in their HSMs… well, that’s a bad day for everyone.

The signed OCSP data itself includes an expiration date. At worst, an attacker can replay a response several days old. (Which is actually rather bad, if a certificate has just been compromised and revoked.)

(OCSP has an optional nonce extension to prevent replay attacks, but i don’t think it’s widely used.)


#6

That’s correct - to add more detail on why there’s two immediate reasons: One is it means each response has to be signed at the moment its requested in order to include the nonce in the response. This means having to “live sign” OCSP responses versus producing them ahead of time in batches, which is significantly harder to scale with HSMs. Second, allowing a nonce can actually help enable chosen prefix attacks for MD5/SHA1 collisions for some configurations.


#7

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.