Understanding How SSL Certificate Revocation Process Works

What is an SSL certificate?

Secure Sockets Layer (SSL) and its successor Transport Layer Security (TLS) are cryptographic protocols designed to provide a secure connection between a server and a client, typically a web server and a browser.
 
SSL Certificates are small data files that digitally bind a cryptographic key to an organization’s details. The certificate contains a public and a private key and the information about the issuer, subject, which is the identity of the website owner, and the validity of the certificate. When installed on a web server, it activates the padlock and the https protocol and allows secure connections from a web server to a browser.
 

Certificate Authority (CA)

Certificate Authority (CA) is an organization that is trusted to sign digital certificates. CA verifies identity and legitimacy of company or individual that requested a certificate and if the verification is successful, CA issues signed certificate.
Public CA vendors: GeoTrust/Entrust/Verizon/Digicert/Verisign/Microsoft/Thawte/GlobalSign/GoDaddy.
 

Certificate Revocation

When a certificate authority revokes any SSL certificate before their scheduled expiration date and should no longer be trusted.  In order to communicate that revocation, the CA publishes a Certificate Revocation List (CRL). In order to make the CRL accessible, the CRL is published to a repository either an HTTP or LDAP repository. These repositories are then referenced in the CRL Distribution Point (CDP) Extension of a certificate. A client that is checking revocation will first attempt to download a CRL from the CDP location referenced in the CDP extension for checking a certificate revocation.
 
Possible reasons for Certificate revocation
 
  • If a CA discovers that it has improperly issued a certificate
  • when a certificate's private key has been compromised
  • due to the compromise of the issuing CA
  • When the owner of the certificate no longer owning the domain for which it was issued
  • the original certificate being replaced with a different certificate from a different issuer
  • the owner of the certificate ceasing operations entirely or 
  • if the secured site is no longer operational

Certificate Revocation List (CRL)

CRL collects and publishes unique serial numbers of any not yet expired but known revoked/invalid certificates are maintained in a master list. Each entry in a CRL includes the serial number of the revoked certificate and the revocation date. The CRL file is signed by the Certificate Authority to prevent tampering.
Each issued certificate contains an URL link pointing to this CRL file so that the web browser knows where to obtain the list for inspection. Since certificates are being continually revoked, replaced for various reasons, the “true list” is a continually moving target, and any copy of the list is out of date from nearly the moment it is published. By default certificate authorities update their CRL weekly.
 
Cons in CRL
 
  • Since the certificate authority model is “trust unless proven invalid”, which means that an old CRL will not contain information of recently revoked certificates, resulting in those certificates being wrongly trusted when they should not be.
  • Also, it is completely infeasible for larger CRL's as the size of the CRL increases it takes more time to download which can affect performance yet the CRL system only works if all web browsers have copies of the very latest up-to-date revocation lists.
  • Also, CRL contains all of an authority's revoked certificates, whereas the client only wants to check one for a website that he is visiting.
During the certificate revocation checking these terms defines how a web browser should behave when errors and exceptions are encountered. Since incorrect security assumptions could lead to serious vulnerabilities and could introduce logical security flaws.
Fail open/soft: When client unable to validate certificate revocation check by any means trust the certificate and proceed.
Fail-close/hard: When client unable to validate certificate revocation check by any means do not trust the certificate and close the connection.
 

OCSP (Online Certificate Status Protocol)

OCSP protocol works by using the Hypertext Transfer Protocol (HTTP over TCP) which allows the web browsers and other clients to directly query the issuing certificate authority for the status of an individual SSL certificate in real time and determine if it is valid or not. When a user attempts to access an https site OCSP sends a request for certificate status information then the server sends back a response of "current", "expired," or "unknown." OCSP was intended to replace the CRL problems but it has its own problems which compromised privacy, reliability, and security. With OCSP, web browsers are no longer required to download and cache huge size of CRL files.
 
Cons of OCSP
 
  • OCSP leaks browsing behavior. Everyone's web browser checking-in with every certificate's issuer to verify its validity is that the certificate issuer then obtains both the querying user's IP address and the website they wish to securely visit. Thus, OCSP creates unacceptable disclosure of every user's private use of the Internet when visiting secured websites.
  • The tremendous load on OCSP responders. With OCSP, every time any user in the world connects to any secured website, that user's web browser must query the certificate authority's OCSP server. The typical certificate authority will issue certificates for hundreds of thousands of individual websites. So every visitor of every website authenticated by that authority will be querying for one of those sites' OCSP certificate status.
  • What does the browser do if the OCSP “responder” is offline, overloaded or under attack or unable to reply for any reason? How long should it wait for a response? Ora Retry before timing out? Certificate validity cannot be confirmed, web browsers do not block their user in the event of no reply to an OCSP request.
  • If an attacker can simply arrange to block a web browser's access to the OCSP system, the browser will fail soft, to treat a revoked certificate as valid.

OCSP Stapling

With OCSP stapling, rather than requiring the web browser to independently obtain an assurance of a certificate's real time validity, the same web server that provides the certificate along with a “fresh assertion(OCSP response)” of the validity of the security certificate which is a cryptographically signed by the certificate authority's key, it cannot be forged. The web server periodically queries the OCSP responder to receive a refreshed and updated assertion. The TLS protocol was extended to allow a web browser to request and a web server to supply this OCSP information in its initial connection handshake.
OCSP stapling solved most of the OCSP problems like privacy, Bandwidth & OCSP server load, Reliability, Captive portals, and Performance.
 
Cons of OCSP Stapling
 
Still, OCSP stapling doesn’t resolve the “soft-fail” issues. What if an attacker steals a certificate and setup a malicious duplicate website by turning off their own server's OCSP stapling. Assuming that they can also block the web browser's direct access to the OCSP server, and the client is set to fail soft, the web browser will assume everything's fine and proceed with the malicious connection.
 

OCSP Must-staple

If a web browser could be absolutely certain that an authentic website did provide OCSP stapling, it could safely and reliably hard fail (preventing the connection) instead of soft fail (permitting the connection), when the website failed to staple a recent assertion even though its certificate was still a valid one.
Just like TLS protocol has “extensions”, so do security certificates also have one. IETF (Internet Engineering Task Force) team have already started working on getting this certificate extension added to the Internet standards which is considered as the best possible solution ever till day. These can be achieved in two ways.
 
Add a “must staple” assertion to the site's security certificate: Any website wishing to protect its visitors from the possibility of revoked certificate abuse can include that assertion in its certificate. The web browser that receives this certificate can verify that an OCSP stapled reply was provided by the server and refuse to proceed (hard fail) with the connection otherwise.
Any attacker who attempts to abuse such a certificate will be out of luck because the certificate itself asserts that OCSP stapling must be provided. But the attacker cannot provide OCSP stapling because that would identify their use of the certificate as fraudulent. This renders stolen and revoked certificates completely useless.
 
Create a new HTTP response header similar to HSTS, HKPK, and CSP: Any web server that wants to protect its users from certificate fraud, and thus offers “Must-Staple:” response header to their server replies with a header includes a “max-age” specification. Once this header is received – over a stapled connection to prevent abuse thus making web browsers will cache the results locally which prevents attackers from excluding that header and not using OCSP stapling.
If the web browser has flagged a site as Must-Staple, because it once saw that header and the age hasn't yet expired, it will hard fail if it cannot obtain OCSP from stapling or as a backup it also cannot obtain it from the OCSP provider designated in the certificate which provides high-reliability of certificate revocation.
 

Conclusion

The original certificate revocation list (CRL) didn't scale well, and the online certificate status protocol (OCSP) which attempted to replace it was suffered from privacy problems and reliability issues making it both undesirable and impossible to depend upon.
 
With the advancement of “Must-Staple” OCSP stapling, it appears to be the best solution for certificate revocation problem which is both reliable and secure.
 
The “first visit” problem: Like HSTS header, OCSP Stapling also suffers from the “first visit” problem. Without having at least once previously visited the authentic website to receive and retain the Must-Staple assertion, a web browser would not know to always insist upon OCSP for that site. This provides a chance for an attacker who can interfere with a web browser's first-ever visit to a website. The simple response header solution fully protects the websites we visit routinely where we are most likely to have a relationship requiring strong security, rather than sites we've never visited before.
 
Binding the Must-Staple assertion into a website's security certificate is the ultimate solution for preventing any security vulnerabilities in the SSL Certificate revocation process.
 
Authored By - Venkatesh G
TCS Enterprise Security and Risk Management
 
Rate this article: 
Average: 2.8 (4 votes)
Article category: