 Alright everyone, the title of my talk is indeed Black Ops to PKI. I think I owe everyone an apology for not having the talk title in the DEF CON description. I just really felt, you know, I don't need another like couple months of drama around what the talk is or what's actually in it, like forget it. I'll just say nothing, have a nice quiet month of July, it'll be great. Anyway, so hi, I'm Dan, not actually a black hat, sorry about that, but this is my 10th talk here at DEF CON. I do kind of a foundational thing like SSH and DNS and same origin policy and DNS and pattern recognition and DNS. So there might be a bit of a theme to the work. This year I'm really kind of looking at authentication. There's something of a crisis going on right now with authentication. Vulnerability is an ode, get all the press, but according to the actual data, 60% of actual real world compromises, not volns, not ode, but just no passwords, bad passwords, default passwords, stolen passwords, my passwords. Yeah, drink does not even begin to describe fail. Oh dear, so here's the deal, passwords are used because they scale really well one at a time. Passwords fail because they really fail to scale once you have them in a large group. So passwords over time, passwords over multiple hosts. At the end of the day the human brain is only so big and people screw it up some more than others. So there are two schools of thought about what to do about this. The first school of thought is we can totally make passwords work if we machine generate them and we cycle them fast and we literally use LeetSpeak as a security technology. It doesn't matter what you do because ultimately as Shania noted, you're still vulnerable to a key log no matter how good your actual password is. So what a lot of people want to do is they want to eliminate passwords entirely and if only we could get humans out of the memory business. We have hardware that has lots of memory, gigs of memory, computational power, why can't it do it? And what we were supposed to be using to do this was public key infrastructure with X509 based technology. We've been hearing this for a while. The kind of vibe I keep hearing is if only we cared enough we could stop using passwords. Everyone would have smart cards, it would be great. Just people need to care. I found on the internet the greatest image of all time that explains what's going on here. The only description I can come up for this photo is if we just had a big enough care bear, we could totally ride this pony. No. Look, business has cared enough about PKI to invest in hundreds of millions of dollars in it in the last decade. It's not working. I have a theory. I think what's not working, it's not the business guy's fault anymore. It's just we screwed up the engineering. X509 is just not the appropriate technology to solve the problems we need to solve to fix authentication. So, I do think we need to rethink the foundations of internet security. I want to point out I'm not one of those guys who says we should build a second internet. That's unlikely. Yes. I was trying to be kind. Look, it's like building a city without roads or highways in the middle of a forest saying, but it'll have great mass transit. It does not make up for the fact that it's not going to work. You have to integrate with existing life. But by the same token, what we're doing now, it's not working. We should talk about why. So, the warning is, of course, look, there's a lot of business stuff going on. The first couple minutes of this talk aren't that late. So, as a preview, I did show up at DEF CON with a cert for DEF CON. It is real. I can't tell you who issued it, but Jeff knows. You can bug Alex Sodorov as well. And it could actually be a cert for anything. In fact, it could be a universal wild card certificate as well. So, at the end of the day, we do end up bypassing the system. Now, let me give you the kind of basic version if you're not that familiar with X509. X509 is basically the digital version of, or when it's implementation wise, of passports. Look, you got a private key, you got a face. You got a public key, it's your passport photo. You have a subject name, your name, a certificate authority, which is the country you live in, a certificate, which is a passport. All we're doing is saying, look, if you have the face that's in the photo, and it's on a card issued by your country, then you have the name of the person on the passport. X509, that's all it's doing. This is the digital version of allowing someone else to assert your identity via a combination of a difficult to fake element, your face, and a name that actually can be used as a handle to communicate with you later. So, it pretty much has only one really good success story, that'd be SSL. This is the technology behind HTTPS or the web. There was a heroic work done in the mid to late 90s that said if you want users to put their credit card number on the internet, they need to use actual good cryptography. This was miraculous that this actually happened. It by far has been the greatest success story for actual strong cryptography. That being said, there's only about a million SSL endpoints. There are hundreds of millions of nodes on the internet, and most of them have no encryption, or actually arguing whether or not cloud-based applications should have to encrypt a link from the client to the server. So, don't think this is a battle that's been won or doesn't need to be refought. Now, here's how you actually end up acquiring a certificate. This is basically a blob of data that asserts that you are your website, so you have a certificate for a website, www.defcon.org. This is a cryptographic assertion that you are indeed talking to DEF CON. The first thing that happens with getting a certificate is you've got to go to DNS. Everyone always forgets this phase, but at some point, Jeff Moss had to go get a certificate from... He had to go get a domain name of www.defcon.org. And when he did that, he actually registered himself as the administrative contact for DEF CON. Next step is to generate a public and a private key pair. These are mathematical objects, large prime numbers multiplied. They are the equivalent of web server needs to have a face, and your web server needs to then take a photo of that face. The public key is provided to a certificate authority along with the name of a website registered in DNS. Now, this is done with what's called a PKCS number 10 certificate signing request, or CSR. The certificate authority. Okay, it's received a public key, it's received a name. How does it know it should actually assert an identity? Why should it go ahead and say that Jeff is DEF CON, or that I am DEF CON, or that Len is DEF CON? Well, the way this is actually done is they send an email to the address that was in DNS at the beginning. There's an exception, hang on for a bit. This is basically them saying... This is basically them saying, is this passport photo actually you? Well, let's go to DNS and find out. Next step, click the link provided in the email, so you get an email at that address, you click the link and that asserts a link between what was registered in DNS and that you are now able to go ahead and get a certificate for that name, and then you get the cert. Now, I'm oversimplifying a little. What I just described is called domain validation. There are many certificate authorities that offer much more stringent validation. They'll do what's called a done's business lookup. They'll do phone calls. There's apparently great news for me. I can go till 8 o'clock. I can relax. But I have no beer. Can someone... No. So, just ascribe it's called domain validation, there are certificate authorities that are much more paranoid about actually issuing a certificate because they're basically vouching for you. They're saying, yeah, you are DEF CON. You are Yahoo. You are whatever. And we're going to do serious lookups. We're going to use a done's business lookup. We're going to call you. We're going to send a lawyer to your house to take a blood sample. But it doesn't matter. X509 has a fundamental limitation in that it cannot exclude without great pain. Now, what do I mean by that? There are dozens and dozens of certificate authorities out there that are trusted by everyone. All of them can issue names, even if someone else... All of them can issue certificates for a name, even if some other one of them already has. There is no exclusion. So this is the direct equivalent of Zimbabwe being able to issue American passports. I'm not saying I have a problem with Zimbabwe, but I'd like America to be the only one who can issue an American passport. I'm just saying. So even if your CA runs you through the ringer, that doesn't mean that every other one will. The security of the whole of any X509-derived system is equal to the security of the weakest link. Unfortunately, anything more is security theater. So there are many good, many responsible, very responsive CAs out there. X509 does not allow the good CAs to offer a better product than the not-so-good ones. The technical term, this is a race to the bottom. But now let's look at DNS. DNS, by complete contrast, is very good at excluding. The root. First off, there's one root. Not 50, not 100, there's one root. There's a classic quote about certificate authorities, where the CA system is only as secure as the money they refuse to take. The root will not actually take your money. You can't register something in the root. They are an adjunct to the state system, and you can't just buy yourself a country. So that's just the reality of it. So the first level, very exclusionary, very good. The second level, the registries. Yes, you have COM, yes, you have NET, yes, you have ORG. But there's one company who is responsible for each top-level domain. Verisign has exclusive control over COM. Affiliate has exclusive control over ORG. When one of the top-level domains had a serious problem with large amounts of malware, this was not a problem that was distributed across lots and lots of different organizations. This was not a problem where there was no accountability. No, that registry had to fix their stuff or their product was going to be blocked, and so they fixed it. That's awesome. The third thing that the DNS system has, which is very elegant, look, we have these things called registrars. These are the actual companies that you interact with when you're trying to put something into DNS. If I register www.doxbear.com through Network Solutions, they have exclusive control over my domain. If they screw up, if I decide they're not very good, I can go ahead and move that domain over to Enom or over to any of another bunch of companies. And Network Solutions, I'm no longer exposed to whatever vulnerabilities they might have. Look, this is the ability for me to manage my risk. Recently, I think Microsoft had their New Zealand sites hit. The registrar that controlled them actually got some SQL injection and they had a bunch of hosts moved over. Microsoft was in the position of being able to move their domains from the crappy place with SQL injection to potentially somewhere else and not have to worry about the problem anymore. That is also awesome. We need the ability to have accountability in the systems that we use. I love the CA system. You wouldn't believe it, but it's awesome having a lot of people out there who are trying very hard to deploy a secure product. But at the end of the day, they can't help me like this. I can't say I only want this CA to be the only CA who can issue names for me. The underlying technology has a problem. Now, it is actually possible to do Exclusion in X509. It is possible to basically run your own certificate authority. This is what every enterprise is told to do. Run your own enterprise CA and that's how you'll manage your trust in your organization. On its own, it's very expensive, very difficult to maintain, and every single time it hits the exact same failure. Oh my God, there are other people out there and they need to authenticate them too. So how do I deal with all of the other private CA's that are out there? How do I federate? The one successful federation in the world for X509 is the Federal Bridge CA. My God, it works. This is amazing. The people behind it who made it work deserve a medal. The rest of us need a system that you don't deserve a medal if you actually get it to work. Interruptibility with other organizations was thought to be an optional thing. We won't often need it. And it turns out it's just not true. In theory, you only need to authenticate your own organization. Usually your house key is only used for your house. Reality, cross-organizational authentication is the rule and not actually the exception. We have partnerships with other companies. We have interactions with other groups. Who thinks a large company is just one large company has never actually worked in a large company? You are dealing with group after group after group. So this is one of the reasons why passwords work. As stupid as they are, a string of text is a string of text is a string of text no matter who you're talking to. This X509 stuff isn't. So X509 cannot delegate either, at least without great pain. Every time I need a new certificate for a node in my organization, I have to go ahead and talk to an external CA, another company, and I have to get a certificate for that particular node. Every single operation that's completely internal, I need to keep jumping across the fence to some outside company. This is expensive. This is operationally inconvenient. There are potentially information disclosure issues, and it interacts very poorly with devices. There are hordes of devices in all of our organizations, all of them have DNS names, none of them have anything more than self-signed certificates. So we were supposed to have this thing called name constraints, and what name constraints were supposed to let you do is they were supposed to let you sign for star.docspara.com or star.this.com or star.that.com. They were supposed to allow you to get a delegated portion of the namespace, and that would be your portion and your tool to work with. There's very weak support for this in the field, so you can't actually buy it. The technology just wasn't deployed sufficiently enough to depend on. Now, there's another option you could do. You could get a wildcard certificate, get one certificate, same certificate for all of star.docspara.com, and now you put the same crypto key on every device in your organization. That sucks. That is a technological limitation that has just failed. DNS delegates fine. The root delegates to verisign for calm. Calm delegates to my servers for docspara.com. I do whatever the hell I want in docspara.com. I don't have to talk to other organizations. That is why all my devices are in DNS, and very few of them are in SSLX509. Now, it is, in fact, possible to delegate X509. There is serious demand. Here's what happens consistently. You have a company. They spend a couple million dollars, or some absurd amount of money, on their own internal certificate authority, and then they find they don't work with anybody else. They say, what do we need to be able to work with everybody else? And CAs come back and they say, well, you kind of just have to come and talk to our website. Companies are like, no. We want our certificate authority to work with other companies. CAs say, well, that would be really insecure. I signed certificates for Bank of America and this and that. And the company says, I don't care. I want it to work. So the CA says, fine. Sign a contract promising you won't abuse the big magic cert, and we'll just give it to you. I promise is not an acceptable security policy. So the reality is we have no way, you know, forget hacking yourself a certificate, a root cert. You can just buy one. It's not that the companies don't take security seriously. It's that the underlying technology forces this particular failure mode. So 2008 was not a good year for this system. Mike Zestman did a whole bunch of work against production certificate authorities. Bypass Komodo's security check by claiming that he had this really cool internal server called www.live.com. Thus it wasn't subject to validation checks. Also bypassed StartCom's checks with some web bug. Well, I broke it as well. As I told you, SSL ultimately takes a dependency back on DNS, and we know how that ended up. But interestingly enough, Avi Pilosov, actually, he did his whole thing with BGP last year. And so he showed that he could actually sniff arbitrary traffic from arbitrary locations on the internet if he had ISP level access. Well, that means he can sniff SSL validation emails as well. So, he wins. But the big hack last year was Steven Soterov versus MD5. And what their trick did was pretty cool. When a certificate authority or country deems you worthy of a certificate or passport, it signs, creates a passport with a hologram, your public key, your photo. Now, signing requires two steps. First, it requires securely hashing the certificate. This is summarizing it to a small number of bits. A hash is considered secure if it's difficult to find two files with the same hash. Secondly, once you have this summary of bits, that's what you go ahead and sign with a certificate authority's private key. So it is actually the summary that, you know, like a photo is a summary of your actual face. That's what the signing is sticking a hologram on top of it. Now, the problem was that RapidSSL, one of the CAs out there, was using MD5 as its hashing algorithm. Now, MD5 is not secure. We've known this since 1996. We're still using it. So, Steven and Lenstra actually went ahead and created what was called a chosen prefix collision attack. Now, in this attack, given two different beginnings, they were able to create a blob that if you attached it to both of these beginnings, which could be anything, would cause them to unify into the same hash, into the same summary. So the attack was that they had a certificate authority, sign a certificate that looked completely innocent. It was a completely valid certificate for, you know, some very long domain name that Stevens and Sodorov had. Sodorov then went ahead and shifted out the innocent content, replaced it with an intermediate certificate that could sign for anything, replaced it with a God cert, if you will. And because of the chosen prefix attack, the summary of the innocent version was equal to the summary of the God cert. Doing this also required some really interesting timing work to get the serial number of the CA also correctly predicted. Now, there's more where that came from. Finally, we can actually talk about the actual security data. So the more where this came from, it turns out X509 is really, really fragile at pretty much every depth that it's examined, pretty serious ambiguities and risks are found. Consider hashing functions. We all know at this point that MD5 is a valid signing algorithm for X509 certificates. What you may not be aware of is that MD2 is also supported. MD2 is a predecessor function to MD5, now known to be even less secure than MD5. If a certificate happens to be signed with MD2 RSA, everything except the new TLS will accept it. Now, this shouldn't matter. Steven Zinzodorov required a certificate authority to actively sign specially formed blobs with MD5 RSA in order to exploit the insecurity of MD5. There's nothing signing with MD2 RSA anymore. There hasn't been for like eight years, so everything should be okay, right? Well, I have a theory. I call it the final destination theory of cryptographic vulnerabilities. Now here's how it works. Cryptovolns tend to be subtle, telegraph years, maybe even decades in advance. We don't know when they'll burn us. We don't know how they'll burn us. We're pretty sure we're going to get burned. It'll probably be epic. Thus, final destination. So we'll begin by taking a look at this. It turns out one of Verisign's core root certificates is actually self-signed with MD2. Really? It was 1996. We were young. We needed the bits. We really didn't do security very well in the 90s. Let's talk about why this matters, because this is not obviously going to lead to a problem. This is a self-signature. This is a self-signature in a root certificate. The signature means nothing, or at least approximately nothing. Len Sassman and I have an argument about whether it actually means nothing. But here's the deal. In normal X509, your public key and subject name are signed because by somebody else. This is an assertion by somebody else that you have a particular identity. When you have a self-signed signature, you're saying, I am me, and I can prove it because I say I am me. This means nothing. This has no actual security implication. The only reason I think this is there is because parsing libraries from the 90s really wanted to see a certificate there, and so they put one there. Why sign with MD2? Turns out it was the 90s. According to Peter Gutman, it may have just been that was the only thing they could get their magic hardware to do, thus proving the general rule of hardware. Hardware sucks. RC2313 actually says, MD2 is the slowest of the three, and thus the most conservative. Not exactly what it's saying, but it's pretty close to if it's slow, that means it must be secure. Subject of insecure hashes. There are many ways a hash can fail. There's collision attacks where you can generate two things immediately that have the same hash. That happened in 2005. This is what Zhayun Wang did. There were the chosen prefix collisions, creating something that when appended to two things with different hashes, causes them to have the same hash. This is what Stevens and Sodorov did and worked very well. There's a third class of attack, and this is called pre-image attacks. Pre-image attacks say, given a hash, create something new with that hash. In other words, hi, I've got this summary from 1996. Create something with this exact same summary. Shawan, you can't do this, at least with no attacks that are being found. MD5, you can't do this. MD4, you can't do this. MD2 is starting to be another story. Here's what you do. This is the actual implementation of the attack. You generate the GodCert. You generate a new intermediate certificate that can sign for anything. That's nice. It's got a chain back to a root. Something has to assert it is valid, or the fact that it's a GodCert means nothing. It's just a pile of bits, there's no meaning attached. What we're going to do is we're going to give our intermediate certificate the same MD2 hash as the actual root. That means we can take the self-signature on the root, the self-signature that has at least almost no legitimate reason to be there, and we can give it a use. We can make it the signature on our faked intermediate. We can make it better. So, now the intermediate appears to be signed by the root. It has the root signature across the same MD2 hash. You have two certificates in the row with the same signature and the same hash. Works very well. Does depend on there actually being an MD2 pre-image attack. Is there one? There will be. In 2004, the complexity of doing this was 2 to the 104. In 2005, the complexity of doing this was 2 to the 97. In 2008, Soreness Thompson found an attack with 2 to the 73 complexity. Now, our best computations out now are around 2 to the 63 complexity. There's a trend going on. I actually went ahead and visualized the trend. We have two options. We can wait, as we always do in cryptography, until it absolutely blows up in our face, or we can actually do something about a cryptographic vulnerability before it fails on us for the first time in history. Yeah, we've got it. So I went ahead, talked to a bunch of vendors, and I was like, guys, come on. We're all a little embarrassed about this whole, like, MD5 still being used thing. How about we at least kill MD2? And I said, okay. So open SSL, it's dead. It's out of 1.0, beta 3 for certificate validation. 098 CVS, has it also disabled. The 098 from August will also have it just completely out. NSS, the CryptoCore Firefox, this is already dead in Firefox 3.5. It's part of their 3.12.3 library. So that's good. Firefox 3.0 is getting fixed soon, some point in the next couple months, maybe. Red Hat has already updated their operating system with the latest NSS as well. Verisign, they're on board. They're going ahead and they're reissuing that certificate with a SHA-1 self-signature. Nothing's using the self-signature, but hey, at least we can get rid of MD2, finally. Opera's waiting on Verisign. Apple, Microsoft, they are testing their fixes. Google has Android disabling MD2, and GNU TLS got rid of MD2 years ago, so they're just laughing. Open source suckers, no. Now, we get to do some really, really messy things with this particular compromise. When this hits, this particular root certificate has the client authentication extended key use. SSL normally is used to authenticate a server to a client, but for very high security applications, SSL can authenticate a client to a server. This particular root has the capability of being the trusted root behind such authentication. So what that means is that you can basically say, yeah, my username is anyone, and just get in, just let me in, because my fake root says so. Then you might say, but Dan, no web server would ever trust this random Verisign root for authentication. Actually, by default, Microsoft IIS trusts this random root for authentication. You can ask, go up to IIS, use the OpenSSL as client tool, and if it has client authentication enabled, you will get this dumped at you. This is a list of CAs that are allowed to assert arbitrary identities. So the Class 3 Public Primary Certificate Authority is actually on this list. Remember what I said about exclusion? It doesn't matter how ridiculous your own CAs policies are, it only matters how ridiculous the weakest of the CAs are on the list. Any of these CAs can actually do authentication to this particular host, and if we actually, when we get our pre-image attack working, this will be part of the list. This was not a capability we had with the MD5 certificate. Now, granted, the MD5 certificate actually exists, but it actually cannot operate as a client authenticator. Now, I'm kind of picking on Verisign by pointing out their root certificate. It is funny to see MD2 in your root store, but Verisign was not the only company using MD2 RSA. Lots of companies were using it up to like 2000 or 2001. Now, all the certificates have expired by now, but that doesn't matter. As Stevens and Sodorov showed, if you can alter a certificate, you can change the expiration dates. It works fine. So it doesn't matter that they've expired, but it does matter that they're gone. You know, it's been like eight years since anything has actually used this. There's not many left. There's one MD2 root that I found that is kind of epic, and most of you are not going to have any idea why this is awesome, but those of you that do will know exactly why. Rubicon, this is not... Rubicon, this is not... So there was, a few years back, one conference. One conference where the attendees, one hacker conference where the attendees were let out with their hands behind their back. That conference was Rubicon. It is rather amusing that that was the only one of the few MD2 search that I found that could still be used. So does this need to be fixed immediately? Now, it needs to be addressed, but we don't need to panic. I went to talk to Bart Praniel over at the University of Leuven. He's Len Sassmann's advisor. Len was working with me at the beginning of this and has been a great support throughout. So his response was, there's not likely to be a public pre-image attack of less than two to the 63 complexity within the next six months, even with this knowledge dispersed. So I said, cool, told the companies we don't need to pull the emergency sync button. Relax, let's actually fix the bug, but we don't have to fix it in some kind of crazy thing like we did last year. I guess my friendly request, which would be kind of lame to do, but I'll do it anyway, please try not to break MD2 completely in the next six months. Is that you and Wang? Please? It is an offline attack though, so it's not the sort of thing that would actually lead to a lot of traffic showing up at certificate authorities. It can be done, you know, stick 20 grad students in a room for six months. So, do you have something you need to say? Apparently there are, MD2 shows up in SMIME email encryption. Crap. Okay. I'm gonna drink for them. So, manipulating existing certificate authorities, how do we do that? The MD2 attack has no link to present day certificate authority operations. Verisign has not done anything operationally with MD2 for years. Is it possible to bypass protections in present day certificate authority operations? Well, you gotta consider this is the quote that actually spawned this entire talk. From Meredith L. Patterson, I'm gonna go home and figure out the precise grammar of a certificate and see just what I can put in there. I'm like, that's a very interesting thing you just said to me, Meredith. Because there are two kinds of parsing vulnerabilities. There are those that cause a system to misuse memory. Those would be your traditional exploits. And then there are bugs that cause a system to parse a different message than was intended. Those would be what we call semantic exploits. It doesn't crash, it just reads the wrong thing. Now, you gotta realize there's some semantics going on here with a certificate. A certificate authority and a browser are talking to one another. They are saying, the CA is saying, browser, I tell you that this public key is linked to that subject name. And the browser has to hear, CA, I hear that this public key is linked to this subject name and it has to be the same name. What if it isn't? That'd be bad. That would mean a CA would hear one name and the browser would see another. So how do we know that what the CA says is what the browser hears? Well, there is a field called language theoretic security that attempts to explore this sort of semantic question. This is formalized by the other guys on this talk, Patterson and Sassman. And it describes how to build parsers that will always parse the same message in the same way. Now, I know you're thinking, you know, we should shouldn't we just be able to take this for granted. How much code is different, how much does code become different in C when you pipe it into different C compilers? Same kind of crap. Same message, different parse tree, different output. This work was actually first used in 2005. They actually built a system called Dejector for eliminating or at least dramatically reducing SQL injection attacks. X509 was developed a long time before such formal validation models. And it shows. So, let's walk through the CA pipeline. The user generates their public and private key, submits it in the PCCS-10 certificate signing request. Now, there's lots of crap in this request. There's a country, a state, a city, an organization, an organizational unit. The only thing the browser cares about is the CN, the common name. If a CA approves of a common name, it can do one of two things. It can do the more secure thing where it generates a certificate with only the elements that have actually been validated, so by actually making the DNS request. This is what's called scrubbing. And that would be the secure thing to do. The easy thing to do is to just say, okay, everything looks good and sign the subject name as it sits. This is actually what OpenSSL makes very, very natural. There are three ways of using OpenSSL to build a CA. You can simply sign whatever request comes in and then see if you like the output, and they actually from their command line will output a nice string for you to audit. You can dump the request to text and then parse that, and that goes ahead and has this nice line that you parse with the subject. Or you can go ahead and dump the generated certificate and then see, you know, here's your CN and see if you like that. Now, there's a pretty obvious thing you can do straight out, which is well, there are strings. We can just inject the appropriate strings to make it look like a new CN is there. So this is the organization string, organization name, and then we're going to have it have the printable string, bad guy ink, slash CN equals www.badguy.com. So now, when the CA does their dump, what they get is signature okay, subject equals bad guy ink, and then this injected slash CN equals www.badguy.com. Now, OpenSSL has four modes for emitting text. It is clearly meant to have its text processed. All of the non-default modes are secure. So, now the exploitability depends on how the text auditor is actually handling its, uh, now one thing you might notice is that we have a couple of CNs here. We have the injected CN which came first, and we have this real CN, the bank CN. Interesting question. What does the parser do when there are multiple CNs? This isn't just a question for what the text parser does. This is a completely valid question for what happens if you submit a PKCS-10 request with multiple common names, and that gets through to a client. That's a really good question, because literally every possible thing has been implemented. Um, OpenSSL will give you the first one. IE will take them all. Firefox takes the last one. First, all-inclusive, last, fail. So, what, of course, should the correct policy be? Well, this is wonderful. If you go to the RFCs and people were scrubbing through the RFCs for, like, weeks, they finally found one RFC that specified correct behavior. In parentheses, most specific. They don't actually define most specific anywhere in the RFCs, but they do say the words most specific. So, I said OpenSSL usually gives you the first CN. It doesn't have to. The OpenSSL developers realized the situation and, uh, they went ahead and made their API such that you could run it in a loop in this particular manner, and it would give you each common name until it exhausted. However, nobody actually uses this API. Everyone just calls X509 GetTextByNid. You see this in every project that we looked at. Clause, Open1x, WGet, Bacula, Neon, OpenLDAP, any CA that was based on using X509, NameGetTextByNid would only see and would only validate the first common name. So, what would you do with this? Well, we want wild cards, but there's an interesting limitation with wild cards. Netscape says if I see a cert with a star, cool, the certificate is valid for every name in the world. Internet Explorer says I'm pretty sure if I see a certificate with a star, the certificate authority was probably hacked. I'm just chicken. I'm not going to do it. So, it will allow a star, but it wants a couple labels first. So, you can get star.duxpera.com, but you can't get just star. So, what you would have is you would have a PKCS10 request with three labels. The first CN is for www.attacker.com that's for the CA to see and validate because they'll send attacker.com an email and attacker owns attacker.com. So, it's great. The second one will be www.bank.com specify a particularly interesting target and IE gets to see that. And the third one will just be the star and that'll be what Netscape gets. So, what is a CN anyway? X509 is written to a specification called ASN1, which I'm pretty sure was designed to make small puppies cry. It's designed to be very fast to parse. It's actually very fast to crash under fuzzing. 2002, the PROTOS project actually fuzzed SNMP and pretty much destroyed every router on the planet. Now, I will say every certificate authority has an ASN1 listener listening publicly and anonymously via PKCS10. Ideally, they're all built on ASN1 stacks that got hardened back when we dealt with all the SNMP vulnerabilities. Ideally, people have been warned but we are a little worried about just fuzzing against ASN1 stacks here. This is cool. One of the other things that can happen with any sort of text injection layer is SQL injection. This stuff is put into a database and we work on it. It turns out the CAs figured this out a few years ago. Quite literally because of little Bobby tables. XKCD actually helped secure a bit of the internet. Awesome. Apparently after little Bobby tables came out, a lot of people were introduced to SQL injection by that comic strip and the certificate authority guys were like you know, we could totally get something with a common name of drop the entire certificate database. We should do something about that. I thought that was kind of cool. Cheers for XKCD. Now, this is cool. In ASN1, common name, that's the nice handle. That's what we speak as English speakers. But language is hard and localization is difficult. Not everyone knows what common name means if you're a Chinese speaker, you have no idea. So what ASN1 does is it actually has all of these what are called object identifiers identified by number. So say instead of common name it's 2.5.4.3. It's a hierarchical namespace. Now what does this actually look like on the wire? What are the actual bytes? Well there's something called ASN1-BER Basic Encoding Rules. And this is a tag length value file format. Very simple introduction. You have an OID, which means your first byte is 6. So if you have a tag, 6 length, some number of bytes, and there are like three different ways of encoding a number of bytes because it's ASN1 and it hates you. The actual numbers are encoded in base 128. So this is how it works. If you have just a 06 that means the number is 6 and then there's a period after. If it's 86, it means the number is still 6, but this is one digit of a multi-digit number, with each digit being in base 128. So 86 is 6 and there's another digit coming. And it's big endian if you're curious. So let's look at a simple OID. 2.5.4.3 is 6 which is the object identifier. 3, length 3. 2.5 is encoded as a 55 because they're trying to save a byte. And then 4 is just 4 and 3 is 3. So 6, 3, 55, 4, 3. Very nice, very simple. Get a little more complicated. Let's do 1, 2, 8, 40, 1, 1, 3, 5, 4, 9, 1, 1, 1. That'd be RSA encryption. Okay, well, tag is 6. Length is 9. Now you have a value of 2a which is 1.2. 86.48. Great summary of what's going on here. This is 6 times 128. 86 minus 80 is 6. So 6 times 128 plus 72 is 840. And there's the 840. And then we have the same for the big number. And we have 3 ones. So 0, 6, 0, 9, 2a, 8, 6, 4a, 8, 6, f, 7, O, D, 1, 1, 0, 1. 0, 1. I missed a 1. Sub attacks. Leading zeros. One can have a tag of 6, and a length of 3, and then 55, 0, 4, and then instead of just 3 we have 83 which is 0 times 128 plus 3. So it's still 3. This has been seen before. We saw this in a few LDAP attacks. But suppose we actually had 2.5.4. 0, 0, 0, 0, 3 and then had that equal to www.bank.com. What would this actually be seen as a common name? OpenSSL tells us to go pound sand. It still actually does render out 2.5.4.3, but it's a semi-collision. It does not actually resolve back to CN. So no text parser would actually see it as a common name. Netscape also sees 2.5.4.3. Object identifier 2.5.4.3. But it does not resolve that back to common name either. IE just sees the common name. Cool. So now we have multiple things that can be in an X509 common name that are valid that will be seen as the certificate authority making an assertion of browser domain identity. This is not the only way we can do this. Another thing we can do is do what's called a semantic integer overflow. Now integer overflows are one of the most common vulnerabilities in software today. Programmers tend to forget that if an arithmetic operation gets large enough, it will actually loop back to zero, or loop back to the beginning. This is a common problem for memory allocation. You have situations where it's essentially, I need more memory, I need more memory, I need more memory. You know what, I don't actually need that much memory. And the system, the rest of the system assumes it has some ungodly amount of memory and everything fails. So we have an arithmetic operation. This is essentially what ASN 1 is doing with base 128, multiplies and adds. What happens if we make it add past 2 to the 64? What happens if we have 2.5.4. 2 to the 64 plus 3? Well, what happens is OpenSSL has a big num library. It deals with it fine. It actually does not have a boundary enforced by hardware. Netscape overflows. But it overflows just like it overflowed with the leading zeros. It renders to 2.5.4.3 but it does not actually render back to a CN. I.e. you just win. You get another CN. So 2.5.4, 2 to the 64 plus 3 is another way of expressing common name. I want to point out one of the reasons we had ASN 1 do it this way is because they didn't want to have to worry about canonicalization. They're like, look, there's uppercase common name, lowercase common name, all sorts of spaces and tabs. Why don't we just have a numeric representation of a number and that grammatically will be simple? Well, this implementation bug tends to throw that out the water. Now that being said, most CAs extract a common name and throw away the rest. Well, good. Is there anything malicious that we could get into a common name? Can't throw out my common name because that's actually what they're validating. Well, what's in a common name? You have an object identifier and a printable string and strings are simple. It's a tag, 13, a length, some number of bytes and then just simple ASCII text. What could be wrong with that? Well, it turns out there's 13 different forms of strings in ASN 1 and you can use the other kinds. Two of the really interesting ones are BMP strings, which are a variant of UTF-16, a Unicode variant, or then there's Unicode string, which is 4 byte Unicode, it's UTF-32. That means when I'm saying 2 byte and 4 byte, I mean saying 2 bytes per character or 4 bytes per character. Now, why is this interesting? Well, first off, there's a trivial read AV in OpenSSL's PKCS 10 parser. There's nothing more fun than messing around with this in one editor by hand and then seeing, oh, well, it just crashed. I wonder if this is exploitable. It turns out it's not. But here's what was happening. They were saying, we are going to advance through this string until we hit the exact byte where we are at the end of the string. And then if they had a 4 byte character, they would advance 4 bytes. So what this meant is, let's say your string was not actually a multiple of 4, it would want to terminate on the 8th byte but there's only, you know, 7 bytes in there. Or what is it? You basically miss the, you'd miss the terminator, excuse me. Little tired, need to drink. It's not actually exploitable. You miss the terminator, but you don't actually write any memory after missing the terminator. So it just reads off into a guard page and you have no fun. Ah. Now, fun with printable strings. There are two ways of ending a string with text. You can have an explicit length field, which is what ASN1 has. Or you can have a null terminator, OXOO. So-called C strings use null terminators at the end of them. What happens when you put a null terminator into a common name? OpenSSL deals with it fine. It actually converts that null into backslash XOO. So you end up with, say, www.defconn.org backslash X00 www. OXOO.com As far as the CA is concerned, this is a host inside of the OXOO.com domain. It will do domain validation against OXOO, which as the attacker I actually own. However, the browser, the browser stops at Defconn. So you end up with a Defconn certificate. If this is Netscape, and if I was in a particularly bad mood, or if I was Moxie Marlin Spike, who found the exact same attack, good job, man. I would have instead gotten this cert for just star null dot OXOO.com and just had a cert forever, if that would be great for every site. But I actually didn't feel like having those kind of bits on my hard drive. Something about my hard drive is getting leaked. But I still owe a beer. So, we actually have a lot of progress on getting null and CN fixed. Moxie was like, wow, you know, this is not actually vulnerable in Firefox 3.5. No, we've been working on that, dude. So, actually I do want to say, Moxie probably has the best exploit for all of this. Do you mind if I tell them? So, you might say, okay Dan, you can impersonate a website. What's the big deal? Well, it turns out Firefox downloads code updates over SSL. So, yeah, if you're on LAN, if your, you know, DNS is cache poisoned, if anything is in path, you launch Firefox, it goes to the internet over SSL and says, hey, is there any new code for me? It should have worked fine, but one of these other certificate authorities has screwed them. So, even though Mozilla has a reasonable certificate authority that would never do anything bad, whoever Moxie was dealing with actually was more than happy to issue a certificate that ultimately was valid for Mozilla as well. So, most CAs should be clean, but we really do want this stuff at this point, but we really do want this fixed client side. So, the latest NSS already blocks nulls. Firefox 3.0 will have it soon. Opera should be covered soon, and IE and Safari are testing their fixes at the moment. So, at the end of the day, what am I suggesting? What am I saying here? Should we just move everything to DNS sec and tell the CAs to go find a new line of business? No, no, you're not going to believe this, the suckers are actually useful. One of the really nasty problems that people keep trying to define a way, keep trying to decide isn't actually a security risk, are semantic name collisions. We have our elite attacks with null terminators, but you know, www.bank-of-america.com works fine for users. They don't care. They also don't care about certificate warnings, by the way. We have a lot of dreams about, like, users really were dreaming about a universe containing nothing but us. A universe containing nothing but us is an even more terrifying concept. So, there's a problem. Somebody needs to be out there able to assert that www.bank-of-america.com that should not get a certificate. Someone needs to be in a position to be able to say that this is a collision, a semantic collision, even though it's different characters, no human is going to see the difference. If you think it's easy, think about other languages, think about other countries. We've got the equivalent of these dashes in China for one of China's largest banks. The only people with boots on the ground, with local knowledge, with actual brand awareness, are actually these certificate authority companies. So they went ahead and they built something called Extended Validation, where they throw some really random crap into X509. It doesn't work wonderfully well because it's just not the right technology for it, but it allows the CA to express their special knowledge that they actually made sure this name doesn't look like any other name and in return the browser changes the user interface a little. You get a green bar. Now Extended Validation has gotten a lot of flack lately. It's gotten flack because while it is wonderful for defending against phishing attacks, somebody went off and said that it deals with the fact that a bunch of CA's have crappy issuing policies. It doesn't do anything about that. If you have a badly issued certificate the badly issued certificate can actually interfere with the Extended Validation version. This is by design. It is a pain in the ass to get an EV certificate and if you needed to go through that pain in the ass for every ad network, every analytic system, every image server, there would be no EV sites in the universe. So the perfect is the enemy of the good. The browsers did not actually design a barrier between EV and DV. So people are surprised by this. It was talked about publicly by a couple of guys, by Colin Jackson and Adam Barth two years ago. It was in my slide deck last year. Some CA's really did get out of sync though. They ran their mouth. They said, no one could ever exploit this. My assessment of Alexander Sodorov actually did some really cool demos with exploiting that lack of a security boundary. But there is no security boundary. So, there can't be. So what do we do? We do need to get the damn DNS root signed. Sorry, it has to happen. It will spawn a bunch of development where we can start using the really nice traits of DNS. We can start using the really nice traits of DNS to exclude insecure suppliers and to delegate authority effectively. We bootstrap other protocols, from SSH to IPsec to PGP to SSL. We put the hash of all of these certificates in DNS. And now consider, since DNS sec inherits DNS's exclusivity, you still have a cert. It still has the X509 GU that still gets the say extended validation. But other certificates will not work. The DV certs from every other vendor will actually be excluded. So you will have the best of both worlds. You will have the certificate authority being able to use the actual useful content they bring to the table. Or you can the actual useful stuff they bring to the table while being able to exclude insecure suppliers. So in summary, X509 is messy. Operationally, its lack of segregation and delegation makes it really expensive to use. Force is really painful decisions to be made. Technically the technology is really fragile. The orgs are doing the best they can. We got to give them better stuff to work with. That's what I'm working on with DNS sec. So, that's what I got. Nope, open for questions.