 Okay, so welcome to another Crypto Village Talk. I'm Matt Singlethee, this is Trey, and we'll be talking about PKI, a public infrastructure, revocation the frailty of PKI, so specifically about some weaknesses in revocation. We're not here to drop O-days, but sort of to talk about the state of the industry and some things that are kind of challenging for the encryption that we pretty much use every day on the web with applications, probably the most commonly used kinds of encryption there are. Okay, so revocation began as something that you did directly to distrust certificates. When you've set up PKI, you have it working, you're gonna find certificates that get compromised, that have problems, they get lost, stolen, whatever, and you have to make them distrusted. So this is what revocation is meant for. And when that started scaling, it's evolved over the last 20 years. The after direct manual certificate revoking, which you do directly on your own device, or on a specific device, non-network related manner, the idea of bringing different kinds of devices together for certificate revocation. So CRLs are a way of taking a lot of certificates and bundling up in a file that can be dispersed. That evolved again because it didn't scale. If you have to have a large file with every certificate that's being revoked, that grows and grows and grows, it gets out of control. So OCSP is the next evolution of that, and OCSP is a protocol that think of it like a database query. You're saying is this certificate good and it'll come back and tell you within a time span, yes, it's good or no, it's not. So you don't retrieve all of them, you only get the stuff that you need. Down the road, so we'll talk about the weaknesses of these things, and then down the road, what the alternatives are. Shortlist certificates are constraining the timelines to do the same, try to accomplish the same goal, and an effort by Google called certificate transparency. So RFC 5280 is where these things are defined. In theory, there's two different states for revocation, which is revoked and held, but the reality is it's just the most common one is revoked. So a little bit of background here. When certificate authorities provide certificates that are signed, they do so in kind of three general assurance levels, that's known as in the industry, the CA industry, as DV, OV, and EV. The reason this is related to revocation is that they have different requirements. So you have a higher level of assurance with the extended validation, because the certificate authorities will go to much greater depth when they're vetting the entity that the certificate's for. And one of the things that go along with that that you get is that OCSP is a requirement, so that most current kind of revocation check is made available. So this means that when you buy that $400 certificate from your CA, they're effectively obligated during that two-year timeline to provide an OCSP server in response that will help, that will redress that. That way they're not compromising their intermediate and again, it's one of those things that's required. So this is, so when you hit the green bar in your mobile OS and you see the green lock and all that, that's typically involving OCSP at this point in time and CRL is still built into these devices, but less than that's commonly used. It's kind of grandfathered in. The CRLs are still there, just not as commonly used. So there are other assurance levels, I won't go into details other than to say CA's will do their own extra magic sauce for other levels. So for explicitly revoking trust, the methods vary by operating system. Mac OS X uses the key chain as a GUI and then the security as the command line tool. It's one from my work that I'm the most familiar with and that those settings for revocation are found ultimately in the system trust settings P list. Windows, I've got the TechNet article there to say it also has a GUI and you can dig in, again, exercise left to the reader. You can go and take specific certificates and mark them as untrusted. For Linux, again, it's gonna depend upon whether you're using Libre SSL or OpenSSL or whatever your stack is. I've got the command here for how Mozilla handles certificate revocation. A good example being a recently compromised certificate or at least a certificate from BlueCote that was not being handled according to the agreements that Symantec and BlueCote had. So it's one that you'd want to have pervasively across the internet no longer trusted or used. So to take another further example to dig a little bit further on Mac OS X, the security dump key chain will give you all of the system root certificates. There are about 190 or 180. Apple updates these on a quarterly basis or semi-annual basis. And that's, again, the root certificates. Removing a root is not the same as revocation. So revocation happens between the intermediates and the leaves. That's how the revocation gets managed. But again, to manually trust or distrust for the whole chain, you could take a root certificate and do a security add trusted cert deny. And then that certificate will then no longer, and all of the things that are a chain up to it will no longer be trusted. So with this command, you could, for example, remove trust to certificates from Turkey or China, things like that. So it's useful. But there being only 180 in the OS, if you drop the Verisign certificate, maybe you'd lose a third of all of your connections. So you have to do this kind of carefully. I don't think Apple wants to have this being commonly recommended. But if you do really need to lock down a machine, it's comforting to know that this is there. OK. So again, that's at the level of the root. So what we'll do for the rest of this talk is step through certificate revocation lists, CRLs, the old way of doing it, and then OCSP, the protocol that's more common and standard currently. So CRLs are encoded as a Dura-Rapim file, and effectively it's just a file that's being hosted. Within the X509 header of a certificate, there'll be an EKU, an extended key usage that basically designates where the CRL will be for that certificate. So when you're doing the chain evaluation, it knows where to check. So you would have a domain setup and a domain name associated with that, that when the certificate is used in a circumstance in which revocation has to be checked, which can also be a requirement in the X509 header, it will go out and make that connection and do that check. So OpenSSL, CRL, there's a command. I don't see it on the slide, but anyway, there's a command in OpenSSL to create the file that could be hosted that way. And then I just want to note in passing, in addition to the X509 headers, the certificate policy statements from the CA will also have these and describe how they're operating and how they're handling revocation. Next. So here's how to make Apache serve CRLs. There's a Apache config directory, SSL, CA revocation path, or SSL, CA revocation file, and you point that to the file where you're hosting these and then when the request gets made typically over HTTP or HTTPS, then that file gets received and the stack that's evaluating the chain will see all those things to revoke and prevent them from being evaluated as trusted. So basically, again, a CRL is just this bag of certificates that are untrusted that grows over time. Also OpenVPN has a directive that's related. So next slide. We're at other places you can find these things. Here are a couple of little Google strings that can help you just find scads and scads of certificate revocation lists that are hosted out there. The certificate authorities largely host these and large organizations that are doing PKI will also keep these collections of untrusted certificates. Once it's untrusted, it kind of sticks around forever. These things, the contents of those, you never want to say, well, we've been untrusted all this time, but we'll take it out. I mean, you have to kind of keep maintaining these lists and they grow, which is why OCSP is a more attractive option. Also want to point out that the policies for checking CRLs and handling revocation sometimes are at the operating system level and sometimes they're at the application level. So it takes a little bit of kind of thought to figure out when you're using an app, you know, is it your OS making the check or is it the app making a check? And a good sort of example here is Firefox handles it all within its own app. So it'll have the entire stack in Mozilla Firefox by itself. Mozilla has a nice feature that pushes CRLs in a compressed form out in every, on a three week basis. So Firefox is doing some really cool stuff. There's a file format for compressed CRLs there, I've shown. And then the patch where Mozilla has done that. Next slide. The reason that Mozilla and Firefox are doing this is that they're kind of keeping up with Google Certificate Transparency Initiative where you have large sets of certificates that are not trusted and yet not necessarily the ability to scale with a lot of requests because if you make a request it's more overhead every time you do an SSL request. So it's kind of hard to find but if you dig for it or if you watch your traffic for a three or four week period on Firefox you'll see it make a request out to this blocklist.adons.mozilla.org to pull down that set. And then again some links to Mozilla policies about where the CAs can report revoked certificates. But by and large it's not really in the certificate authority's interest to do a lot of this reporting to the public. It's more headache, it's things that don't work instead of things that do. So they're not terribly incentivized economically to keep the CAs or to keep the contents of the revoked set made public. So it would be good for us to keep the CAs on track and make sure that they're actually doing their job and handling revocation correctly. Okay, so onto OCSP. Again the online certificate status protocol. It's encoded in ASN1 with all the joys and tribulations that brings with it. So ASN1 is abstract syntax notation. It's very compressed encoding format. And it's as a protocol you basically are making an outbound request for given certificate or given chain to see if it's valid or not. Again run with very high availability requirements on and very low ping times for the big CAs. On the client side the requests are good for a given span of time and there's the span of time in which the CA can provide the response for, which might be you're good for the next year or something. And then there's the actual caching of that check by the OS or the application. So there's a lot of different sort of time slices to keep in mind when you're troubleshooting and working through this. Like I said, there's the official, here's what the OCSP server will tell you and then there's what the actual clients are doing with it. Those are very often very different timelines. So you'd want your browser or your device to check on a fairly periodic basis even though maybe the certificate's good for a year or two years, which is typical for EV, the next day maybe that was revoked. So how do you know it's still good? So there's this kind of set of different timelines about under what period of time the certificate is good. All right, next slide. Okay, right now we're just gonna walk you through working through a basic example of going through an OCSP query. And these are actually pretty straightforward. This is an open SSL command, the commands at the top, the first bit of the output. These are kind of long outputs. But basically what it's gonna do is start going to get the certificate. The next thing you would wanna do is save it as a file which is that last little redirect I've got at the end. And then literally it's this one open SSLX 509 command and this is all you've gotta do to parse it and you'll get this URL. And this is basically telling you the OCSP URL, URI. And that's basically all you have to do to verify where it is. For the next example, we're looking at how you actually do the query if you've got a chain. And this first step is the same. We're just gonna save the certificate to a file so that we've got it. But then this part we're gonna do is grab the certificate chain. And this is gonna vary in length, depending on how the certificate's signed, number of intermediaries, also sometimes where you're at if you've got an intermediary or whatever listening on your network or through your country or whatnot. But this is gonna pull all that data and you can start seeing inside of it all the different issuers of who all's in the certificate chain for that. The next thing is this is just a simple command. We're gonna save the chain to a file. And then this is inside of that chain file. And if you look at this right here, you see the I, I is the issuer. That's the first thing that you're actually gonna look for because you're gonna actually wanna be verifying who's issuing the certificate for this particular website. So this is the thing that you're gonna have to pull out of that. And then this is where you're actually gonna verify the certificate with the issuer. And you can see what we did is we pulled the chain as the issuer. We did this for DEFCON. And then we actually are going straight to the certificate provider for the DEFCON OCSP URL. And that's gonna be a site. They're usually something like this, OCSP.SSLProvidersName.com. The important thing is not to be fooled by this successful response, but make sure that the cert status is actually good. So this can be a little misleading. You wanna make sure that you're actually getting the cert directly certified from the issuer. Okay. So maybe we'll just stop for a second. Any questions so far? Yes. So that those responses are signed. So they're signed by the issuing CA. There's an issue that we're gonna talk about. On the way, yes. Okay, yes? Can you repeat the question? So let me repeat the question and make sure I get it. So you're saying with this, the timeline for the next update, is there a reason for the client, is there a requirement for the client to go and make another request after that expires? So the question is, are the OCSP queries cached? Yes, the answer is yes. And the policy for that can depend upon the requesting stack. So most browsers and operating systems will have a cache for OCSP queries for that reason. And they'll all have timelines for when that's done. So when it does the evaluation, there's a time check every time. Hopefully that's helpful. Okay, next question. Okay, so just some words about revocation on iOS. These aren't typically things that you can access unless you've got a jailbroken device. The CRL is located in VARDB. The OCSP daemon is there. These were used in previous jail breaks. And so they've been attacked. It's part of the infrastructure that gets attacked. The revocation cache is in a SQLite file. And again, you can't do this on your iPhone unless you jailbreak it and directly work with these files. But when you get that SQLite file, you can actually take a look at the contents of a SQLite in SQL and query it out and see the contents of that. If you want to reset that, or basically, I think the only thing I can find that's sort of like officially sanctioned by Apple for interacting with revocation is, other than when you receive the certificate and it's not signed, you have the option to either trust it or not trust it at the very beginning, but is to use the reset network settings, which will blow away the cache. That's kind of awkward though, because then it gets rid of a bunch of other settings at the same time. So there's not a whole lot of granularity for this on iOS. But again, the goal is to make these slides a general resource for people investigating revocation. So maybe some helpful things if you want to look further and some pointers as to where to look. So in some ways, OCSP is a privacy disaster. And I think there's one takeaway from this talk. I would like it to be this, which is that as you're surfing and you hit a site where you need to, you haven't visited before, but say you go through an online commerce store and you visit some products and then you go to the checkout site, which is HTTPS, that will initiate the OCSP request when it's not cached. And so you effectively leave a trail of requests out to the OCSP infrastructure of where you've been. And it's not very commonly talked about that your browser history for HTTPS sites is being leaked or given to the OCSP server operators. It's called a responder. So you have to have a very high level of trust with your CA, the people who are running that server, because effectively you're giving them that snapshot of your browser history that includes every site that you visited that has an HTTPS connection on it. It would be good if someone kind of queried the big CAs to make even more clear whether they're using that data for any purposes. It would be very valuable for data mining. And it's not that there's a right or wrong answer to whether that should be done so much as the policy should be very, very clear to the general public what the use of that data ever could be. I've got to slide a little bit later that'll show the different levels of logging on OCSP server and they can pretty much get, I mean they're gonna get your time and date stamp, they're gonna get your IP address and they're gonna get the domain that you're requesting. Some user agent browser? That's correct. That's true. So let me repeat the question. The question is what about the non-domain cookies? So to be clear, this isn't your web traffic that's being exposed. It's only a check for verification of a certificate that belongs to the domain of the secure one. So you're not getting inside traffic. All your leaking is the domain name. Yeah, because it's cached, it's also not as powerful as a cookie where you're gonna see like that. You're just seeing the initial connection the first time that browser goes to a site that has HTTPS. So it's not as much information as Google cookies. So you only get a check for that domain. So it's not traversing. That's correct. It's on a per domain basis, but let's say, you know, if let's an example path might be like you go to Amazon and then you check out and so you visit a couple web pages for products, none of that would be leaked. What you'd leak is when it's not cached, the fact that you hit the HTTPS, you know, store.amazon.com or whatever site and the time and date when that happened. But again, you're effectively, it's pretty likely if someone wanted to go after that data, they'd be able to get a lot of specifics around what kind of device you have. There's a bigger issue is if you have a large scale aggregation of data, let's say you're in a repressive country or something and a whistleblower goes to a site and uploads some information and stuff, it might identify that whistleblower. So it's situations like that where it can become a much more dangerous scenario rather than the day-to-day user might have. Yeah. So what happens with the OCSP query fails? Yes. So the response where it doesn't know anything about it is actually then a pass because it's saying it's not revoked. So before I jump into the answering the question about man in the middle with multiple CAs, I wanted to point out that there are different levels of failure mode here. Sometimes the fail is hard, sometimes it's soft. So what does that mean? Does, do you continue on with that session enabling that encryption to occur or do you hard cut it off? And that's really up to the browser and the policies in your OS. And the different operating systems handle that differently. It'd be cool if we had a nice table showing how they all handle them, but they're a little bit different. So hard fail and soft fail is a difference. And if you don't mind, we'll keep going on the presentation and get back to the man in the middle thing a little bit later. So you noticed when we did the OCSP request it had that the date range at the bottom. They are time sensitive and basically again the cache is held by the device and it should can only be good for that. But you could have a certificate that gets compromised out within under that time window. So it's good to think of this always in terms of a timeline. So again, your EV certificate is good for two years but if you're looking at how this revocation infrastructure works it has to be able to provide effectively an ongoing 24 seven availability of is this certificate known to be compromised or not. So it helps to think of it in terms of the failure modes of the system as always having a time element to it. Okay, next slide. So revocation is not just for SSL. SSH certificates are quick show of hands. Who's a SSH user familiar with authentic keys? Okay, awesome. You're in the right place if you're a crypto village, okay. Open SSH 6.8 has a feature called key revocation lists. What this lets you do is have a set of keys, SSH keys that are revoked. So the normal model for SSH authentication is you have a key pair that you exchange that you're allowing in. You can graft on PKI to that authentication and this is a mechanism for taking certificates that are bad. So if you had a red team come and own a couple boxes on your enterprise network and they left some keys around it'd probably be good to drop these in a revoked keys list so that they couldn't be used anywhere else. And in general I think having the mindset of managing SSH keys by revoked keys list puts you in a much better position to respond to attacks and challenges with compromised keys. So again, just some directives here in your SSHD config to turn it on. It's called a KRL, which is a key revocation list and you basically provide that as a file which basically stores all the bad keys as hashes and then every time you're authorized in it'll check that against it. So just good to know I don't see this in heavy usage out there probably because the PKI authentication integration for SSH is not all that common but hopefully it'll be more common in the future. So you want to take that? Oh, okay. And this is like we were just kind of pointing out that if you've got traffic that you can capture either on your network or from your browser and your host and stuff. Wireshark has a built-in OCSP decoder and so you can actually run Wireshark or T-Shark, capture that data and start looking at what's going on on your network. This is useful for a number of reasons. You'll also see things like might be software or operating system updates on your network. You might catch a lot of different things. When the OCSP queries are being made via HTTP rather than the HTTPS connections. So you get a little bit more information if you're a network admin of stuff that might be going through your network. But that's already built into Wireshark and we just kind of wanted to point that out real quick. Yep, there's been built-in support for OCSP since Wireshark 1.0, which is kind of cool. It's a protocol that's been around a long time. All right, if you want to run your own OCSP responder, you can do that with OpenSSL and pick a port. I believe there's not a standard port for that. 2560 comes to mind, I don't know. But in this example, 7654. So you basically give this OpenSSL command and use an indexed file that when you set up the CA, it basically keeps a list of certificates that are under management in that file and then you mark them as revoked. So there's a little bit of a question about how well just OpenSSL by itself scales for traffic. So typically the big CAs, in fact, every CA that I know of isn't using OpenSSL. They're actually using another thing called EJBCA. So EJBCA is Enterprise Java Beans, difficult authority, it's like a suite for managing a CA out of prime key. And they were, I typically, you know, at RSA and Black Hat, anybody from prime key in the house? Okay. They're a really great solution. It's Java and Oracle back, so it'll scale like crazy. It typically has a lot of load balancing, net scaler type infrastructure in front of it when you're gonna really like, you know, do the things of the size of Symantec or just sort of the big CAs. It's got three logging modes. So you can log, so what I'm describing here is the logging behind the scenes that as you're hitting these OCSP servers, it can go on. There's just log4j for doing kind of daemon level logging for just troubleshooting the daemon and that it's got network connectivity and whatnot. Then there's transaction level logging which can be customized. And then finally what they call audit log. So if you turn on audit logs, if those audit logs are turned on, that's where you just get a complete stream, you know, of everyone's request for this stuff. That's kind of the privacy scare story right there. So again, these are features that are built in already and if that data gets streamed off and captured for data analytics purposes, again, it's neither good nor bad. It's just I think that the public could use some insights into, you know, if the CAs are doing that and what they're doing with that data. So also to say that, you know, it's a really, really dominant solution. Every OCSP responder I can find is backed by Primkey's EJBC. It's really, really dominant in the marketplace. And when you see that kind of monoculture, like if there was a flaw in that and someone could, you know, take down those servers, it could be pretty crazy. It's a little bit of a risk aggregation for global PKI usage. So short-lived certificates in terms of alternatives to OCSP and CRLs, like maybe this could be kind of like where we're going with the future. Short-lived certificates are one of those options. It kind of came into vogue around 2012. There's a Dan Bonnet paper about short-lived certificates in which they very clearly declare that OCSP is as good as dead. And I guarantee you it's probably the number one revocation check going on right now. Doesn't look like it'll change anytime soon, but it's good to have alternatives. The recommended timelines are like weeks or days, things of that timeline. And basically it would mean that the CAs would be just issuing, you know, very, very short-lived certificates. So it's gonna be pretty heavy lifting. If you think about, let's say your Apache servers would be replacing their certificate every week. I mean, it could be kind of challenging to get that set up. And it will also make the usage of PKI a little bit more dependent upon the CAs. They're kind of in favor, I think, in some ways, but it's a pretty complex topic. There's a lot of challenging effort that would have to go in to make this actually work. But that's one option. Again, with OCSP you get this validity timeline, but the certificates are all the same. You only replace it when it fails. This would just be a continually replaced certificate, like on a weekly basis. The ACME project at Mozilla Firefox would fit very well with that vision to be able to very quickly validate that a certificate is good from the CA for a specific domain. That's actually still under discussion. The industry at large, the CAs, the browser and OS companies are all debating that right now. Yeah, there's a variety of issues with the IoT. There are IoT providers that have ways to manage certificates or having unique clients' certificates on each one of their devices, but there are hardware manufacturers that might just do stuff in bulk that can create huge problems with these kind of things. So yeah, there's a huge issue with that. There's also a huge issue for apps, not necessarily because of the app stores. The app stores are frequently doing the right thing, but if somebody writes bad code on the back end on how it's checking in, there's multiple layers where that can occur in software. So there are other issues there, too, for sure. So another alternative for revocation infrastructure is called certificate transparency. And it's not really a CT talk for those familiar with it, but I'll just give a quick highlight. CT is a Google-driven effort and it basically applies a blockchain to this problem. And it's being already implemented in Google's operating systems and browsers, so it's kind of in place and going. As far as I understand, anyone from Google here? Chrome is not making OCSP requests as a habit. It's using CT instead of that. A good place to kind of see some of the CT logs. The census.io from Michigan has a nice sort of description of the statuses on all these CT logs that are in operation. So I think of these as blockchain servers that are able to provide statuses on certificates. And then with the future of certificate transparency, there's a debate ongoing about how redaction is handled, which would basically be the ability to make exceptions for presence in the blockchain. So kind of a current topic that would open up lots of challenges to the future of CT. So I'll just leave it at that. And the certificate transparency.org site, which Google operates, is a great source of information. Right, right, so with CT, that would be a policy. So the question is, would CT handle every certificate that gets issued? That would be a policy level question. So the certificate authorities would answer that question for you, and they would either say, yes, we're gonna operate this route with that assumption that every certificate comes out of here would be in the blockchain, or they may not do that. And right now we're in a situation where the most of the routes out there don't have CT support by default. So there will be a transition period where, if that is the goal, that we'll have to take some halfway steps to get to that point. So how is CT better than OCSP? Yeah, so it doesn't require an outbound request. The revocation typically gets bundled and then sent out on a periodic basis. Again, the timeline question applies. It's better in the sense that there's an automated, there's a number of reasons. It subjects the issuances to an automatic process that would provide you some level of assurance that it has been issued and the details of that issuance, which right now there are human factors that could get in the way or things that are not logged. So it just provides automation, among other things. But again, this is not really a CT talk, but it'll probably be a future talk here at DefCon on CT, I'm sure. So in summary, you have to take your need to revoke trust about as important as your ability to establish trust. So revoking a certificate creates kind of a failure of PKI. This is where the website doesn't work. You can't reach the site, you can't get authenticated, stuff does not work. But if you don't have a fluid mechanism for handling revocation, you're not in a good position. You should be able to revoke as easily as you can grant on some level. And then we kind of walk through examples for CRL and then another example for OCSP. And for those of you joining late, the slide deck provides a nice kind of worked example that you can use to kind of run this on your own operating system. And then online real-time revocation checks are kind of a privacy disaster and require you to place a level of trust in your certificate authority that exists there, of course, because they're your CA, but in addition, as you use, you don't think of, so list all of the certificate authorities out there as you browse, you don't sit there and say, oh, I just went to, in order to pair shoes online, now I just told that to DigiCert, or I'm gonna go, what's another good example, or hit a messaging server and now Symantec knows that I did that, right? But those are the things that are actually happening with these outbound requests for the use of revocation. What's that? Yes. Or whatever your vice of choice is. So, yeah. Something else that we noticed that kind of comes up, it's not necessarily in who CSP or CRL thing, but there's an issue where people are not checking the certificates in line when they're surfing. And so if you're in a repressed country or repressed corporation and maybe they've got blue code or something like that, we talked about the blue code one that might be revoked, but checking the chain of certificates is gonna tell you if there are people that are decoding traffic. If you've got a certificate added to your box where people can sit there, be it the corporation you work for, whatever, or government or whatnot, it's gonna show you who else can decode some of your traffic. So it's a really important check. And it's something that most people don't think about. So it's something worth looking into. Again, it's not directly related. We ran across a lot of different certificate issues and certificate issues with like IoT and stuff like that. They're not revocation issues per se, but they're definitely interesting things to, you know. So how do you check the OCSP response signature? So that will be in the log for the example, but that's handled by Libre SSL, OpenSSL, your stack will make that check and fail out with that signature is not correct. How do you revoke? So revocation would be the presence of that in your OCSP server, right? So when that responder has that in its database, then that would be providing that as a revoked certificate. So again, if you look at the protocol, you can see it's a HTTP plain text, you can read it and see that that's taken place. Does that answer your question? You're saying you're trying to verify that the OCSP server certificate is valid. You could actually make the request that we showed earlier to check against the certificate server and the way that OCSP communication is authenticating is whether you're gonna know whether it's the same one. You'd have to manually do that. I mean, there's nothing in the software that checks that on a regular basis. Yeah, if the CA is compromised, you could. It only applies to the one who issued the search. Okay, next slide. Oh, okay. That's correct, but the other requests are signed. Okay, so it shouts out to the DEF CON goons, DC 206, DC 408, DC 404. The CA browser forum has a revocation working group that are working on some of these topics and they're hard at work trying to kind of improve the situation. So shouts out to those guys. The Apple ProdSec team, Team Obsters and Hi Mom. I think we're good. So other questions and we are out of time, yes. Yeah, so the question of OCSP stapling. There's specifically a flag with OCSP must staple, which is not in common use, which basically allows the server that you're talking to to make that request out to the OCSP server and give it back to you signed rather than the browser or operating system making that server directly. So that's exactly right. I should have a slide there for that. So OCSP must staple is a promising way forward that resolves some of those privacy concerns. Yeah, the only thing is we don't see that many people using it. Just when they're setting up their search, they get this working, they're happy, it's working, they leave, you know, yeah. So the question is, which browsers are supporting OCSP must staple? Off the top of my head, there are common browsers that do support it. Chrome, I'm pretty sure Safari does. I think that refers to the gentleman behind you's point about the CA pinning and I think, yeah, you're correct, that does prevent a lot of this stuff. The issue that we end up running into is that like, you know, if you're in a repressed country or something like that, you may not have ever connected to the site in the whistleblower case to be able to have the pinning set up to be able to really help. So it's kind of a, yeah, and I agree with that. I think that more controls are better because you don't necessarily know how the browser or software, it's not necessarily a browser is gonna implement the checks. And so the more checks, the better it's gonna be the case. Okay, thank you.