Does Your Incident Response Plan Address TLS Certificate Revocation?

Warning: Sorry, this post is way more technical than most of my posts.  If you are an executive reading this, you may want to show this to your security or IT folks and ask “how are we handling this?”.  They should be able to explain that to you in English.

Incident response is all about having already considered the scenarios and having a plan for dealing with it.

Consider this scenario:

You have a web site, mail server or other system which is encrypts traffic using a TLS (or more generally X.509) certificate.  That protection works with a secret encryption key and a public key.  Those keys expire after a time period such as one, two or three years (I have seen ones as long as 10 years).

This all works as long as the secret key remains secret.

But what happens if you have an incident where the secret key, which may live on a server or an admin’s workstation (IT SHOULD NOT!) gets compromised?  How do you deal with that.

The problem is that if the private (secret) key is no longer secret, then a hacker can masquerade as you and even encrypt the data with their victim.  There is nothing that a victim can see that would make them suspicious.

If the secret key gets compromised, you can get a new one, but the challenge is how to revoke the old one.  This is something the industry has been wrestling with for years.

FIRST ATTEMPT: Certificate revocation lists:  The certificate authorities that you get your TLS certificates from maintain a list of revoked certificates.  It turns out that this process was so unwieldy that many browsers don’t even look at these lists any more, so that measure is useless.

SECOND ATTEMPT: OCSP or Online Certificate Status Protocol is an attempt at fixing the first attempt.  Instead of browsers having to maintain and update lists in each user’s computer when you try to connect to a secure web site, the browser can make another connection to the certificate authority’s OCSP server to see if the certificate is good.  Only problem is that what do you do if the OCSP server doesn’t respond?  Do you deny access or do you cross your fingers and hope that the same hacker who stole your certificate is not blocking your access to the OCSP server?  Plus, it means that every time you establish a connection to a  secure web site (almost all of them now), it will take twice as long because you have to make a second connection.

THIRD ATTEMPT:  OCSP Stapling.  With OCSP Stapling, the SERVER sends a copy of the OCSP certificate at the same time that you are negotiating the connection.  The server updates the OCSP proof frequently (say every 10 minutes) so there is much less overhead from the browser’s standpoint.    It turns out that some stapling implementations don’t work right and a hacker might tell the victim’s browser not to use OCSP or stapling and the victim would not know any better.

FOURTH ATTEMPT: As I am guessing that you can tell by now, this problem does not have any easy answers.  The next attempt was ACME or Automated Certificate Management Environment.  ACME creates certificates that have a relatively short life expectancy.  For example, Let’s Encrypt creates certificates that only last 90 days and automatically renews them.  But 90 days is a long time for a hacker to be able to run amuck with your credentials.  What you want to do is make it last only a day or a few hours.  This means if the vendor that is issuing the ACME based certificates is down, you won’t be able to get a new certificate and you will be down.  Still, this is way better than the first three attempts.

FIFTH ATTEMPT: (is this getting a bit out of hand?)  There is a new standard in the pipeline with the Internet Engineering body (IETF).  It is designed for big firms right now, but it will evolve.  It does require a change in the browser to make it work, but Firefox already has it and it is likely that Chromium (the basis for Chrome, Brave, Opera, Edge and others) will likely have it soon.  But remember, this is, right now, only for the big folks.  This is called Credential Delegation.  With Credential Delegation, the certificate authority issues the web site owner a normal signed credential but the web site owner has the ability to create delegated credentials that might only last a day or an hour.  They can only do this to the same domain that the certificate authority originally issued their certificate for.  The win here is that if a Delegated Credential is compromised, it will only be usable for a couple of hours to a couple of days.  For example, Facebook is one of the early adopters and is testing it.  If someone were to steal a Facebook credential but that credential was only good for say, 6 hours – or 30 minutes – the amount of damage they could do is greatly limited.

Here are a couple of takeaways:

1. If you are using traditional TLS certificates, do not create certificates that are valid for more than one year.  At least you are beginning to reduce the risk window.

2. Make sure that your certificate provider supports OCSP.

3. Make sure that your certificate provider implements OCSP stapling and that you have enabled it on your server.

4. If your certificate provider supports it, implement OCSP MUST STAPLE.  This will cause the connection to fail if there is no attestation attached to the connection that a hacker uses to try and scam a victim.

5. Use an ACME provider if possible.  Again, we are trying to reduce the time window that a hacker can use your stolen information.  If that window is reduced from one year or two years down to 90 days or 30 days, that is a huge win.

6. Watch for progress on Credential Delegation.  If might be a year away, but when it happens and is available for everyone, you will have the ability to close that window that a hacker can use your stolen certificate down to a day or a couple of days.  Much better than a year.

I know this is a very technical post;  if you have questions, please reach out to us.

For more technical information, see here, here, and here.

by