Strategies for Improving the Benefits of Certificate Revocation

In my last two posts I examined the reasons why certificate revocation is important to enterprise security and some limitations of using OCSP to check for revoked certificates. Now I’m going to suggest a strategy that you can use to improve the effectiveness of OCSP in your organization.

Improving OCSP

The problem with all of the revocation methods mentioned so far is that the burden is all on the client. Each user, each web browsing request, must make its own query of the revocation service. But there is a smarter way to do this.

OCSP Stapling

OCSP Stapling moves the burden of proof over to the web server or ADC. In this model our ADC will periodically fetch the OSCP status for the certificate it is managing. The result sent by the OCSP responder is digitally signed so that signed of tampering may be spotted.

Figure 1: OCSP Stapling

Now, the client needs only make a single request to the web service. As the ADC sends back the certificate for the web site it is delivering it also sends back the digitally signed status of that cert. >

So OCSP Stapling significantly improves things for us…

1. We remove a huge amount of page load time by cutting out the requests to the OCSP service
2. We fix the privacy issue since the OCSP responder now sees requests only from one place – the web server or ADC
3. And we also cut down on the overhead on the OCSP responder itself since it is now only serving infrequent requests by the web server or ADC.

OCSP Stapling is, however, susceptible to the same active man-in-the-middle (MITM) attackers we discussed with OCSP. By blocking the OCSP response from the ADC to the client (step 4 in Figure 1) we can, again, trick the web browser in to thinking a malicious certificate is actually genuine.

OCSP Must-Staple Certificate Flag

How do we get around this kind of MITM attack? A flag can be set in the certificate at the time it is created. Must-Staple benefits from being embedded in to the certificate itself. This means that, since the whole certificate is digitally signed, it is not possible to forge or remove this setting.

When a client visits a web site and is given the web server certificate by the ADC, the client can then see if an OCSP Stapled response should be sent along with it. A MITM attacker which removes that stapled response would raise the alarm bells in the client browser.

Popular web site testing tools such as ssllabs.com can check for the presence of Must-Staple flags in certificates.

The major drawback is that, as the name suggests, certificates with this flag embedded in to them must  be accompanied with a valid OCSP Staple response. Any that don’t will receive a ‘hard fail’ by the browser. In other words, no warnings. No bypass. The web site will simply fail to load. Even stapling failures caused by lost packets could result in the webpage not loading.

In order to slowly transition us over to this more secure world a security header can be added by your ADC. This Expect-Staple header is being proposed though uptake is slow. Currently only the Chromium and Firefox browsers support it, though it is worth considering if you want to ensure you can reliably staple OCSP responses.

Are short-lived certificates the answer?

Many believe that certificate revocation is so broken that the only realistic alternative is to have certificates with very short life spans. The certificate authority LetsEncrypt has taken this approach. Since their system is fully automated they can justify creation of certificates with a maximum 90-day life span. While there is still that window of opportunity for attackers to make use of a compromised cert, if it expires relatively quickly, that window is minimised.

Though it’s not a perfect solution it is worth considering in combination with your chosen method of checking revocation status.

Recommendations

There are a number of methods for checking revocation status but they all fall outside of the scope of the SSL/TLS protocol itself and, as a result, rarely get implemented.

As with any aspect of security, we need to remove the complexities. Protocols and applications need to have revocation built in and the defaults should be secure. For now, however, the use of OCSP Stapling should be considered best practise so long as its vulnerabilities are considered.

There are many guides available which take you through configuring OCSP Stapling for your web browser or ADC of choice, including for F5’s BIG-IP.

But since OCSP Stapling is far from the perfect solution, what else can we do to raise the level of trust we can place in the authenticity of the user connecting to us? The only true secure form of authentication is multi-factor authentication, and mutual authentication (in which the server and the client both exchange certificates) is not multi-factor.

Rather than rely entirely on certificate authentication, particularly when revocation status is not available or reliable, we need to perform additional checks.

Your application delivery controller should be able to inspect the validity of the client cert, check its revocation status and apply additional authentication methods such as querying the status of a user account in a directory. It is also wise to inspect the end point the user is connecting from. Is it a corporate or unknown device? Is it running a firewall and up to date anti-malware solution? Once we are happy with the device that is making the connecting we can combine certificate authentication with traditional credential or maybe ask the user to enter a PIN from a time-based token. Finally, our application delivery tier should be inspecting the actual requests made by the client and applying behavioural analytics to look for malicious behaviour.

See how Venafi and F5 are working together to simplify machine identity protection at F5 Agility 2018 in Boston, MA August 13-16. For more information on how F5 can help deliver secure authentication please visit f5.com

Related posts

• Why We Need Certificate Revocation
• How to Check for Revoked Certificates
• 4 Reasons Why Shorter Certificate Validity Periods Are a Good Thing

David Warburton, Senior Threat Research Evangelist, F5 Networks