 What's up guys? Yo! Holy crap, another year, another DEF CON. And you know what, it's another DNS talk. Damn straight I got a drink. So um, man, can't say I really knew what I was getting myself into with that whole break DNS thing. But the DNS route is signed and people keep blaming me for it. More importantly, it turns out that this whole DNS sec route signing, I got a level with you guys. I pretty much was convinced any kind of DNS sec stuff was way too much work for pretty much no benefit whatsoever. No, it's actually kind of awesome. And this talk is about why. Let me show you something kind of cool. By any chance was anyone in this room at like my way way back in the day SSH talk? Yes, you guys at the old school. So check it out. It's not like I ever stopped playing with SSH. It's a really common thing when you're managing networks like in the real world, you're often managing some customers network. So here's me trying to log into, you know, root at some customer.org. And what does it do? It asks me for a password. Oh man, I got to like find this customer's password, call them up, notepad. Wouldn't it be great if I could just say, look dude, I'm Dan at remote sport.org. I'm trying to log into you root at some customer.org. Yeah, it's multiple organizations. Yeah, it's Federation. Yeah, it's something we as a security community been trying to build for a decade. Oh wait, that just worked. Yes. And what did I have to do server side? Hey server, you allow Dan at remote support.org. Done. DNSSEC is a lot more interesting than I gave it credit for. We've been trying to do authentication in Federation across domain boundaries for years. And with DNSSEC, with the root signed, we implemented it in about four hours. This is kind of cool. So we basically coined something called DKI, the domain key infrastructure. It's basically PKI, but this time it actually works. We can't do DKI, we can't do DNSSEC if it is in fact, as some people have been saying, oh my God, this is going to be a horrible pain to deploy. It's going to take hundreds of thousands of hours and hundreds of millions of dollars. We can't do what I just did if it's going to cost that much. But I get ahead of myself. There are four audiences for this talk, four groups that I think are in here. The user, the buyer, the builder, and the breaker. If you are a user, if you are someone who just wants your computer to work right and you're here because you're interested in what that means, I think the entire security community owes you an apology. We have been promising so many things for so many years. When you receive an email from the bank, maybe it's just me, maybe you should actually know it came from the bank. Telnetting into port 25 still works. This sucks. So I apologize. We failed you. We ask you too many questions. We make too many demands upon your memory. And we blame you. I was in a session earlier today where all I heard about was how users require education as if it was their fault. No, we have failed to give you what you need. And it's not because we're lazy or stupid. It's because we haven't had the foundational tools required to deliver a more secure experience. If you are a buyer, and don't be offended if you're not a buyer for the market terms, but let me give you the bottom line, budgets are going to go up because this stuff actually works. Ten years ago, we tried as a community to deploy public key infrastructure. There was a whole bunch of hype about how this technology would finally free us from passwords. It's ten years later, passwords ain't gone away. Now, our stuff from ten years ago did not work, but it's not like we have any less need for strong authentication. Our belief, our hope, is that DNSSec through DKI is the way that we're finally going to achieve all the promises of PKI. Now, if you are a builder, if you are someone who makes security products, we are all tired of your crap that doesn't scale. How much stuff have you sold that sits on shelves? Because it worked in the lab, it worked enough for the initial sale, and you ever notice how like six months later, the customer doesn't call you back and talk to you ever again? Yeah, yeah, that's kind of been the story of the last decade, hasn't it? A lot of crappy products have been shipped. A lot of devices have shipped with no authentication whatsoever. A lot of sacrifices have been made. You know, one of the things you find with SSL certificates is the browser's care, and everyone else just says, wow, this is hard, I'm going to turn that off. Half of all certificates on the internet don't even pretend to offer security. There's only about a million certs on the net, period. So it's like all the possible internet endpoints were running out of four billion IP addresses. We don't even have a half million secure endpoints. This is a failure. However, it's also an opportunity. It means we can do better. But the most important group here, and I think actually the majority of the people here are breakers. You know, most people in technology believe code is secure until proven otherwise. Yeah, y'all know better. By default, software is pretty much generally going to be broken. You're the community that looked at my demo earlier and said, did he just make DNS sec pre-auth in open SSH? Is Dan crazy? Thank you for noticing. I think it's time we get some work done. There's about to be some huge bets put on DNS sec, and I'm going to level with you. I don't want to wait 25 years for the next DNS bug. So you know what? We're actually pushing a radical transparency model. Started a company called recursion ventures. We're actually playing in this space. Yeah, so we are going to be backing an aggressive and public and open audit of all DNS sec and DKI technologies. If you're familiar with Justin Ferguson, he is one of the probably top five code auditors that I've ever met in my career. He is auditing L DNS, which is the best DNS sec library on the planet. We are releasing the pen test report publicly and not someday in the distant future. We are releasing it September 1st, 2010. This should be an excellent starting point for anyone else who wants to bash either DNS sec or the L DNS library in particular. The authors of the library and L net labs are fully on board. There may very well be a problem found in DNS sec, but we're not going to guess. We're not going to hope we're going to bash on it until we're happy. Now, some ground rules to doing some DNS sec work. We don't care about not inventing here. We can't have religion. We can't afford it. We have an internet fix. That means we have a problem that's bigger than any one person, any one organization, any one community, or any one country. We don't care about style. Skype's law is basically, you know what? We security people really bungled up the internet in 2001. We've got to froze it in time. You get HTTP and you get HTTPS and deal with it. I like elegance, I like theory, but I like stuff that actually works. Not just barely. Systems that barely work are barely deployed. Now there's a corollary. We can't care about historical precedent. You know why? Because it's not like it's actually been working particularly well. We're going to have to do things differently. Or, you know, we can just keep failing for the next 15 years. We do care about operations. We do care about that IT guy that actually has to wake up at three in the morning if the stuff fails. We are not going to secure the internet by calling people lazy or stupid. To be fair, that does define us as intelligent and industrious. Great for our egos, crappy for the internet. We are not going to win through moralization. Wag your finger at someone and think it's going to change anything. You're really not going to win through regulation because let me tell you, without naming names, I've seen a lot of certifications and I've seen a lot of compliance programs and I haven't seen a lot of competence in any of them. We're going to win this. We're going to win this the old-fashioned way. We are going to deliver a better product that works better, works cheaper, works faster, works easier. This is not like the status quo of security is exactly inexpensive. There is better that can be done by actual genuine people who want to run it. What if you don't think of security as something you bash people over the head with? What if you think of security as, man, this is actually kind of awesome? That is the goal of this talk, to show you DNSSEC for all the hype. Wait a second, I can build something with this. Some timelines. 18 months ago, everyone pretty much knew all of DNSSEC was crap from an implementation side. But 18 months ago, we basically said, okay, yes, it's crap, but this protocol that's gone through ITF for 15 years is actually not bad. It can be done safely, securely, easily. Well, we live in the future. We look at what we have and not just what the work we're doing. We have three open-source servers that are pretty good. We have three commercial servers that are pretty good. And pretty much any company in DNS is basically saying, man, don't worry about it at all. Just tell us what you want and we'll do it for you. This is good from a market perspective. This means lots of people are in this space. This is a stable technology. I'm just here to tell you all they can do what they're doing. This is where it's going. So first off, let me explain DNSSEC to you. It's not actually that complicated. And normal DNS, you ask a question, you get an answer. Or you ask a question, you get a referral. So you ask Alice, you know, hey, what's Jenny's number? And she says, I'll ask Travis. Travis said, you know, good Travis. Hey, Travis, what's Jenny's number? She says, ask Charlie. Ask Charlie and get apparently the wrong number for Jenny. What is Jenny's actual number? She keeps giving me the wrong one. So with DNSSEC, it's really quite similar. You ask a question, you get an answer and a signature. Or you ask a question, you get a referral and a signature. Now, is it really that simple? Mostly. Referrals now contain new keys. Before, you were just told where Travis was. You know, oh, you know, go ask Travis. He's down by the water fountain. Now you're told how to recognize him. Oh yeah, he's a skinny white dude in dreadlocks who's, you know, now the new chief hardware officer of recursion ventures. So welcome Travis, good speed. Computers can make stronger identifiers than people can. So we use cryptography, but it's just the same. You know, everyone always says, I don't understand public key cryptography. Look, it's really easy to recognize a face. It's really hard to smash your face to look like someone. That's asymmetric public key cryptography. Done. Is that it? Yeah, pretty much. Okay, there's some magic here and there with, you know, if Jenny has no number, lies. Records can expire and keys can lead to other keys. But a lot of the magic is optional, more than you'd think. And all of the magic can be implemented in an easily deployable manner. Now yes, the easiest thing to do is to call up some manager's provider and just say, hey, go do it. You know, failing that. I have heard estimates that deploying DNSSEC could take a hundred hours of consultant time per domain. Let's me show you how we would... Okay, I'm not doing a live demo in the middle of DEF CON. Hook up to this network. Are you joking? But this is what it would look like. You're just going to have to believe me. This is DNSSEC made so easy to deploy, you could do it on stage at a conference. So, first thing that we have, and I apologize that the text is small. First thing we have is your standard little name server. It's got, you know, 10 or 11 domains. You know, they're very small and whatnot, very simple. Kind of thing anyone might have. Okay. Step one, change the port on the DNS server from 53 to 50,053. Step two, launch FreeBird, the recursion ventures DNSSEC server. Note the lack of options or configurations or anything. You just run it. Step three, there is no step three. You're done. You know, once upon a time, once upon a time, web servers were very simple things. They ran static documents. You had a file system, everything you wanted to do. It had to be through there. And if you wanted to do anything dynamic, okay, you ran processes with CGI, you know what? Web services evolved. So are name servers. This thing goes ahead. It dynamically generates the signature. It'll dynamically generate the key material. Now, we're not entirely done. We do need to go ahead and tell, in this case, .org, hey, we actually exist. This is where we are. So this is how it looks. Yeah, let me talk about something else I'm not doing from DEF CON. So we go to GoDaddy. Say, hey, I got remote sport.org here. You go to name servers. You hit manage DNSSEC. You paste in this little record. You do a simple lookup. It comes back against the free bird server. Gives you the hash to put in. You say, go ahead and do it. You've got to wait 30 seconds. And then you're done. And then it's live. And then it's working. And then you can run end-to-end authenticated queries against remote support.org 30 seconds later. This is actually kind of cool. So why does this work? Free bird is an online key signer. Like SSH, SSL, and IPSEC, it depends on a signing key being available whenever requests come in. There's an alternative where a magic key sits in a vault and you truck it out every once in a while, you alter things in DNS. In our real world networks, we're changing stuff in DNS all the time. Free bird, for performance reasons, actually has a cache. So when it applies signatures to some records. So a record might be this IP address is, you know, the IP address for food.com is 1.2.3.4. Or I don't know, the certificate for food.com has a hash of AABBCCDD. Free bird will see what responses come back and will sign them so that a thousand requests for the same name will not cause a thousand hits to the encryption engine. Now DNSSEC was designed to allow offline key signing and that is awesome. The two reasons why this is the case are first, DNSSEC is old. I mean, DNSSEC was started in the 90s where high-speed processors and cryptographic accelerators simply weren't the kind of things that were available. Also, DNSSEC needs to operate at scale. So it needs to be able to simultaneously support the smallest to the smallest name server to the root operations that have a maximum security requirement to COM, which is just enormous. But you know, not every server should be run like the root. It's a big deal that everyone can be, but that doesn't mean should be. Because the reality is, the biggest thing that made DNSSEC such a miserably complicated thing to deploy was having to do some massive pre-computation phase. When you have some massive preload happen, it turns out empirically protocols get orders of magnitude more complicated. And the best example actually is PGP or GPG. The amount of work that those code bases go into to managing their key rings are literally 95% of what's going on in there with the other 5% being encryption, decryption, signing, and validation. It's enormous, and by going online, you get rid of the complexity. Now there's some precedent here. We did not invent online key signing. I mean, look at all those other protocols. DNSSEC has been quietly including support for this design strategy for years. Ben Laurie is the guy behind it. Behind at least some of it. There's even another DNSSEC server that does this sort of lazy signing. That'd be Power DNSSEC by Bert Hubert. What FreeBird has that's kind of interesting is that it uses the existing DNS framework, whatever it may be, and enhances it with DNSSEC responses. So it's just a proxy. It sits in front of your systems like a lump in the wire, and it signs. That means there's no operational impact. You manage your DNS just like you always have. There's no configuration. There's enough information in a DNSSEC request-reply pair to figure out everything that is needed in terms of the signatures involved. I wasn't sure it was going to end up that beautiful, but it turns out, yeah, it totally does. And it always returns the right answers. So you can have the world's most complicated name server that is trying to return video over DNS, and I'll still sign it. No problem. Implementation notes. Today it's a UDP port forwarder. You've got to change the DNS port. If you don't even want to do that, sometime in the next week or two, I'm going to implement what's called Linux MangleTableSupport. The name server will think it's sending an unsigned response, but something magic will happen in the kernel, and it'll be like DNSSEC on, DNSSEC off, DNSSEC on. So this stuff is fast. Well, look at me. I just wrote a few lines of code. The Linux kernel developers and lib-event developers are awesome. Neil's Provost is a badass. With a few hundred lines of code, you can today write a name server that will support 60,000 queries per second on stock hardware. Now, if you want to understand how fast 60,000 queries per second is, maybe a few years ago, that was all the queries that .com received in the world. So on one box with this API approach, you're able to do what com was doing a few years back. It's actually quite impressive. Now, we're not going to be that fast because we've got a backend to talk to, we've got to manage crypto, we've got to manage caching, but the experimental evidence suggests we are by leaps and bounds fast enough for all but the absolute biggest thing. And we haven't even tried to optimize. Freebird is open source because you're just going to implement it anyway. We should have code out today, but we wanted to get all the demos done. So if you want a preview of what probably has some horrifying remote code execution flaws, feel free and by probably I mean like man that's not a good use of P open. Uh seriously send an email to info recursion and you can make fun of me all night. Code should be out within the next couple of weeks. I am actually planning you guys heard about these pixel displays by any chance? Fully sunlight capable. I actually got one out of makershed. All I want to do in life is sit by the pool at the palms, get a pina colada, bust out the net book and hack like yes. That should actually dramatically accelerate development of the Freebird packaging. Uh as a note this stuff really is the 6 to 18 month timeline so your mileage may vary in terms of deployments. This is purely so you can understand wait this technology is pretty cool. Now Freebird's doing a whole bunch of stuff I don't have time to tell you about today. I'd be going on for a couple hours if I did. There's a bunch of obscura, there's a bunch of things people have kind of rung their fingers about about DNSSEC. Questions like how do you handle non-existent records dynamically? How do you tunnel records to the registry .org when say your registrar doesn't give you a web interface to be able to put what are called DS records in? What about time? How do you manage rollover and expiration? How do you keep clocks in sync? There's some very interesting problems like what do you do about time since everything has an absolute time. What I do have time to tell you now is this, all these problems are pretty easily managed. They took some work, they took some effort but we've got fixes for all of them and online the recursion.com site, they'll like the answers will be posted. But I want to focus this talk on hey this technology is going to be awesome for your applications. So okay, towards the domain key infrastructure perhaps DNSSEC is easy to deploy but is it in fact useful? Distributed authentication is only interesting if it provides end-to-end semantics. My desktop to your server or my phone to your phone and so on. You might say, but Dan I know a little bit about this stuff I heard that all DNSSEC does is secure the link between these name servers that I speak to but not like me in the actual end server. So what's going on here? Well it turns out that was the original model of DNSSEC. They actually figured your name server would do all the hard work and then it would send you a little bit called AD. And AD stands for nah it's cool I checked it for you. Doesn't actually stand for that but it really does. Look, I like Starbucks. I've known people who work for Starbucks. I like their coffee. I'm not trusting Starbucks to tell me whether it validated the certificate for Bank of America. Not gonna happen. There's no application on earth that's gonna alter the user experience based on this little bit of context. Give me the proof or go away. So we have some normal end-to-end modes. First mode is called chasing. When you ask for www.food.com it's said a bit called CD called checking disabled. And what you will get back is the answer and a signature saying www.food.com was signed by food.com. And then what do you do? Well you go back to food.com and you say well what were you signed by? And it says well I was signed by com. And you say well what about you com? What were you signed by? And it'll say well I was signed by the root. www.food.com to the root. And in this model you only talk to your local name server. Now there are two problems with this model. It works about 90% of the time but that's not enough. A 1 out of 10 failure is still operationally too expensive. The first problem is that it might get blocked by your local resolver. The deal is in DNS it's a lot of work to bounce around the internet to go from root servers to com servers to com servers I mean it takes some complexity. And DNS was designed in 1983 when such complexity was unimaginable to have on every single computer. So what they did is they said okay we'll take this hard work and we'll put them in these magic boxes called name servers. And these magic name servers they'll go ahead and do all the run arounds. Well what is happening in this situation is the box that's doing the run around. Not only might we not be willing to trust it to go ahead and do DNS validation but it may not know how to send us back a little bit of extra information about the key material so that we can do it. In other words it ain't doing it and we ain't doing it so it ain't getting done. And so that's kind of a problem. The other thing that might be a problem is round trips. If I have to keep going back and forth and back and forth with my local name server that's actually a lot of round trips and it can be slow. And as we know from experience if you make a web browser depend on too many things that are slow it will just not do what you ask it to. So in general almost all web browsers don't go ahead and check to see if a certificate has been revoked. Someone's checking if search is revoked because apparently there's a couple billion checks a day but your average web browser is not one of them. Revocation is a bit of a lie in X509. What we're doing about round trip fixing in DNSSEC and this is a project of Paul Vixen in mind. It's called SuperChase. In SuperChase when you ask for the when you say hey give me some signing information for www.food.com in SuperChase it gives you the path all the way back to the root. Why? Because it has to know it anyway if it was going to do the validation it knows the chain. I'm just saying hey give it to me as well. And so we figured out how to make that happen and it's pretty straightforward. Doing it's about 10 lines of code in LDNS. Part of the free bird release is going to include sample code you just say chaser spooky.navy.mil.org and you in fact get a path all the way back to root. Done. End to end. Another method is called tracing. Instead of chasing where you go up, tracing you go down. You're basically taking that magic box that does the running around the internet. You're embedding that in random applications with what's called LibUnbound. LibUnbound is the name server built upon LDNS. And it itself is about, it takes about three lines of code in LibUnbound to do a secure resolve. It's super straightforward and easy. Now some issues chief among them you have, if you have a situation where every device is going straight to the root you'll cause the root to melt down in a pile of flames. What might make that acceptable or at least make things better is if the devices are actually caching information for serious periods of time and only updating the information when it changes. The root information doesn't change much, common information doesn't change much and so on. This by the way was the problem with DNS curve. Dan Bernstein's approach is brilliant. You guys have no idea how much time I spent arguing that people should do his stuff. However, if Dan Bernstein's approach the only way to get end-to-end trust was to bypass local caches all the time always go to the root, always go to the com servers, they would have melted down. And of course those middle boxes, more stead hotels, there's nothing worse than hotel networking. When you're at a hotel be glad you can go to Google, it's surprising. Hotel boxes will still mess with tracing operations. So HTTP is the universal tunneling protocol you can actually do DNS over HTTP. DNS over HTTP basically involves doing get requests with DNS in the actual URL that is requested. Freebird does implement this. Obviously you can tunnel stuff over DNS over HTTP because everyone tunnels stuff over HTTP. The only question is, what's the performance impact? So, what do you guys think? Tunneling everything over HTTP is like a 10% hit, a 50% hit, an 80% hit. Yeah, well for whatever reason it seems to be faster. What? Yeah, no. 3200 queries per second with UDP 4,000 with TCP. Paul Bixie thinks I'm wrong, thinks there must be something wrong with my tests. And that's okay. Quote goes, being wrong just means the world is more interesting than you thought it was. But even with a significant penalty, super chasing over HTTP should be a, if all else fails, get me this information approach that we need. And so we're actually going to go ahead and start running a DNS over HTTP endpoint on the Internet within the next couple of weeks so that the libraries that are out there, if all else fails, can always get stuff resolved. Because that's the only way we're going to get to 100%. Wrapping. So I talked about chasing, I've talked about tracing. I've talked about chasing, tracing, packing. This is wrapping. Wrapping is an idea of this crazy Kiwi by the name of Brett Watson. And what Brett said to me is you have to be willing to separate the content of DNS from the transport of DNS. Now this was a fairly profound point and it led to an interesting concept. If you look at X509, X509 certificates always contain high. This is a certificate for www.food.com, food.com that's signed by Barrisign or Thalott or Godaddy or whoever. So there's a chain from where you are all the way up to some trusted certificate authority. X509 can also contain the DNS sec chain. SL is already moving X509, so we do DNS over X509 over SSL. You know what totally passes through hotel mini boxes? SSL. Also, we get really high performance because it's delivered in line without any kind of external query having to happen. Now, to implement this, what you have to do is you have to do just like super chase, you have to extract all of the keys necessary in order to resolve a zone and then you have to shove it into an X509 certificate and validate it during the actual certificate validation. Now this would have been a lot of work for me. So, Adam Langley at Google may very well have sent me a private, unofficial build of Chrome. That is getting HTTPS. It's got the lock, but when you look inside that certificate has a DNS sec chain enabled. Full DNS sec inside of Chrome was up. So, I want to be clear, this was private, this was unofficial, this does not at all represent a commitment by Google to DNS sec, DKI or X509 certificate embedding. This is just Adam and I seeing what was possible. So, that I think it's a good idea to start talking about actual applications. Where do we implement DKI? What I showed you at the beginning of this talk was SSH, specifically FreeShell, a federated identity system for open SSH. It's based on the idea that N nodes should authorize and validate identities and not public keys. So, you're not P times Q. You are at least an email address. Today, the way that this works on the server is you go to the authorized keys file and you provide a list of email addresses that are allowed to log in. When someone tries to log in, they have a special syntax that they use for their username. That syntax is parsed and if the declared user is actually someone who could potentially log in on that account, DNSSEC is queried securely end-to-end to say, all right, dannatremotesport.org wants in. dannatremotesport.org, if he had the right private key on his system, yeah, we'd let him in. Let's go to DNS to find out what public key to validate. So, that's what it is today. Tomorrow it's going to be an actual LDAP back end, sort of like this Fed SSH package out there. And you'll be able to say, let everyone in the vendor.com group log into the machines at somecustomer.org. This is going to be very, very nice. Now, I'd like to go a little bit philosophical into why this is a big deal. People have been selling what's called federation for years, federation being the ability to authenticate users outside of your organization. All of the stuff has been terrible. Reason why is we have a couple of choices. Our first choice is M2N complexity. That means every company that wants to authenticate someone else has to make a deal with every other company who wants to authenticate someone else. It is M2N complexity that gives us things like on Gmail, if you receive mail from eBay or PayPal, then you get special user interface. Why was it one email provider and two possible senders because the management load of getting more done was too high? Then there's the problem of risk of the king maker. You always have a situation where one group says, all of you, why don't you just trust us? Everyone trusts us and we declare who is who. It's great and it's wonderful and it turns whoever is in that position of the centrally trusted person into a monster. It happens every time. And so the final approach and this is what we see in the existing certificate authority system is key bleed. It's almost there to be a god so you end up with everybody's god. It's not any better. What is interesting with DNSSEC is that the DNS route is run by ICANN. And for all the controversy of ICANN, this is a group that is massively constrained. They are constrained by a technology that delegates as soon as possible. They are constrained by politics of the worldwide nature that you cannot imagine. Getting things done is a tremendous amount of work. That is not a bug. That is a feature. That means you have a neutral overseer. Net neutrality began with ICANN of all places. It's kind of crazy. So what do you end up with? DKI gives us federation that actually works. Because you have the trusted route that the technology needs but you have the controlled route, the managed route, the governed route that the politics require. So what do we do? We're going to go ahead and manually hack in LDNS or lib unbound into each package. One by one by one. Well, you know, maybe that might be useful for some things. It's definitely a way to get the best application integration. But you know, Linux and Unix, everything is using OpenSSL. Specifically, the OpenSSL call X509 or verify underscore cert. This is a nice and self-contained library call. What could we possibly do with that? So, another thing you're releasing is called freeload. Freeload adds DNSSEC transparently to existing applications. If it validates a certificate, we will make it validate a certificate successfully using DNSSEC. There is some prior work. Libval Shim from Rust Monday at Sparta will actually go ahead and it also transparently applies itself to applications, but it does so at the DNS layer. It makes sure that applications get the right IP address. That's nice. There's a million ways to attack IP. I'm sorry, that's just how it is. The other thing that Rust Monday's code does is it assumes that if you're validating for www.food.com obviously you have the food.com certificate. Because when this code was written, the root wasn't signed. With freeload, freeload is operating in a different layer. It's saying, look, let's take the software out there that is actually trying to be secure. It's actually trying to make an encrypted end-to-end safe link. Let's take its validation layer, which already has handlers for errors if validation fails. Let's take the validation layer and replace or augment it with the authentication layer of DNSSEC. So for example, you ever gone ahead and used these command line web tools and said curl some address and you get back this big error and the last line of course is if you'd like to turn off curl's verification of the certificate use the dash K or dash dash insecure option. Now think about what this means. At some point they said the dash K option and people missed it. So they have two points in the documentation where they say here's how you turn off the security. That is a system that has failed. Now we're going to go ahead, we're going to LD freeload freeload.so and bam, this is the story all about how my life got twisted upside down. Works glorious. If we go ahead and we turn on debugging we say export DNSSEC debug equals one. What we see is a lookup happen to what we call the deliberately incorrect schema. We look up SL absolute www.hospitallink.org it has returned this hash 5e09 05 b and so on and that is actually the correct hash of the certificate seen at that address and validation occurs just fine. So that's all that's happening. You have this silly little value in DNS. It's wrong. We're working on the right way to do it. If you go ahead and you change the value you make the hash incorrect poof, curl doesn't work anymore. It's not enough to do a DNSSEC resolution, the hashes have to match. We set the information back we go ahead and we can use curl we can use wget, the same code, the same configuration works for all the protocols. Now, all open SL apps means all open SL apps. So you've got postfix as a mail server setup postgres as a database, mysql as a database, Apache. Now why would it be interesting to alter certificate validation in Apache which is a web server? We've had the capability to in web browsers to do certificate client certificate validation. Meaning it's not just the server that has a cert the client has a cert. But today really getting a certificate issued by one site or a smart card issued by one company to work anywhere else yeah good luck with that with DNSSEC it's trivial. You get a smart card we get a request it claims to be an email address you go ahead and find out so what is the what's the public key associated with this user and the group that issued the smart card is the group that hosts the public key and now that public key works on every server on the globe works like a charm. Welcome to domain key infrastructure but I'd like to go ahead and stay focused on browsers open SSL is great but browsers don't use it. Internet Explorer uses crypto API and Firefox and Chrome use NSS also there is no LD preload on Windows there's just no way to go ahead and hack an API in Windows. So what are you going to do? HTTPS proxy this is kind of neat actually I had no idea this was there PDP it's put out this thing called htbservers.py it's based on the work of Azuki Hishao Andres Rianjo and Dave Eitel and basically the web browser has since the beginning had what's called the SSL proxy or secure proxy and what that does is it says every time an SSL connection is attempted to be made please do connect www.site.com Now this is actually very nice I mean this is a channel by which I can see what the browser wants without having to push any code in there I should really build a proxy so we built a proxy it's called foxy it is a remote validation proxy for production browsers basically what you do is you provide the browser a custom root certificates the browser knows okay I'm going to trust whatever this random piece of code tells me when the connect line comes in we know the domain the browser is expecting to authenticate too it's pre declared to us so we basically gin up a certificate at that point we allow the connection to come in and then we hook it up to an SSL connection of our own out to the internet now here's the thing we are still going to we are not actually going to certificate validate the cert out there so we don't want to make these connections unless they're good we're outsourcing certificate validation we're not disabling it entirely however since we're outsourcing certificate validation to open SSL and open SSL is running freeload we inherit dnssec for fun for nothing and just so you see what this means there's the browser lock from dnssec in internet explorer there's the browser lock in firefox from dnssec browser lock in chrome no private build it just works done move on now here's a neat trick this this is a bad idea of old style there's something very interesting we can do once we've outsourced validation doesn't involve dnssec barely even involves dns wouldn't it be nice if we could boot strap trust only with a domain name what if we put the hash in the url yeah it's not a good idea but it is actually something that works so basically what we have here is hdbsslh bighash.www.pba.org if you can go ahead you can actually even extend this to you can put a hash in front of an IP address and the server will say well I connected to that IP here is the hash of that IP I will let it through there are lots of reasons why this is bad but if you really really need to bootstrap something and you don't have any other way of declaring what certificate you want to use this is actually not the worst way to go now as funny as this was actually inspired by this old file system called the self-certifying file system someone else made this link it's called sfshtp securing the web with self-certifying urls it was done by some guy Michael Minsky Michael is my middle name this was done in 99 there are some scalability issues what do you do if the certificate is lost but like I said there are some situations where I think it will actually be really useful to be able to say please bootstrap your initial initial connectivity here's the url and by the way the url contains the hash of the identity you're speaking to and hey it doesn't have to be a good idea so around this point you might be thinking now is the time to get rid of the certificate authorities new the CAs are in fact more critical than ever there are domains bankofamerica.com proctorandgambel.com and so on and there are brands proctor and gamble domains and brands are not the same thing if you go ahead and you look at what's done to actually offer value they have gone ahead and done a program called extended validation this isn't just bankofamerica.com this is the bank of America corporation that's great because that is something DNS is not going to be able to do extended validation has some problems I can't go into full depth if you want to know more look at Mike Zussman and Alexander Zodorov's SSL rebinding attacks from and the basic problem is EV only protects you against phishing attacks if EV only protects you if the attacker doesn't have a non-EV cert as well so a bad guy who goes to lend a certificate check and gets a certificate for www.bankofamerica.com he can go ahead and interfere with green bar communication that's just the nature of the technology but DKI fixes this the exclusionary property when your DNS domain is registered through Enom GoDaddy cannot interfere with it when your X509 certificate comes from Verisign GoDaddy can it's because there's no actual link no actual forcing function saying when Verisign's got a cert GoDaddy can't but you do have that in DNS so what you can do under DKI systems is you can say the only canonical certificate www.bankofamerica.com is the extended validation certificate issued by Verisign and any other certificate I don't care who it's signed by that cert's not valid that ends the EV attacks and while yes there are attacks under EV where there are say invisible subdomains things from content distribution networks that load stuff we can go ahead and we can use the same stuff it is in fact cheaper with those sub machines SSL certs than it is to go ahead and go ahead and get SSL set up on them normally so exclusion works there too before we finish I do believe that we promised users we would do something about email now I don't know about you guys but I am sick and tired of trying to find people's PGP keys and worse of assuming that what I get back from the key server is valid wouldn't it be great if you could securely retrieve them via DNSSEC well we've begun a project it's called free GP and it actually is porting end-to-end DNSSEC lookups to GPG you might notice this is a little hideous I've had to type echo foo GPG no default key ring key ring temp GPG random random encrypt armor auto key locate test at pba.org it's so user friendly GPG really does not want to be patched to do this it has a bunch of DNS code in it it's only present on the encryption side the amount of rework that's going to be necessary to make this happen effectively this work needs to be done inside of enigmail it's hideous but alright I started it a little then I went ahead and looked at something anything else decim decim is a scheme for retrieving public keys not certificates for domains outside of DNS it is pretty trivial to get end-to-end validation out of it for in terms of eh so its goal is this mail server and that mail server want to know okay Google wants to know it's getting mail from the Bank of America server the Bank of America server signs all of its mail with a particular private key and DNS validates the mail only delivers it if it validates that's cool that's nice there's no real user experience designed into it right now it's mostly an anti-spam system super trivial to do DNS sec with it an ITF is looking at making that happen but I'm not really a fan I want there to be a user experience and the best user experience is out there and that ain't saying much is um Esmime Esmime is the email encryption and decryption buttons you see inside of Outlook and inside of Thunderbird there claims to be a plugin for Gmail it doesn't verify it's dead to me Esmime has some key management problems this is an understatement but of course it has key management problems it's based on certificates even if you have the greatest enterprise CA in the world meaning you have wonderful systems for sending email and getting everyone in your organization to have certificates Esmime has a problem which is some cheap little shop on the internet has root certs and they will go ahead and ship a cert for any email address if DNS tells them they're supposed to and you know nothing could go wrong with DNS so can we fix this actually can we we are able to hijack OpenSSL because of LD preload we are able to hijack the browsers because of secure proxy how are we supposed to hijack crypto API the only extensibility point inside of Windows that we could find lets you reject certificates but not allow them it doesn't let you say accept a certificate that's self signed and we could write an Outlook plugin but who wants to do that there's another trick but at least smash like one beer is not going to do it so I guess we're host right raise your hand if you recognize what this code does anyone I'm just going to hope that it's byte temp jump size equals 0xE9 0x90 0x90 0x90 0xE3 mem copy jump temp jump size there's some virtual protect in there alright so API hooking is not just for World of Warcraft anymore yeah yeah most people use these tricks to hack World of Warcraft or we're going to hit crypto API and Outlook because damn it I've wanted it to work that bad it is possible to inject code into any process to alter how it works we've built FreeCappy which is DNSSEC validation for Microsoft crypto API crypto API has a function called cert get certificate chain if it returns true the chain is valid the call receives all sorts of interesting context about the certificate being validated I'm not that much of a binary hacking guy so imagine my surprise to find out when you inject a function with full symbols into a closed source application like Outlook you get full debugging symbols at that particular point so here's the certificate in the middle of Outlook with all of its debugging information valid awesome so what are we going to do so we have this signed email here from danatthebank.org not exactly the most compelling image you know look at those 16 pixels throwing the mark of award of validation what we're going to do is we're going to add a checker this is remotedll.exe it's not like I could have written this manually but I thought if I'm going to use the World of Warcraft approach I might as well use the World of Warcraft toolkit also the website is securityexploded.com and I'm pretty sure this is going to security explode this guy's head I was in what slides so we're going to go ahead and we're going to inject our own certificate chain into Outlook and when we do this well first off we haven't done anything with DNS certificate validation is attempted it's a totally valid certificate but there are problems with the signature check the signature button so we get this big red line look at that user experience awesome now what we do is we go ahead and we take the fingerprint of the canonical certificate it's going to be used to sign mail from daniththebank.org and it's you know 46OC1BE3 we are going to shove that into DNS 46OC1BE3 now this next time we validate the certificate this value is going to be securely extracted from the DNS it is going to match the certificate used to sign that email and the email will now find this is now the only certificate in the world from any certificate authority that can be used to sign mail from the bank that's actually not something we've been able to do before never been possible now you shouldn't be that impressed because it's 16 pixels who cares what user is going to give a crap about that you ever wonder why they're giving you so little visual information I can tell you under the normal SMI model we have had so little assurance so little validation that what we're seeing is legitimate so what we have is when the certificate validates we put a few pixels on and when it's bad we're like eh we can do better we can strongly identify email senders now we can strongly identify the brands what if that certificate that the DNS sec was validating what if that certificate was an EV cert what if you weren't just getting mail from dan at the bank.org what if you were getting mail from Dan at the bank incorporated and the green bar experience from the browser actually showed up an email we would be able to tell users legitimately when you receive an email from the bank someday soon you will know it came from the bank conclusion oh go ahead so DKI is coming get on board or don't but here's what we're delivering for you to see we have shown you that DNS sec can be deployed in two minutes we have shown you that we can achieve end to end security no matter how messed up the hotel network happens to be we have shown you federation for probably good federation for the first time in your career we have shown you how every open SSL application can use this technology using a simple LD preload we have shown how real browsers are going to have real useful experiences with this tech and we've shown you how certificate authorities and extended validation are going to combine with DNS sec to finally give us secure email that is what I've got get to work building get to work breaking