By Tobias Manolo
Life on the Internet can be quite a minefield when it comes to sensitive information, and that’s why we have SSL/TLS protocols and web server certificates via Certificate Authorities (CA) that we trust; they are important, crucial even, to online communication. The web server’s digital certificate is checked, automatically, for any problems when a browser connects to a site using SSL; if any are found, an alert is sent to the user. But there are issues when it comes to these certificates; they expire, the domain name isn’t the name on the certificate, etc. When this happens, the user is unable to verify the site’s owner or check that the page they’re looking at does actually originate from the site they wanted to visit!
Now, there is a way around this by revoking certificates prior to the expiration date, i.e. compromising the private key associated with the certificate or, god forbid, a forged certificate. Revoked certificates are published on blacklists, known as Certificate Revocation Lists (CRLs) and, as part of the validation process, are referenced; however, regularly checking the blacklist doesn’t concur with speed when needing to validate and authenticate a certificate. But, you argue, CRLs are issued hourly… and yes, they are, but there remains a period of time – almost 60 minutes – in which a certificate that has been revoked could be accepted…
Hackers these days are very clever; forging a certificate for them is probably child’s play and they are very adept at disguising a malicious or fake site as though it is legitimate. You look for the padlock in the address bar and its there, displaying a valid certificate should the site be checked; the poor user has not idea that the website is anything other than legitimate, and secure. We’ve all seen the bogus certificates that have been issued for popular sites, such as Google, Yahoo, Microsoft and Skype. But don’t lose faith; around 2 million trusted certificates are issued by CAs every year, worldwide, and the number of fraudulent or incorrect certificates sent out is very low; that’s reassurance that a website you’re visiting is legitimate.
And the recently formed CASC (Certificate Authority Security Council), including members of leading CAs, is keen to promote the understanding and importance of checking for revoked certificates, as well as the deployment of OCSP – Online Certificate Status Protocol – stapling… a vital step in protecting users of the web from blacklisted, forged and malicious certificates.
Today’s major browsers support OCSP checking, but it’s the web servers with the digital certificates that need to support OCSP stapling as well. So, when a CRL request is received by the CA via a web browser, a full list of all the revoked certificates managed by that CA is sent back. At this point, the browser needs to be able to parse the list to determine whether the requested site’s certificate has been revoked. OCSP makes the process easier; the web browser sends the certificate to the relevant CA, who then responds – good, unknown or revoked – for that specific certificate. This process also leads to much less data requiring parsing! And there’s no delay as OCSP stapling allows the browser to connect with the CA directly as the web server will cache a time-stamped, digitally signed version of the OCSP response. The web server is able to ‘staple’ the OCSP response to the original SSL, reducing the workload by as much as 30% than using plain OCSP.
One point to note though is the firewall must be configured to allow OCSP requests and responses when enabling OCSP stapling on the server, especially as the OCSP response will be updated ad pre-determined intervals that have been set by the CA.
To my mind, although a CA will still need to know about revoked certificates, OCSP makes the whole process easier, speedier and more accurate.