OCSP - Online Certificate Status Protocol

Web client submits a request to a CA server, that returns a signed response with certificate current status.

But the problem with OCSP is,

• OCSP query between client and CA servers during TLS handshake increases latency.
• Relies on CA infrastructure making it prone to availability problems.
• Privacy compromise. Browser leaks what website is being accessed and who accesses it to CA servers.
• Tremendous load on CA servers to respond to gazillions of OCSP requests.

• OCSP is supported by pretty much all the web browsers except google chrome.

OCSP SOFT FAIL

1. Failure to receive OCSP response doesn’t mean certificate is invalid, it is just that CA is unreachable / unresponsive.
2. Most browsers simply treat the certificate as valid in this case. This is called “ Soft Fail “

• Google Chrome does not support OCSP but instead implements its own revocation-checking mechanism. This is called as CRLSets Mechanism.

OCSP STAPLING

• Normal OCSP protocol requires web client to directly query the certificate authority ( Using OCSP ) for status of website certificate.
• OCSP stapling moves this responsibility to the web server itself.
  • Web server will periodically poll CA ( via OCSP ) for revocation status of its own certificate.
  • web server will “ staple “ this OCSP response along with certificate to the client during TLS handshake in a “ server certificate status “ message.
  • In this way , the CA will not know when a client is visiting any particular website.

DOWNSIDES OF OCSP-STAPLING

• It is not mandatory , and clients don’t know when to expect it.
• When cert is received without an OCSP stable, web-client proceeds to using normal OCSP ( if anything at all ) to verify revocation status.

OCSP STAPLE CAPTURE USING WIRESHARK