Root Causes 272: OCSP's Privacy Problem

Episode Transcript

Lightly edited for flow and brevity.

• 

  Tim Callan

  We have talked in the past about OCSP. OCSP obviously is real-time revocation checking. Wa browser goes to visit someplace with a certificate there is a check that is made on the moment to say is this certificate revoked or not. Seems like a great concept in principle, right? And it supersedes the prior method which was CRL, Certificate Revocation List, where the CA publishes a list of the certs that have been revoked and then the browser checks against that list to see if the cert is revoked, and you can see where that feels kludgy and inefficient in a number of ways. But, as so often happens with these things, it turns out that in a more sophisticated, nuanced world view suddenly we start seeing the trouble with the other solution, OCSP, and in this case real specifically, there have been a number of concerns from industry watchers but also from industry people including browsers about the privacy of their user in an OCSP scenario.

• 

  Jason Soroko

  Right on, Tim. That’s interesting. So you have been at that table. What are they saying about it?

• 

  Tim Callan

  So the trouble is, if I’m doing a real-time lookup for any given site or subdomain that I’m going to, then it’s possible for somebody to see the site or the subdomains that I’m going to, and that might not be anybody’s business, and we can think of lots of reasons why that wouldn’t be anybody’s business. Even if they can’t see the contents of my correspondence, just the fact that I’m navigating to certain places could be problematic in lots of ways. One of the things that we’ve mentioned earlier in this podcast that’s worth considering is if you are not protecting privacy universally all the time and you are just focusing on very specific moments, then that becomes a privacy problem as well. So you have to think of it broadly, and even if I don’t care if anybody knows that I go to Amazon, or the very fact that you isolate some things we are gonna be able to look at and other things we are not is also problematic. So you have to think about it universally everywhere and yeah, if someone could sit and tell the individual behaviors of each individual as they go get OCSP lookups, that is potentially a privacy problem.

• 

  Jason Soroko

  Absolutely. We did a podcast recently about privacy cookie tracking. We’ve talked about all this. It’s just another way to track you.

• 

  Tim Callan

  Absolutely.

• 

  Jason Soroko

  And it’s kind of client side, kind of service side. So, in other words, these are things that are not secret. So I can see that, Tim. Good point.

• 

  Tim Callan

  Right. Now on the other hand, we have revocation for a reason and we have revocation checking for a reason. So then you go, well, ok, what’s the alternative?

  There are two alternatives. The first one we already mentioned. It’s CRL. Certificate Revocation List. Now we just said, well hold on a second. Doesn’t that sound like it’s inefficient? Yeah. In a way it is. And it probably will continue to be. There are techniques you can use to improve the efficiency. Like you can split and shard and segment your CRLs in various ways, for instance, so that you don’t have to give the entire CRL to everybody all the time. And that definitely makes the whole system more efficient and it means that the CAs’ CRL handling has to be more sophisticated, and they need their own schema and they need their own automation around that and you need to have software systems in place to do that and they need to work correctly, but it absolutely is an option.

  And the other option of course – and this would be a radical change for the industry on the whole but could be, you know, it’s within the realm of what could be done from a computer science perspective - is just extraordinarily short certificate lifespans.

  So let me just pick an arbitrary thing. Let’s suppose, hypothetically, that every SSL, every public SSL certificate was good for one day and it was replaced every day. Under those circumstances, if there was a problem with the certificate, that problem would be guaranteed to be gone in not more than 24 hours.

• 

  Jason Soroko

  Perfect.

• 

  Tim Callan

  And from a revocation perspective, in reality, that’s how long these things take anyway. Like the guidelines, the CA/Browser Forum baseline requirements, state that even in the most extreme revocation scenario like a private key compromise, for instance, or a domain name mismatch, that the CA has 24 hours to get that revoked. So, if the certificate just plain expired in that period of time then from a practical enforcement perspective, it would be identical to having a revocation mechanism in place if you simply didn’t renew the cert. There’s obviously a lot of work that goes into moving off OCSP to one of these other schemes. And it obviously involves changing a lot of how businesses operate, how CAs operate, etc. and in the case of the short-lived cert scenario – and it wouldn’t have to be one day. It could be five days; it could be a week. Like we could pick a timeframe. But if we wanted to move to one of those scenarios, they are doable. They also are not trivial. And so it’s something that would involve standards and systems and processes and behaviors on the side of the subscriber, and all of that stuff would have to be in place.

• 

  Jason Soroko

  So what are talking about, Tim, is to the consumer, to the people who actually use their web browsers, you probably won’t see this transition. It won’t affect your life.

• 

  Tim Callan

  It’s all in the background. If the cert is revoked, you are gonna be presented with a roadblock and an interface that you understand by the browser. And by the way, that’s what happens today.

• 

  Jason Soroko

  Exactly. You are probably not away of it at all. And that’s the way it should be. I think it’s interesting though, of course it will be the browsers who will implement a change. It’s the browser that is doing this. It’s not done at the webserver level. It’s done at the browser level.

• 

  Tim Callan

  Yeah.

• 

  Jason Soroko

  So the other point too - - I think there’s a couple important points that you’ve made, Tim, is from a privacy standpoint, revocation has all kinds of problematic issues and so therefore, eliminating it completely is in fact probably a good goal anyway. The amount of resources it takes to do revocation checking. If people who browse the web understood the sheer amount of complexity and scale it takes to do these OCSP checks as an example, it’s remarkable the amount of work that has to be done. That could be a podcast in itself. I think though that there is every benefit to having shorter lifespans and any time that the CA/Browser Forum or others have talked about it, some of the big industry players have called for it and have instituted it. I think we supported it, Tim.

• 

  Tim Callan

  Yeah.

• 

  Jason Soroko

  However, that is not compatible with those of you who are still not employing certificate lifecycle management.

• 

  Tim Callan

  Yeah, as we start to look at these scenarios, especially, I mean the arguments in favor of automation and Certificate Lifecycle Management even with yearlong certs are compelling. When you start to imagine that you are swapping them out every week, it has to be automated. Like at that point, I can’t even imagine the organization anywhere in the world no matter how large or small who is going to be able to realistically sign up for manual management of these certificates. It’s just not going to be practical. That’s the biggest piece here. We still see so much manual management of certificates even at this late date in history and before we can get to something like we are gonna remove revocation checking because certs are so short-lived that we just don’t care, it is going to have to be fully automated universally.

• 

  Jason Soroko

  Tim, you know, this is more of a topic of OCSP changes, but I think there is a lot here that is benefitting even from the same effect of going to shorter lifespans as a possible option to do away with that complexity anyway. And even just something as simple as mis-issuance by a CA – and it could be from anybody for God knows what reason – going with a shorter lifespan of certificates is a good idea.

• 

  Tim Callan

  There’s what we call a five-day revocation event. Let’s suppose that a public SSL cert is issued and the name of the organization is misspelled, ok? That is an incorrect organization name. If that comes to the attention of the CA, that triggers a five-day revocation event, which means that the CA has five days to do the revoke, and if the certificate is five days in term then what you do is you don’t revoke it at all. The one you issue next time has the correct details and the problem solves itself within the timeframe that is considered to be acceptable by the rules and by the CA/Browser Forum and by the community at large. It’s a cleaner solution to the problem and it’s 100% reliable. There’s no scenario where it doesn’t work at all. And so if we got to the point where we are recycling all of our certs every five days then most revocation events would go away.

• 

  Jason Soroko

  Exactly. There’s so much benefit to the shorter lifespans but it has to go hand-in-hand with automated Certificate Lifecycle Management.