Should the OCSP Responder service be running HTTP (80) or HTTPS (443) ? RRS feed

  • General discussion

  • Hi all,

    I'm finishing my High Available setup of OCSP Response servers (Array).
    I'm at the point that I have to configure my AIA (Authority Information Access) url.
    I've noticed that all configurations in the help files and manuals online at technet are mentioning something like http://yourserver.contoso.com/ocsp, using http but never https. Nowhere it's mentioned that it would be a best practice to use https (instead of http).

    I've been doing some research on this, thinking of scenario's where our HA OCSP Responder (only to check our own client certificates) would actually be running on a public IP, or if there would be "man in the middle" attack scenario's to take in consideration. I've found one scenario in which one can tamper with the response message: http://www.thoughtcrime.org/papers/ocsp-attack.pdf

    But as an "official" or good answer from an OCSP responder is signed by the CA (responder), I think it's not needed to add SSL in the traffic, as it would not add additional security at all (no benifit).

    Note that our OCSP servers would never be running on public address, it would be offered using a reverse proxy + web application firewall. But in large networks like in my company, even for the internal network https is considered as the standard.

    Please share your thoughts on this topic :)

    Kind Regards,

    Wednesday, August 21, 2013 9:10 AM

All replies

  • it MUST be running on unsecured HTTP 80 port.

    My weblog: http://en-us.sysadmins.lv
    PowerShell PKI Module: http://pspki.codeplex.com
    Check out new: PowerShell FCIV tool.

    Wednesday, August 21, 2013 9:50 AM
  • Is there a (official) website where that is actually mentioned as "mandatory"?

    Wednesday, August 21, 2013 10:15 AM
  • OCSP over HTTPS is technically non-working solution, because it requires a SSL certificate that is ussued by a another authority, because SSL certificate MUST be checked for revocation. If SSL cert is issued by the same authority as certificate being checked, then you will never reach OCSP service. When usin 3rd party certificate, you will be redirected to a OCSP service provided by a 3rd party authority. If 3rd party OCSP uses SSL, then you are starting over, another authority must be used to provide SSL certificate and this will lead to a infinity request sequence. Thereby, OCSP over HTTPS is really bad solution. Not sure, but apparently CryptoAPI will permanently fails facing SSL handshake request during OCSP query.

    And the document you provided is about nothing. There is no security risk if someone changes OCSP response by removing response data and modifying it to tryLater status. In any cases when status is not Successful, OCSP service is considered unreliable and revocation provider will move to another OCSP service (that is specified in the AIA extension) or fall back to CRL.

    My weblog: http://en-us.sysadmins.lv
    PowerShell PKI Module: http://pspki.codeplex.com
    Check out new: PowerShell FCIV tool.

    Wednesday, August 21, 2013 10:42 AM
  • Do not OCSP with SSL protection. 

    You are creating a dog chasing its tail.

    To download the OCSP response, you must validate the OCSP response.

    You cannot download the response, until you validate the response.

    Wash, rinse and repeat.


    Wednesday, August 21, 2013 3:16 PM
  • Per RFC6960, "All definitive response messages SHALL be digitally signed" plus a number of other constraints.  If someone is able to successfully MIM these requests you have bigger issues.
    Wednesday, August 21, 2013 4:28 PM
  • Thanks all for the answers and feedback.

    It confirms what I was thinking ;)

       Best practice: HTTP only for OCSP Responders.

    Kind Ragrds,

    Thursday, August 22, 2013 7:54 AM