 Well, hello back again. We have discussed a number of things about public key infrastructure so far, but I have withheld one really important thing and that is called revocation, revocation of certificates. Now what am I talking about? Well think about the following. What happens if you issue a certificate and the private key that belongs to it is compromised at some point in time after the certificate has been issued? Well actually, the certificate at the time of issuance is just a statement that the binding between the identity and the key is valid at that time, at the time of issuing. A simplified example using a kind of comic series. Let's assume Milhouse has stolen Bart's private key and Bart notices a day later. That actually means that for an entire day Milhouse can do pretty much anything mischievous that he would like to do. He has, as we say, a window of attack for one day during which he can impersonate Bart. This has important consequences for PKI. You actually need to make sure the binding between the identifier and the public key is correct at the time that you are interested in when you verify the certificate and in order to achieve that, you need to do a revocation check. Now revocation is actually incredibly important in PKI but in most discussions that you're going to encounter people won't think very much of it. That is a bit sad but it's true. No certificate can be considered valid without a revocation check or at least in theory. And there are cases when a certificate that has already been issued must actually be withdrawn. An obvious case is if the private key has been compromised but it's not the only one. For example, what happens if the owner of the certificate decides that they don't want to use or to operate the service any longer? They don't need a certificate anymore. Best to revoke it or otherwise someone might achieve to use the private key for something else. The key ownership might have changed. For example, someone might have sold their business or more often than not, the private key has simply been lost which means the certificate is unusable on a server. And believe me or not, but this is actually a really common case because human error prevails a lot in security. It doesn't stop there. It's not enough to just check the ENTO certificate. You also need to check that the intermediate certificates are valid at the time that you interested in. In the world of X5 or 9, generally we say we have two options, certificate revocation lists and OCSP. And these come in various flavors, at least in the case of CRLs and we're going to talk a little bit about it. Let's have a look at it. The simplest form are lists. A list of certificates that are considered revoked can be published by every CA that is in the business. They should of course be updated and maintained at regular intervals. There should be ways to identify a certificate for example by a serial number. That is why the field serial number is important in a certificate. Ideally you should also give a reason for the revocation. But obviously there are business secrets and sometimes you just don't want to do this. And of course to be usable, a certificate revocation list must have a time stamp because you need to know which certificates are on the list and at what time they are considered revoked. And it needs to be signed as well of course by the CA because otherwise you have no assurance at all that no one is trying to get you to use a forged certificate revocation list and try to make your service unavailable. There are further entries by the way like when is the next update you etc. But we don't go particularly deeply into this. Certificate revocation lists are the simplest form of revocation but they come with a few drawbacks. Now technically a browser or let's just call a client should download a certificate revocation list every time it connects to a server and of course update it after a given time. So they can check if the end host certificate is correct and not revoked. Now there are problems. Obviously there are always problems and CRLs galore in that respect. First of all downloading certificate revocation lists means you need to download a lot more than the number of bytes in a typical TLS handshake for example. That means you are going to induce a certain load and you're going to induce a certain network activity. The other problem is of course there can be a relatively long time interval between two updates of a certificate revocation list. That would mean for example that your window of attack is one week the worst case if your interval between two updates is one week. Not exactly ideal isn't it? Now CRLs can unfortunately also grow relatively large. Just imagine you have a large CA. Then they are going to have relatively large certificate revocation lists. There was a response to this actually someone proposed to use so-called delta CRLs that essentially just contain the differences. However that requires a certain amount of server side support and in practice they have never become very popular. It doesn't stop here unfortunately. And really nasty little fact about revocation is the following. If you are already under attack and someone is trying to get you to use a forged certificate or a certificate for which they have managed to steal the private key. Well there's actually nothing that prevents them from also blocking your access to download the certificate revocation list. And that renders the entire thing pretty much moot. Now for all these reasons browsers historically did not activate certificate revocation lists at all. Meaning on the web for a very long time and still is and it's still the case in most cases. Browsers are not going to download certificate revocation lists at all and they are not going to do a revocation check via certificate revocation lists. You might be wondering now why are we even talking about it? Well because these are the foundational principle of revocation and it's worthwhile to have a look at them. Enter the online certificate status protocol OCSP. You might be asking why should I download an entire list if I'm actually only interested in one single certificate and why don't I do it live so I have the assurance when I actually need it without a window of attack that corresponds to the time interval between two updates of a certificate revocation list. Why don't I use a query response model? Well that is what OCSP is for exactly. You can think of it literally as a kind of live implementation of look up in a CRL without a CRL ever being transferred over the network in its entire team. You look up a certificate status in a server side data structure that has many properties of a CRL. You query actually by several hash values correspond to the certificate and the serial number of the certificate. Replay protection can be added by using nonces. So you don't just send your query but you also add a nonce in a particular way. You sign it and the responding server must reply with that nonce or modification of that nonce and then you receive the result. You can be sure this is actually a response that you have asked for and it's not just some replay of a previous response. Encryption however is not required. Now what can responses actually be? Clearly there are two status values that are useful. One is good and the other one is revoked. And they are exactly what you think they are. Good means the certificate is still considered valid revoked means it is considered revoked. There is interestingly a third status. What do you do if the certificate for example is not contained on the server side in a data structure? In that case, OCSP interestingly responds with unknown and the response will always be signed. Now there are a few oddities that are worth looking at. Here are the problems and number of issues. Once again, lookups have to go over the network, which means in addition to your TLS handshake, you're going to have additional latency until you can complete the handshake until the OCSP response arrives. That also means your OCSP server must have a really high availability. The last thing you can accept is a server that is slow to respond. OCSP information must always be fresh. So if a CA just uses CRLs in the background and doesn't update them immediately when a certificate status changes, well, that doesn't actually help you very much because you basically have fallen back to a CRL model. It's just that you have managed to reduce the bandwidth required to download. Again, the revocation check can be blocked by a man in the middle or person in the middle. And that is a bad thing because it doesn't actually allow you to check the certificate status. Historically, by the way, many browsers opted to do a so-called soft fail that don't show an error in that case. Why is that? Actually, it turns out that OCSP servers often don't have the high availability that would be required. And even a very small percentage of OCSP queries going wrong would mean that a browser is going to show an error to a user on an otherwise legitimate site. And what is the user going to think? It must be somehow a browser problem. I'm just going to switch the browser until I find one that doesn't show the error. That is a perverse incentive, of course. That's really the term you would use. And because it implies that it is better to ignore security than to protect your users properly. Nevertheless, this soft fail is a phenomenon. This has really happened and has been done. A further issue however is privacy. The OCSP server on the CA site is going to learn which site you are going to access. In other words, they see which IP address is requesting the status of a given certificate. The certificate contains a domain name, almost all cases. And that was going to reply and tell you, well, here's the status of your certificate. And by the way, thank you for your data. Now I can actually build profiles of users. I'm not sure if anyone has ever tried to sell that kind of data or make good use of it. But in principle, this is a leak in terms of privacy. Now, Peter Goodman, who I quote down there below, is a cryptographer from New Zealand. And one of the many quotes that he is famous for is the following one. OCSP was designed as a fully bug compatible stand in for certificate revocation lists. It is true. It solves a couple of problems that are pertain to certificate revocation lists. But it by far, it does not solve all of them. Now, there is an actual improvement to OCSP stapling that addresses a couple of these things, especially the latency of the lookup, the load on the CA. The idea is the following. Why do clients have to request fresh proof from the CA that the certificate is still valid? I could actually instruct my web server to request the very same and basically piggyback it as part of the TLS handshake to the browser to the client, meaning I have reduced my interval of attack, my time window for attack to maybe let's say 10 minutes for server requests fresh OCSP proof every 10 minutes and adjust piggyback the result for example, the certificate is still considered valid to the browser, right? This is called stapling because the piggybacking is like adding a staple to a certificate that the server sends in the SSL or TLS handshake, it reduces the load on the CA in principle, because many users might access a website, and hence also access a CA in a normal model, whereas here, the web server can just do it once every 10 minutes. Nicely, it all dissolves the privacy problem because all the CA learns is that there is a server that requests a new fresh proof at certain given intervals. Now OCSP stapling has been around for while I write a long time, by which I mean at least five years plus, but it has actually seen pretty little deployment. And that if you want to take further lectures, for example, on internet measurement is a phenomenon on the internet that new good technology sometimes is just not accepted by the market. Consequently, browsers chose a new method chose to do different approach revocation, based on the observation that actually most users ever access a relatively small site, a number of websites. If you think about your own browsing behavior, how many websites do you really access a day? Maybe a few dozen? No, imagine most users are like you. They're probably going to access a good part of the same sites as well. Meaning that if you actually have fresh revocation status for let's say a few thousand or a few 10,000 websites that actually is going to cover the needs of let's say, a large part of your users, I have no concrete number, but let's say it covers the needs of 90%, 95% of their users all the time. Why not bake a list of revoked certificates into your browser and let the browser deal with it by phoning home to the browser vendor, who does the entire evocation check on your behalf for that selected list of websites. Nicely enough, browsers actually have such a call home channel. Browser updates nowadays are always distributed basically in band. The browser is active, it downloads and updated updates itself. Most users actually don't even notice that the browser has updated. And in that update process, well, you can just go and do it once daily, for example, and download a fresh list for this list of tens of thousands of websites. It's beautiful. It counters attacks where traffic to the CA is dropped, for example, because your browser is really going to complain if it cannot connect to its own own vendor network. And this way you can avoid the person on the middle attack against the connection between browser and CA. Now, from a more theoretical note, I would say the scalability in general for the entire web is really bad, right? Because we have hundreds of millions of websites, and you can impossibly track revocation status for all of them. But for the most important sites, let's say anything between a few thousand a few dozens of thousands, this should work really well. And indeed, it is a state of the art approach. I believe it was pioneered by Google's Chrome, but was later also integrated into other browsers. Now, let's maybe summarize what are the lessons that we have learned revocation is crucial, but we do not have a silver bullet so far. It is absolutely safe to say that CRLs never worked. They always had very limited use, but they are useful at least to understand the basic principle. OCSP checks are expensive. There's latency load bandwidth, and they are not sufficient to either against an attacker who drops traffic to the CA. OCSP stapling would be nice if it was deployed in sufficient number. And we have the general statement for the general web revocation is an unsolved problem. For a subset of important sites, most browsers can offer a solution.