 Hello everyone. Today we will talk about CERT Mitem, which is my tool, and what it does is automatic exploitation of TLS certificate validation vulnerabilities. We will first learn a little bit about all of these words, what they mean separately, and then we will put them together. We will start with me. I'm Aapo. I come from this Nordic cybersecurity company called Nixu, where I work as a senior security specialist and I focus on IoT. I do quite a lot of work with cryptography and network protocols and sometimes some people put them together to make this TLS thing. I also do security research bug bounty during the nights and weekends and kind of before you go to conferences you start the morning with some bug bounty. I go by Aapo, so please invite me everywhere, shameless bug plug. And I also coach this Finnish-European cybersecurity challenge team from Finland. So good luck to us in Norway in the couple of months. But let's dive directly into TLS. So when you use computers, there's something that you want. So you have your computers. There is some kind of server somewhere. It has something that you want. And to get it, you need to go through the internet. So this internet is a big mess of computers trying to get you what you want. And of course it's made up of different computers in different countries run by different people. And of course there are bad guys. And these bad guys might also want what you want. So they may be able to intercept your connections and listen in. And for this, we have this thing called TLS. So transport layer security. So it secures the connection between you and what you want. TLS basically it's encryption and authentication. The encryption part is basically a bunch of math, kind of cryptography. So people call it like military grade stuff that it's kind of bulletproof encryption. We're not going to be talking about that. So the other part is authentication. So TLS utilizes certificate based authentication. And that's really important because even if you have the best encryption, if you connect to the bad guy, it doesn't matter how well you encrypt the connection between you and the bad guy, they will be able to see kind of the connection. So that's why you really need to authenticate the server first before you make the encrypted connection. And these certificates, you might have kind of heard about them, might have used them. They are these kind of files that have some information and a signature. So this is basically exactly the same as your passport or kind of physical ID. So it has some information about you. It has some kind of signature that, hey, this is a valid certificate for you. In the computer world, the certificates are basically fancy text files that have information listed inside of them. So information like issued by, issued to, public key, some miscellaneous information and a signature. But I think a good take out of this presentation is that these kind of, they are only kind of information inside a text file, nothing special. This information could for example be that you have a certificate that it issued by someone and it issued to someone. It may contain like a public key. This is for the encryption part. Also some information, hey, this is an APO certificate. And of course there is this kind of signature to kind of validate all this data. And how do you make these signatures? You also have your private key. So with your private key, you can calculate the signature and kind of have this mathematical proof of ownership of the public key. So in a sense, you have a certificate and you have a key and this key allows you to use your certificate. And what to use certificates for? Well, you can use these certificates to issue another certificate. So I have my APO certificate and I want to issue a certificate for a server. So I just create this text file, server.pem, issued by APO to a server. It has its own key but I need to sign it with my key. So that's why it issued by me because I have signed it. So this is quite brief introduction to certificates but we can use these certificates now to do this TLS authentication. So server has a certificate that is issued by APO. So we can use the APO certificate to verify the authenticity. We don't need the APO's key, we only need the certificate to kind of validate stuff. But the server needs to have its own key so it can kind of prove that it is kind of allowed to use the server certificate. But yeah, the main thing here and the kind of main point of my talk is that you need to authenticate the server to be kind of, to be sure that you're connecting to the correct thing. So for that we need certificate validation. And of course there have been security problems in certificate validation in TLS quite a lot over the kind of past 15, 20 years. And I think most notably in like 2009, 2012, between those that time there were quite a lot of kind of things. So Moxi had good talks here at Defcon and created these tools to kind of attack certificate validation. The problems are in the libraries and how you use them. And the libraries currently they kind of, they have got some work. So you can use the libraries securely nowadays. The problem is that the implementation part is still hard. It's super hard to use this and we will talk more about those. And 2012 there was also this paper titled The Most Dangerous Code in the World, Validating SSL Certificates in Non-Browser Software. And kind of not much have changed since then. Nowadays we call it TLS, but still it's the same thing and the problems are the same. And we will talk a little bit more about this publication in the end. But I want to give you some overview on what these kind of problems have been. So I think the biggest problem with TLS certificate authentication is kind of, you can see it from this slide. If you don't spot it we can zoom a little bit and enhance. So you might be able to see it. Like what does it mean that you can check the authenticity of the server? So turns out certificate validation in TLS is completely optional and you don't have to do it. So to ensure that you really are connected to the correct server you have to validate the server certificate if you want to. Like usually it's enabled by default, but it can be turned off. And if something can be turned off, like a security feature can be turned off it definitely will be turned off. And if you go to Stack Overflow and kind of search for how to fix certificate validation issues they tell you, hey, just turn it off. You won't have any problems validating a certificate ever anymore. And the certificate validation is really hard to configure. So many libraries they allow for kind of secure certificate validation but they might not have secure defaults. So kind of practical certificate validation. It boils down to kind of three things. Like if it's enabled at all, then there's three things left to do. So we need to check the signature. Like it's just a text file. You can make it up. And if you don't check the signature, like anyone can create any kind of certificate. Next thing, who has issued the certificate? So you really need to check this because I just created myapo.pem. I can issue certificates with that. But you kind of shouldn't trust it. I just created it. And also, who is the certificate issued to? So if I issue a certificate to my server, like it's issued to my server, it's not issued to Google's or Apple's or whoever's servers. It's only for mine. But of course, it's just a text file. I can kind of present, hey, this is my certificate. And if you don't check it, it might go through. So kind of has the certificate been signed? So has the math part been done? And this is usually checked by the TLS libraries. So there should not be kind of problems with this. And like who has issued the certificate? So there are these things called global certificate authorities. So basically a bunch of companies who have their own posertificates just kind of shipped out to all the operating systems and they are there kind of by default in the operating systems and then they can charge money to issue certificates for you. So of course these kind of nice players like Let's Encrypt, who they have done that, they have kind of paid for it. They have the infrastructure, but they will be giving out these certificates for free. So you should get your certificates. And this is something that kind of nowadays, kind of every server has a certificate. And it's kind of, there's a big thanks goes to Let's Encrypt for that. Of course I could just use my aapo.pem. That's valid certificate, it's self-signed because it has issued itself. So kind of you need to check. You can't just offer a self-signed certificate and it shouldn't be trusted. It could be if you trust only that, but you shouldn't be able to create a self-signed certificate on the fly and have someone accept it. And of course is the issue even allowed to issue certificates? So if I get a certificate from Let's Encrypt, like it says that I can't create any more certificates, because of course you shouldn't trust me. But it's still, it's a fancy text file. I can just kind of create, I can calculate the signatures. I have the private key for my Let's Encrypt certificate and I can create more certificates with it. It's not allowed, but if you don't check it, it goes through. Like who is the certificate issued to? I talk about this Let's Encrypt certificate, so I have a certificate issued to me, to my server. And if you are connecting to my server, you should trust my certificate. But if you are connecting to somewhere else, you shouldn't trust mine. But this is one of the biggest things I've come up with that libraries like OpenSSL and WolfSSL, they don't check who the certificate is issued to. You have to go into the settings and kind of enable it. So the default context of OpenSSL, it doesn't have the hostname validation enabled. So if you use OpenSSL, like you might want to check that, have you remembered to kind of enable the hostname validation. And don't let get me started with custom certificate validators. So these are kind of really fun, really scary, but really fun, because you can see kind of quite a lot of different things when you kind of read the source code of someone's certificate validator. So we can take a look at this code, and like if there's some really kind of .NET developers who do certificate validation all day, you might spot them. But let me highlight some problems here. So this is like 15 lines of code that actually do the validation. And on this line, we are checking the elements of the chain, so we are checking the kind of certificate chain. So we only take the last element, so we take the kind of CA, and we only look at that, so we don't even look at the certificate. We don't look at the server certificate, we only look at the CA of the certificate. So for that, it doesn't check who the certificate is issued to. It only checks that it's issued by this certain thing. Of course it doesn't check the signature, so you don't even need to kind of have a certificate from that CA. So you can just make it up because it doesn't check the signature. And like if this is kind of hard for you and might not kind of know how to do this, they made it even easier. So in the end, if all the checks fail, there is this return true. So any certificate file whatsoever doesn't need to be signed, doesn't like any certificate will be accepted by this certificate validator. If you scroll up a bit on the code, we will see where this is from. So this is from this product, Microsoft Management Services, Intune Windows Agent. So if you don't know what it does, it runs every hour and it checks the internet from Microsoft servers that is there a script for it to run with system privileges. And if I intercept the connection, I give my certificate, it trusts me that I'm Microsoft. So of course I have scripts for you that you should run as system. And with that, there is this remote code execution vulnerability. But yeah, we've talked about the vulnerabilities, the issues, everything. We've seen this code. We kind of now have an idea on what to do. But how to actually do it? How do we attack against certificate validation? So we had these problems, like the certificate validator needs to check these three things. So who has issued the certificate? So if you want to attack that, we can just kind of self-sign some certificates. If it doesn't check for it, it will go through. We can also take our kind of let's encrypt certificate and we can sign new certificates. If it doesn't check, is the certificate actually allowed to create new certificates, then that might go through. Also, if it doesn't check who the certificate is issued to, we can get the certificate from a proper CEA, like let's encrypt, for our website and we can try to offer it to the kind of client application connecting to us. And the signature, if it doesn't check, has the certificate been signed? We can just change, kind of get the original certificate. We can put our public key there and then we will have the key to the certificate. Like it shouldn't work because the signature is invalid. But if you don't check the signature, then it will be a valid certificate. So, there's me, there's what I want and the TLS connection right there. So, if someone goes between the connection, generates some self-sign certificates, gets some let's encrypt certificates, does all of this, and does the man in the middle? That's it, that's easy. And this thing, this was taught about 14 years ago. So, there's nothing new in anything that I've shown you here now. So, why am I talking here to you? So, when I was a kid, I looked at those kind of moxies presentations and when I got into penetration testing, of course, I wanted to try these things out. But when you are attacking kind of a phone or a laptop, it's not this. This is the kind of easy thing, but actually it looks like this. So, nowadays, you have a bunch of apps and libraries. Like on a phone, you might have hundreds of different TLS connections. And when you have hundreds of applications with hundreds of TLS connections, you have so many certificate validators to test. So, how do we actually test kind of all these certificate validators? It might take like 30 minutes to kind of test one connection, and if we have 100 connections and you're paid by the hour, like it will take too long. So, we need automation. So, we want to automate attacking these certificate validators. So, each connection might have a different certificate validator. Like, one of those connections is from Intune and it has this funky validator. So, we need to kind of differentiate between the connections. So, because we need to kind of offer many certificates, we need to know which connection is what. And for that, there is some information available, like completely black box. You still have the client IP, you have the server IP. You have this team called SNI, so server name identifier. So, that is something that you can kind of see from the connection. So, you see that there is a client connecting to a server and it asking that, hey, I want to connect to this host name. So, from that, we kind of know that, hey, this is like, this is a connection. And if we see that connection, that type of connection, we can kind of think that, hey, this might be done by a single certificate validator. And kind of every time, it will be kind of the same application and maybe the same validator. So, we want to kind of attack this. So, I created this tool called cert metem. And it does exactly that. So, we have a client. It wants to connect to this auth example. And when it first connects, we will kind of intercept the connection and stop it there, kind of freeze the time and start to do some things. So, first, we will fetch the certificate from the auth example. We will generate all the certificates, do all the kind of test cases that we talk about and then we will start to test these certificates. So, for this first connection, we will give a self-signed certificate. And then it fails the connection, it terminates the connection and then it most likely tries again. So, you might need to click retry or something or wait a bit. But at some point, it will make a connection to auth example again. And then, we will offer the certificate where we have replaced the key. It fails, we will offer a real certificate, our Let's Encrypt certificate, for example. It fails, we will try to use our Let's Encrypt certificate as a CA, and it fails. So, we need to just let the connection go. So, it connects to the auth example. And the auth example, kind of, they talk in TLS, so we have no idea what's going on. Of course, if the kind of server is called auth and it's the first connection from the application, it might be doing some kind of authentication. And usually, kind of authentication libraries are secure. Like, they have done their stuff. But next, like, if you let it connect to the auth example and do the authentication, like, in couple of seconds, you will see a call to API example. And we will do the same. So, we will fetch the API example certificate, we will generate the certificate, so we will kind of try to clone it as close as possible with kind of different attacks we talked about. And then, we will start to test this. So, we give it the self-sign. It fails, we give the replaced key. It fails, we give our let's encrypt certificate. And what is this? We see a connection kind of go through. So, it will try to connect to us. And we, of course, accept the connection and it will send to us this payment post-request. And there's the authorization token. So, even though we didn't kind of intercept the authentication, we now have the token to authenticate as the client. And, of course, there's some kind of business critical data in the post-request. To be really thorough, we close the connection and for the next connection, we give this real service CA test. And it fails. But now we know that there is one test for this particular connection from this particular client that we can use to intercept it. So, now comes the man in the middle part. So, we connect to API example from cert metem. And for the next API example connection, we will give the real certificate. So, the let's encrypt certificate. So, kind of not there. It's not real. But yeah, so let's decrypt. And we will get the same post-request. It tries to resend it. And now we kind of give the kind of push the connection through. So, we send the data to API example. And it kind of, it can then give some something back. And the next connection, like it connects to API example. It wants a software update. And we can see the software update coming from the API example to the client. And because we control this flow, we can see everything. So, of course, we can change this. So, for Intune, this would be the case where you kind of, it tries to get the script. And then the server is like, hey, there's no scripts for you. But we can modify it to always say that, of course, we have a script for you. Cert metem doesn't do that. It's only for figuring out where these vulnerabilities are. And then you can use these certificates generated by Cert metem to actually do the attacking. But yeah. So, I have demo of this tool. So, let's see. So, let's go here and start. So, on the left there is a terminal. So, I have set up some redirections. And if anyone wants to connect through my computer to the internet using these TLS ports, these will be kind of redirected to a port on my computer. So, 9900. And there I will have Cert metem running. So, we have a Windows machine connecting to the internet through my machine. And we are redirecting the TLS connections to Cert metem. And here we can see the connections and see the tests. So, there are multiple connections trying to kind of connect to the internet. We are giving certificates and then in the end you can see what happened. So, nothing received. So, we didn't receive any data. So, that's supposed to happen. Like, if we give a bad certificate, we're not supposed to get anything. So, we either get nothing received or we get some error. But there is this kind of red error message here. It says that this go.microsoft.com connection and we use the real certificate. So, we have, if we give a less encrypted certificate to Windows, it will kind of connect to us. And there is this two connections related to each other. And we can go see the logs. So, here we have the kind of all the traffic logs, what certificates kind of worked for what host names. And here we can see the actual data that was downloaded by Windows. So, this is a configuration file to configure where Windows sends the login credentials when you login. So, this is nice thing to kind of intercept, because here we can change all of these. Like, every kind of URL definition we can change to something where we have the certificate for. And now, Windows trusts us. And that was kind of a vulnerability that I found with this tool. And, well, quite critical one. Next, we have more Windows. So, now we've kind of logged into Windows. We will kind of modify the parameters a little bit of shared with them. So, we will run every test twice. So, sometimes these kind of applications are a little picky and they kind of don't. The first connection doesn't go through and you need to run the test twice. But here, we are setting up a work or school account. So, we are connecting our laptop to our organization. If you are running this GUI applications we might need to kind of retry. It doesn't automatically retry stuff. So, we need to just click on retry. And here we get a connection again for our Let's Encrypt certificate. And it asks us, where should I go if I want to kind of connect to the organization. So, I can now intercept the connection from here and I can set kind of take control of your machine by kind of forcing it to connect to my organization. So, this was another vulnerability found with shared with them. And now, after hard days of work I want to play some games. So, I boot up my PlayStation and I want to play a game. But I don't want to play by myself so I want to go online. And what best way to go online then through shared with them. So, we can see here it's making different connections to the internet through shared with them and we're trying to intercept the connections. And while this application is a little picky it's kind of, it has a connection it really wants to get through and then after that kind of when we have run our tests we will let the connection through and then there's another one it really wants to get through. So, we need to kind of do this multiple times. But this is only for the kind of figuring out if there is a vulnerability phase. So, when you are actually exploiting this and you know what connections can be intercepted then you don't need to kind of retry anything. You can just, for the certain connections you can just offer the certain certificate and be done with it. But I think now we are starting to kind of go past these first phases of the kind of going online and those parts of the application had a certificate validator that works. But when we get kind of through the first five connections we start to see connections with really bad certificate validators. So, all the red are connections made by this game that are vulnerable for this. And when all the test cases have been kind of gone through we will start to see the actual data go through our machine to the internet and we will see everything here. So, here we are intercepting connections from a PS5 game. And, again, a vulnerability found by CertMittim. So, let's see. So, we are getting these connections. Here's the log from CertMittim and I think we're changing up. We're booting up an iPhone. I have to kind of take the HDMIs out and plug them in now. But yeah, we have an iPhone here. So, let's make it a little bit bigger and connect to the internet with Wi-Fi. So, soon we should start to see connections made by an iPhone. And, of course, good part about CertMittim that it's multi-threading. So, you can do all of these tests kind of at the same time. So, have a PS5 controller on one hand, iPhone on another and just go nuts. You, of course, need to, again, retry the connections a couple of times until you get inside the application. This is a lot faster. It has kind of better error handling. And here, we start to download LinkedIn. So, we, again, need to just click a couple of times, see what connections are made and just see that no test kind of goes through. But, again, there are so many certificate validators, so we just need to find the insecure ones. And here, when iPhone downloads apps, all the tests fail or kind of go through. And here, we can see an iPhone application being downloaded, or we can see the plaintext data of that. And we can see here LinkedIn application downloaded from an iPhone. And, again, vulnerability found by CertMittim. And, yeah, this kind of keeps on going. The list is quite big. Here's MatterMost, giving us the MatterMost authentication token that we can use to take control of the victim's MatterMost. So, here, again, vulnerability found with CertMittim. And I just want to highlight kind of, I have quite a lot of these here, just for you to see that this kind of, it's quite easy to find this. Of course, it's staged in that way, that I know that these applications are vulnerable, but we've just tested, in less than ten minutes, we have tested, like, five or six different applications. And here, we are playing a mobile game, and we are getting quite a lot of kind of certificate validation vulnerabilities. And, kind of, sometimes these applications, kind of, they don't show the errors, but they still don't go kind of further. So, we might need to, kind of, kill the application, restart the application. Sometimes applications, like, crash when you do this test, because, kind of, at no point in the development, kind of, the fourth TLS connection failed. Like, usually, like, if you are connected to the internet, you, kind of, everything goes through, or nothing goes through. But here, we will, we can see, kind of, some update files, some definitions, whatever, downloaded by the game. And here, we can see, kind of, the, now all the tests have been, kind of, done. We can see, kind of, many in the middle here. And one good thing about the cert metum is that you can actually, kind of, use these applications quite well. Like, after you have, kind of, clicked retry a bunch of times, then you can just start using these applications, and they, kind of, go through quite well. And you can, kind of, download applications. You can just keep this on. So, at my home, I just, kind of, have everything connected to cert metum all the time. And then, kind of, sometimes, I just, kind of, look at the screen and see some red things there. So, then I just have to, kind of, report the vulnerabilities. So, yeah. So, this is basically how you use cert metum. And after you found these vulnerabilities, you can, kind of, go check the logs. So, what this, kind of, writes. We can see the actual, kind of, intercepted connections. Here, we can see the, kind of, certificates that were, kind of, used to intercept these connections. So, you can just take these certificates and, kind of, kind of, now it's the good part to, kind of, make your report to, like, if you are a pentester, then you just say that, hey, these connections from this application have these vulnerabilities. And this is just a log that shows, kind of, when a connection was made by who and to what and what the test case was. And let's take a closer look at the actual output of cert metum. So, here, we can see that there are connections that we couldn't intercept, connections that we could intercept. And, yeah, and it shows here, kind of, what kind of data it can intercept. Yeah, so this was the demo part. And here are some CVEs, kind of, all of these were found by cert metum. And there are lots of, lots more coming. I found approximately 80 vulnerable applications on different operating systems like Android, iOS, Windows, Mac, game consoles, IoT. There are some things that I do this, of course, professionally, and through bug bounty. So there's lots of things that I can't show you or talk about. But there are some funky things that I found with cert metum. There's approximately 40, zero days currently that I know about that can be found with this tool. So if you go, kind of, connect your phone to cert metum, I guarantee you, kind of, from this audience, there will be, kind of, vulnerabilities found. So maybe the airplane mode goes on now. Mostly these zero days are from, kind of, not so big applications, some games, kind of, not that kind of important stuff. But I think the biggest thing about cert metum is the scale on how many vulnerabilities, kind of, are found with this. And some fixes rolling out in the coming weeks. I've had so many emails yesterday and this, kind of, today morning from the bigger players that, hey, we have fixed this, can you test? So I think, kind of, telling them that you are going to DEF CON to talk about the tool really helps motivate developers to create some fixes. And yeah, more vulnerabilities found every week. I found one this morning. But yeah, so what can you do about this? So if you are a developer developing applications using TLS, so pretty much any developer of any application, you really should read the documentation of the libraries that you are using. For example, Python's SSL documentation has this, kind of, big red box right on the top that says, hey, please don't do these things. And you might want to check that are you, kind of, doing those things. And no custom certificate validators. If I ever see a customer with custom certificate validators, they will, kind of, hear from it. And the reason is that the built-in validators, they support everything you need. Like, I've never seen a real use case that wasn't supported by the actual validators built in to that, kind of, like, languages or whatever. And there most likely is a reason that if it's not supported, like, there's kind of reason why it's not supported. Like, you shouldn't do that. There's most likely a vulnerability in there. One big thing is checking the host name of the certificate. If you use OpenSSL, WolfSSL, you really need to check the host name. You, kind of, you just need to enable that check. And you need to do it every time you initialize and, kind of, SSL context. So if you have, kind of, used OpenSSL, you have done some TLS connections, kind of, have you enabled host name validation? Maybe not. At least the windows didn't. There are some, kind of, you can create some unit test for this. So there is this website called BadSSL that there are these, kind of, similar certificates hosted online, so you can just, kind of, make your application connected there. And if it's, like, if your application accepts a BadSSL certificate, then, kind of, the test should fail. And, of course, setting up CertMitim in your, kind of, workplace, run everything through it, see if it finds something and then fix it. Otherwise you might be getting a lot of bug bounty reports soon. And bug bounty hunters, pen testers. So for you, just run CertMitim against everything. It's really easy to use. I have my, kind of, dedicated laptop for it. It always is, kind of, hosting. It has Ethernet connectivity, it has Wi-Fi. So I just need to connect something to it and it will show me in couple of minutes, is it vulnerable or not. So you run it against everything, you find some vulnerabilities, and you make some profit. So yes, you can run it against everything. It's quite reliable. Nothing has, kind of, broken horribly. Sometimes the applications crash and the thing reboots, but it only does it a couple of times and then the tests go through. You will definitely find vulnerabilities. And the profit part is this little bit of yes and no. So let's first talk about the yes. So decrypting someone's TLS is, kind of, a big thing. So if you, kind of, hack something really important, you will get a lot of money. And this is, kind of, so these are everything found by Certmitum, me reporting them, and this is the reply. The no part is that this, kind of, managed middle attacks are, kind of, kind of people don't like them. For some reason, kind of, some vendors are not worried about connecting to insecure Wi-Fi. Same with this. I tried to, kind of, not include the word man in the middle. I just said, hey, we need to do DNS, kind of, attacks to, kind of, get this. And still the answer is, like, if you need to do some, kind of, DNS attacks, then this is out of scope. But how many people here, kind of, trust their DNS? Like, it's, kind of, universally, kind of, not that well. But in some countries, you might not really get that good DNS replies. And this was, kind of, a really funny one. So this is not a vulnerability, because TLS best practices are out of scope. So, well, yeah, this might not be, kind of, when they say that TLS best practices are out of scope, they might not mean this. And then some vendors don't really have any idea what's going on. So this one is saying that the issue is in, kind of, the cloud provider, so AWS or whatever. Kind of, they are the TLS server. Like, it's not our code. And I'm checking their client application. So it is their code layer. And the problem is that when the, kind of, bug bounty programs, kind of, if they want to give you negative points, they can. And if you go see my hacker one reputation, it's not that good. So I have quite many, kind of, not applicables or out of scopes and these kind of things. So I just try to do the good thing and report it. But yeah, sometimes I get peace. So I think my main thing is for the platforms themselves. So many of the middle and TLS are out of scope in most programs. So there is this kind of default thing that says that TLS and middle attacks are out of scope. But they are mostly written for web application targets in mind. So if you have a server, kind of, man in the middle is not that critical because you, kind of, don't control the client. So it's a user's responsibility to have a client that connects securely. And also, like, TLS servers, they don't do the authentication part usually. So they only do the encryption and the encryption is quite good. So that's why problems in TLS are usually not problems and that's why they are out of scope. But for client applications, these triagers, they refuse to accept these kind of reports from certmitten. And the list of nodes, so there were the four nodes, three of them actually paid me a bounty after, kind of, some back and forth me explaining that, hey, this might not be what you mean by, kind of, TLS best practices. So I propose if you run a, kind of, back bounty program and you have TLS clients, you might want to include that, at least for the clients, insecure certificate validation should be in scope when impact can be demonstrated. So this is just, or then just make this that, hey, this is out of scope. So then I won't, kind of, bother myself to report it. This TLS library developers, so we had in the beginning this, kind of, publication, the most dangerous code in the world. And it was written in 2012 and it has this kind of conclusion was that future research is needed for these three things. So the first one, we need a better black box testing tool to discover errors in TLS connection establishment logic. So this is cert mythum, so 11 years later, we have successfully done the first thing. The second and the third things, however, kind of, still bad. And I'm hoping with the release of cert mythum, these might get more, kind of, we can then move on to the second and the third point. So this is basically just make better libraries. It's really hard to use them. There are so many vulnerabilities because they are super hard to use. So please make them better. And with that, we had cert mythum. You can find it in my GitHub. There's the link. It's up there right now. And go use it and make the world a better place. So you can find me here at Defcon at Nixu, at LinkedIn, at Backbounty. And if you have any questions, I'm available here next to the stage after this. It's done so pretty much now. Thank you.