 OK, thanks. So first of all, briefly explain why we need DNS second instead of the regular DNS, though most of you people probably already know that. We'll spend some time on how it actually works. I'll explain how to use it with bind. Then I'll show you how in the Netherlands, there's an experiment going on on how to actually deploy this. There's a shadow system running that actually works fairly well, and hopefully will be integrated with it in the year into the standard NL3. And then I'll talk a little bit about the tools on how to manage a lot of DNS secure zones. In part two, after the break, I will talk about opportunity encryption, what exactly it is, how you can install it, how you can protect yourself with it. And I'll talk a bit about WaveSec, which is our solution to actually encrypt all your wireless traffic, which we'll also be deploying here at Defcon. So if you want to be secure from all the weird people out here, definitely listen to the WaveSec bit and secure your laptop. So one of the problems with DNS is that basically everybody is involved. It's not something you control yourself. You only control part of it. But how people get to you is completely in other people's hands. This is an example of www.freesone.nl. I've just picked the organizations I've found while sort of traveling the organizational view. And we can see that there's a lot of places where things can go wrong that are completely outside your own control of your own zone. It starts with the root registry. Whoever it is today changes every few months. Internet, Verisign, IANA, whoever it is. Then we get to the root servers. Many people, there are quite some root servers out there. They're more than 30 now that they're using Anycast. There are a lot of things that could go wrong with the root servers that are generally reasonably OK. And we get to the CCT-LE servers where things can go wrong. In this case, for the .nl, we're talking about the domain registry in the Netherlands. Then we get to the bit where your packet will have to go through all the BGP routing structures, which unfortunately is not yet protected by any good secure mechanism. So packets can get lost there before they even reach your zone as well. And then we finally get to the register of the Fris1.nl and the reverse space where things can go wrong. And then you get to the ISP of Fris1.nl, which in this case is actually me. And then we get to the registrant. So in short account, about 23 organizations, plus everybody who can mess up the BGP routing, that can actually get to your domain or perhaps hack into things before they get to your server. So no matter how secure you are, even if your server is unackable, before they get to you, you're depending on like 20 organizations. So this is a problem that needs to be fixed. And DNSSEC is meant to fix this. So this is a quick overview of actually a query. I didn't do the layout very well, I'm sorry. Basically what happens when you ask for a www.fris1.nl, you'll get to the IP 193.1.1.10.1.5.7.9. And if you look at how it actually works from the start, your laptop uses a file if it's using a caching name server, as the root servers, which is a hardcoded list, gets a root server, asks for the name server for .nl, gets an IP number, grabs some glue, continues, gets to the domain registry, which is in Amsterdam, gets another IP number and some glue, continues on, gets DNS record for Fris1.nl, gets NSXDNet.nl, plus some glue, and then finally, that name server actually has the answer that we want. www.fris1.nl is at 193.1.10.1.5.7.9. So these are about eight questions plus three, if you want to verify all the glue that you get to forward servers. There are a lot of things where this can go wrong. To sort of categorize the vulnerabilities in DNS, there are roughly two kind of vulnerabilities. One is the integrity of the data, as somebody actually is somebody messing it up while it's in transit, as somebody doing a spoofing fake packets, filtering out, sending other things, that's one part you need to protect. The other part is the guy who's answering to my query, actually the guy that's responsible for it, and it's the guy that's supposed to answer the query, or is it just some weird guy on the blog. So these are some of the things that you need to secure that are somewhat addressed by DNSSEC, not all of them. First, you have the DHCP server in your network. Once you get your IP, you have to know that you're actually talking to the right guy. You'll find out here that that's often not the case. You have to trust your resulfer, which might be difficult as well if your resulfer is half a planet away. You have to trust the communications to the resulfer. The resulfer has to be secure. And also the name server to name server communication actually has to be secure so that if changes are made, that it propagates properly and is protected. The DNS spoofing can actually happen from the internal side, but also if a server on the other end of the planet is hacked, it can just give you other answers. If a name server is hacked of whatever, ican.org, then it will just give you valid answers. But it might not be the people you would expect the answer from since they're hackers instead of the real people. OK. To the sound technician, apparently on my right, the people have difficulty hearing me. So if they can do anything about it, thanks. I don't think there's much I can do here. So any more questions that I missed, or can I? OK, I'll go on. Yeah, yeah, yeah, go on and ask questions. But if I missed it. OK, just OK. So we have to secure the client resulfer communication. So I'm sure nobody's here using any resulfer that's not on their own laptop. If they're really going to be in deep shit, you can just not trust any resulfer out there. The best thing to do is to just run your resulfer, probably DNSSEC can wear a resulfer on your own machine. That verifies all the queries, because you absolutely have no clue what's being rewritten during the time on the network. The security communication is between two name servers. Depends on what you want to do. If the zone itself has been secured with DNSSEC, then you don't carry too much that things go over the wire in plain text because they have signatures that do it, and you don't really need to further secure it. If somebody would tamper with it, then the signatures are wrong, and you can actually detect it and not serve the data, or the client will detect it and not believe the query. So even though it's strictly not necessary, once your zones are secure, you can, of course, still secure it somewhat. But there are other ways to do that as well. And of course, you have to be sure that your server is very secure as well that it's not hacked into. There are basically two ways in which you can secure the name server communication, which is also used actually for client name server communication. One is T-SIC, the other is 6.0. T-SIC works with pre-shared key and was like a sort of mini DNSSEC when people started out writing this stuff to secure the name server to name server communication. It wasn't very popular. Most people just secured the IP layer, set up an IP stack tunnel, or actually didn't worry about it, or use SCP to propagate those own changes. So T-SIC's not very much in use, probably it's not very useful, especially since it's using pre-shared secrets. You definitely cannot use it for clients to name server communication. The other one, 6.0, is based on public key cryptography. You can actually use that to secure some things much better. That's especially useful for dynamic updates from your laptop to update reverse tree. So DNSSEC basically comes with four new record types. The key record, which is the key used to sign everything, the SIC record, which actually contains the signature, the next record, which I'll come back to later, but it's used to securely say that something does not exist, and the DS record, which is meant to, which is used to build a chain of trust between parent and child. And there's a new flag in the query answer that's the authenticated data flag, which actually tells you whether or not the query was resolved securely. So mind you, do not use it, do not put any trust in it because it's just a bit and it's not protected by any signature so anybody can set it. So just see it as a debug flag only. So this is the standard syntax of the key record. It's the label first, the TTL, IN, key, then we get the flags, protocol, the algorithm, the key material. You can see here it is the key record for freeze one an hour. You can see it's protocol's DNSSEC, you can see the key material in there, the algorithm, it's fairly straight onward, be aware that you can have multiple keys, which I'll come back to as well. The only thing to note now is that they've restricted the use of the key record, so any protocols you're supposed to only use the DNSSEC and not any other value, so it's only type three is allowed. This is the signature record. The types covered, algorithm, number of labels, original TTL, expiration and inception of the signature. It's very important that there's actually dates in the signed signature, sorry, in the signature, because otherwise people could do replay attacks. If you sign something and someone stores that record and uses it a year later, it would be valid because you've signed it if you're still using the same key. So to prevent replay attacks, it's not enough to just have a TTL and expire it, you actually have to say the signature's only valid between this period of time. Again, you see here there's a signature over the two NS records. Also signatures are also based on the type, so if there are two NS records, you'll have one signature over all the NS records. If you have five MX records, you'll have one signature over the five MX records. Then we've got the next record. The next record is basically pointer to the next alphabetically sorted record in the zone. Why do we need to do this? The problem is if somebody is querying for a record that doesn't exist, how do we tell it like this record doesn't exist with a signature? We basically need to sign our answer. It's not enough to say, well, the record doesn't exist, go away. We need to actually say, here's a signed piece of data that says that the data you asked for is not here. So the way that people came up with it is to actually point to the next valid record in the zone. So if you look in the example you see alpha.freezone.nl is the next record that comes after that is gamma.freezone.nl. And the records that are actually in existence for alpha are NS, SOA, MX, SIG, KEY, and NEXT, which I guess the NS record I should have left out because alpha's probably not the name server for Freezone.nl. So now, if somebody's asking for beta.freezone.nl, they'll actually get this NEXT record back, which of course has a signature. So this signed record then says, you've asked for something and it fell somewhere in between alpha and gamma, but we don't have it, it doesn't exist. So now they know securely that beta.freezone.nl does not exist. Update from December is that the key record was limited to only use the key record for DNSSEC. So they decided to split up the key records because they were afraid that there were too many application keys going to end up in the APEX of a zone, so they decided to use a different key type for all the applications. Not everybody was too happy with it. I don't think it's really necessary because there won't be that many keys in the APEX of a zone, maybe an SSH key, an IPSEC key, and two DNSSEC keys, but that's about it. So yeah, well, the ITF decided on this by consensus, so we're stuck with it. So basically key records are only usable for DNSSEC. If you want to do something else, you'd have to make your own application key, which many name server software versions will not support yet, or you have to stuff everything in a TXT record and use your own format within the text entry, which is actually what we've done for FreeZone. So this is an example zone, I'm not sure if people can read it all the way in the back. This is a stripped-down version of FreeZone.nl. You see SOA record, two name server records, an A record for the website, and one MX record. So this is the unsigned zone. This is what it looks like when the zone has been signed. First of all, you see that the entire thing had to be sorted. This is, of course, because the next record has to point to the next alphabetical record, so first thing you do when you're signing a zone is actually sorted before assigning all the entries. So you'll see there's a SOA record, there's a signature over the SOA record, there are two NS records for the signature over the NS record. There's only one MX record and the signature. You'll see two key records, not one, but a signature, and actually both of those keys have been used to sign the key record, so you'll see another signature. I'll come back to that in the next slide. And you'll see the next record pointing to www.FreeZone.nl and the signature, and then we see the entry for www.FreeZone.nl, and one thing to note is that the next record for the last entry actually points to the first entry, so you see that the next record for www is actually FreeZone.nl, the Apex again. So now we have a secure zone. So now, even though your zone is secure, now you actually have to make sure that people delegate to you properly, and that has some problems. The parent should securely delegate to the child zone. However, the parent does not have a key to sign anything, and in fact, the parent shouldn't sign anything anyway for the child, because it's the child's responsibility. Where in the regular DNS, you would get a non-authoritative answer saying basically, well, go try here and don't hold me responsible for it. For DNSSEC, you have to be slightly more secure, so you have to basically go there and then somehow we will give you a pointer to check whether you're actually there. And that's where the DS record comes in. What you see here are all the entries for FreeZone.nl at the top level, nl domain name server. You'll see two NS records, and you'll see a DS record, and you'll see that the DS record is signed. So what is the DS record? The DS record is actually a hash of the key of the child's zone put into the parent's zone. The hash is signed saying that the parent believes that that's truly the key of the child's zone, and you'll see that it did not sign the NS records for the name servers, because that's absolutely no clue about that. The only thing it knows is that wherever you end up with, if the hash of that key is the thing that's in my DS record, then you're at the right spot. Sorry? I'm sorry, I can't really hear the question very well. But this is part of the nl zone file, what you're seeing now. So these are the only pointers to FreeZone in the nl zone file. Actually, there's one record missing, which is the next record, which points to the next entry, whatever, g something. This is what's in the parent. I did not discuss yet how the parent actually knows what to sign for the DS key. That's something that has to happen either out of bound or in bound. There's some protocols for that, but I'll get to that a little bit later. So once we have this delegation in place, we can just chain everything together. So the nl key in use is actually also signed and used by the top level, by the root server, which has a DS record over the nl key, if everybody would be using the NSSEC, which unfortunately they're not yet. So we have to come up with a way how to deploy this partially when half of the world is secure and the other half is not secure. So the way to do this is to basically say, this is a key, this is the entry point for that key, and we trust it from here. I see that the key record in the below is actually not very visible. But basically you have a trusted key statement, which you'll probably see in the next slide as well. Basically configuring your name server to say, this is the key for dot nl, and we trust everything from it below. So everything should be signed using this as the start of the chain of trust. So one of the problems we then have is, okay, so we have a key and we secure everything and everybody trusts our key, but what if something goes wrong? Keys have to be recycled at some point. People can just start some super cluster on trying to brute force your key. We don't want to use two large keys because we're gonna have to do lots of CPU and extensive operations. Keys can be stolen from the machine. Lots of things can happen. So at some point, no matter we like it or not, we'll have to replace the keys. So how do we do this? The parent needs to be securely informed. So we can't really automate this and say, hey, this is our new key, go ahead, use it. And then there's also problems with the key records are of course cashed in out there. So at some point we need to make sure that if we change the key, that people do not have the old key while they have the new key and they can't verify the signatures anymore. And one big problem there as well is that you want to make sure that there's the least amount of interaction between the parent and the child, especially if it's out of bound action. You don't want every month to call up your domain registry and say, hey, I've got a new key, can you just verify it over the phone with me? So they came up with the concept of separating the tasks of the delegation. So to fix the DS record, to change the DS record, use one really big key that's secure. You don't need to communicate as often to your parent. And one zone signing key for your own zone, which you can just recycle whenever you want without informing your parent. So basically there are two keys, the zone signing key, which is fairly small and a key signing key, which is a little bigger. These bit values are, it's what's currently used in the experiment. A time will have to tell where they're not, it's a good practice. So one way of these two keys, how does it work? First we've seen the normal situation. I've tried to abbreviate it here a bit. The parent has a DS record, O for the key signing key. And the child has the key signing key, the zone signing key. And then the key signing key actually signs the key signing key record, the key signing key and the zone signing key. And then the zone signing key actually signs all the data in the zone. So now if somebody does a query, it will first find these keys, it will find the DS hash of the parent, come to the child, check the key signing key, find the matching hash, trust the key signing key. Then it sees that the key signing key is actually signed to zone signing key. Then it trusts the zone signing key. And once it trusts the zone signing key, it can trust everything signed with it in the zone. So now when you want to do a rollover, you want to change the zone signing key. First thing you do is you have to add the second key signing key. No, sorry, the second zone signing key. Then you sign it with the old key. When you leave it in the zone for a while for things to propagate. And then when things have propagated, you just remove the old key and you make sure you sign it with a new key and you're all set to go. The key signing key rollover is a bit trickier because now we have to talk to our parent and say you have to change the DS on our key. You can have a look at it. It's fairly complex, but there are tools out there already that actually more or less automate this for you. Some parole scripts actually do this. It's a two-step rollover. First, you add the keys. Then you sign it with both keys. Then you make sure that you update the DS. Then you wait a while and remove the old key. So when there's an unscheduled key rollover, you basically, once your private key is stolen, you have a problem. There are a bunch of operational issues you have to address. Make sure that you're ready if something like this happens. So have an emergency procedure ready. One trick that's come up is actually put a spare key signing key in your zone which is just a signed piece of data. And actually put the private key in a vault and assume it's whatever your name server you're actually just signing machine is compromised. Just delete the whole machine, grab a new machine, grab the fresh key and use that. And just talk to your parent about a quick DS change. And then you're all set to go because the key's already trusted out there. Also, since we're using the trusted key statement in the name server, everybody who uses you as a secure entry point should need to be notified that your key's been stolen and they need to remove that because otherwise they keep trusting the key. Okay, so now how do I actually deploy? How do you actually run and secure your own zone? Sadly, the bind development has gone rather slow. So you still need actually to lay the snapshot from December, configure it with SSL support. If you're using Linux, you'll unfortunately have to disable threat support because it's completely broken. Compile and install it, make sure you're uninstalled. Preview stuff or install properly over it. If you wanna tools to test things, do not use the host command or the NSlookup command. They're really old. If you really like the host output like actually I do, that's why I still sometimes use host command. You can use dig plus multi-line and then you'll get a more or less similar looking output and you can actually, in the snapshot, there's also support for digrc file. You can put this in your digrc file and just start using dig instead. If you wanna check the NSSEC, use the plus NSSEC parameter to do secure resolving. If you just want the data without the checks just to verify that the data's in there, use plus CD flags in your query and you'll just get the data without the checks. Like if you don't use that flag on something's wrong, you'll just get surf fill. You have no clue what's going on. If you use plus CD flag, you don't get surf fill, you just get the data back. And there's one big issue. We ran into as well at some point, but bind eight actually is too clever. What it does is if it sees that the signature expired or the inception date is wrong or your time on your server is wrong, it will just remove that data from the zone file. So if you start experimenting now, sign your zone for 30 days, then forget about your experiment. Then in 30 days from now, if you're running bind eight, your zone will be empty and people will have problems. So either use bind nine or make sure that your signatures don't expire. No, as far as I know, the only software currently supporting all the DNS stack and the DS records only bind snapshot. If there's any other software out there, please let me know and I'll test it immediately. But so far, as far as I know, bind is the only software out there. Yes? So your question is about how to handle caching of keys? All right, the question is if data is cached, what do you do when the key is stolen? Well, first of all, apart from the cached, there's also the signature lifetime. So if you keep your signature lifetime low, like say one day, then it doesn't matter how long it stays in the cache, after a day it will be invalid. If you actually use a long signature time, then you'll run into the problem that yeah, if all the cache data is out there, then you might have a problem, only if the path of trust is not broken before. Like even if that's cached, if they do a proper check on the entire chain of trust and you've changed your key and the parent has changed to the S key and they actually ask for that data, then they already know that there's some other data there. So automatically that what's in your cache is invalid. Okay, so the actual commands to secure your zone file. Clean as a key gen and then the parameters for algorithm, bit size, zone name, you'll get some output back telling you what key number, what key ID is there. The first command is for, the DIN as a key gen command doesn't really know the concept of key signing key and zone signing key. So you don't see any difference here in the generation of keys. You just see that we used 2048 bits for the key signing key and 768 for the zone signing key. And we'll end up with two files, the dot key and the dot private file, obviously the private file should be very secure on your own machine and the dot key file is actually something you put in your zone. So you could cut the key file into your zone, increase the serial number and then actually use the DNS sign zone command to sign the key as illustrated there. You'll get a dot signed zone file which you then update, upload to your master name server and then change the load command to actually load the dot signed zone file and you're running. And you can test it with multi-line DIN as a command. So in the Netherlands, this has already been deployed in a shadow system by the domain registry. You can go to secrack.nl.netlabs.nl and this is an example of how you actually talk and create a DS record at the parent. You basically set up your zone just like we did before, you publish it on your name servers, you wait until things have propagated, then you go to this website and you say, I wanna secure freeswand.nl. What it will do is it will do a query for the key record and you can decide which of the key record is the one that needs the DS, so which is the key signing key. You select it, you hit submit, some email is sent to the proper context that pulls from the WIS database and actually it creates the DS record and the next day your zone is secured. Obviously for the people who've paid attention, they've now seen a big problem, but I don't see any hands raised yet. Okay, this first query that's being done by the registration system can of course be spoofed. So they need to work on preventing this but that's also why there's the extra mill step there to secure it. This is just an example implementation. They need to address things like PGP Secure, the updates for this. They've also written an application to actually do a key rollover at the parent. Basically what happens is you go to this web interface, they give you, you tell them I wanna rollover freeswand.nl, key signing key, they give you a random record, you sign it with a little girl script tool, you put it in any box, you upload it, they check the signature, then you know that you've got the old key and then they'll replace it for your new key. This is how a resolve query looks and answer. You can use the two machines listed there to do your own testing on secure resolving. This machine is set up to accept the queries from everywhere in the world. You'll see here a query for actually an old example, fnl.nl. One thing to notice is that you'll see the AD bit being set, so this was actually authenticated data. This is all fine for one zone. How do I handle a lot of zones? There are some standard pro tools written to net DNS stuff and there's some new things written to the net DNS stack, which probably the DNS stack main tools have been slightly renamed in a different hierarchy. Some of these are pre-released by all of Goldman of Ripe. Not all of it is public, but just talk to me and I'll give you a copy and you can test it if you want. These pro tools actually support all the things I've talked about so far. Some commands you can use, main key DB is actually a shell. You can just type in everything with command line completion and everything, or you can just type it all on one line, which says that here's an example. So it's a great key to just type that and it keeps the key separate in a separate file structure apart from your zone file, which means that you can easily roll over stuff and change your keys without actually having to manually edit your zone file. So it keeps your zone and your key separate. And once you sign it actually adds the two bits together and creates a secure zone for you. Then you run the DNS signer and then you can also do the key roll overs. So there are some changes in the organization that you'll need to be aware of. Of course, you do not want your signing machine to be your name server. If you keep all of these secure, all of the private keys on your name server, the next brute exploit for bind will still kill all of your extra security. So it's very important to have a separate signing machine sign the data elsewhere and then upload it to your name server and make sure that your name server have absolutely no rights to your signing machine. It should just be one way communication, which means that even if your name server is completely hacked to pieces, they can only use regular DNS, but they could never use another DNS sex signed zone data to hijack your zone. But it's actually a really cool feature. Your name server can be completely hacked, yet still they cannot send you anywhere else. Don't let the SIG records expire. If you're using complex system like MySQL databases to have customers edit the zone with their own zone, you'll have to write your own glue where it's actually fitted in. So now we've secured the DNS, apart from having a secured DNS, how do we, what other applications are out there? After the break, I will talk about what we believe is the real first application using DNS SIG, which is FreeSwan. Basically, it can do opportunistic encryption, meaning that it can set up IPsec tunnels based on keys that are in the DNS zone. And then of course, if the DNS zone is secure, then you can just spontaneously set up IPsec tunnels to anyone who supports us in the world without having had prior contact whatsoever. For anybody who's maintaining more than a few static IPsec tunnels, this is really something you wanna use because it ensures you massive deployment of IPsec tunnels without having to configure every single tunnel. If you're interested in this, come back after the break. Another application people wrote a while ago to test was the open SSH support, basically put the SSH key in the DNS zone and support it. Unfortunately, nobody's maintaining it. It was written for open SSH 2, I think. So maybe someone can convince the BSD people to update this. The DHCP software actually has some support to send keys over DHCP, which we'll be using for the WaveStack stuff here at the conference as well. If you wanna secure your wireless, come talk to us and we'll show you how to use the DHCP software to secure your last mile here. And there's some next walking software written. If you remember the next record, it points to the next piece of data in the zone. So basically you can sequentially query a whole zone and get the entire zone data. Some people are worried about that, especially the domain registries who basically do not publish lists of the entire domain. If you would run this on .com, you would just get the entire .com zone file, you know, all the domains. People don't like that. And there's still no browser plugins, no mail clients that actively support DNS sectors, no POSIX support written or defined. That's something that needs to happen now, but that's not gonna happen before people start deploying it on a name service. There's some references here for people who want to look up. The write reference is actually a really good manual if you want to experiment with it yourself. These are all on the slides. You can find it later on. So I'm more or less ready for the break. How much time is there left? We have left 10 minutes, okay. So are there any questions at this point? None, okay, well I'll show you my little script that I wrote then to secure. I'm basically running a copy of our signing machine on my laptop. So if everybody wants all the keys of us, then they should really try and hack into my laptop. Of course it's not connected to the net right now, sorry. So if you see here, these are a bunch of our customers and they have domains in several things. What I did is I wrote just a little shell script. I don't like pearl. Basically increase all the serial numbers to the current date and hour and then you'll see that I've run the sign command. There's a little bug, I have to do one manually because it's a really big record and apparently there's somewhere in the process there's a bug in it. Basically to give you an idea of how fast, actually how slow all of this is. These are about 150 domains that's now running. My laptop is about a Pentium 3500. One thing I found out that I had actually, like my battery life is really, really crappy, but when I was in a train running this for the first time, I actually found out that there's something that you run out of even before battery power, which is random. When you're on a laptop, you really have that random. So there you see the error for the exodine at an L zone. That's the only, there's a really big TXT record we use for the opportunity encryption and it can't really sign it. Now you see it's starting to sign all the zones. It's actually much slower than it normally is. Oh, there we go. So no questions. And we're gonna have a slightly larger break. So if people are interested in setting up the NS2 and IPsec tunnels to secure the wireless, I'll talk to you about the opportunity encryption bit after the break. Thanks. Apparently there are now more microphones and you should be able to hear me a little bit better. If not, just let me know. Okay, so now part two, opportunity encryption. The reason I personally got interested in DNSsec is that I really want host to host and encryption. Just I basically want IP to basically standardize to IPsec. I want everybody to talk IPsec. And no way we're gonna do this with manual configuration. So we have to have something that just works automatically. Basically what we're going to do is we're going to put keys into DNS and use that to talk securely. And of course we can trust the DNS because we just secured it. And we will deploy this here during the conference in the WaveSec way as well. If you have any questions on how to use this, do come to me. We really need to deploy this as soon as we can. Okay, so I'll quickly talk about the basics. What's opportunity encryption? How you can protect your network with it or your servers. How to install and configure it. The config part should be really easy. We've done our best for that. And then we use an example implementation on how to use opportunity encryption to protect your wireless. So IPsec in a nutshell, it consists of two parts. First, we're going to get a private channel that we're sure that we're only talking to one guy and not three guys in the middle. And once we know that we're talking to one guy using the helmet key exchange, we're going to actually ask who this guy is and if he can prove that he really is who he claims to be. And that's the part two thing. Of course, as you might guess, we're going to use DNSsec for that part. So to quote myself, the goal of opportunity encryption is to have IPsec connections without prior arrangement to exchange information with parties you've never knew before, allowing mass deployment of computers on the internet to talk securely and privately. This will mean that anybody who is going to e-stop will have to do an active attack on you instead of a passive listening attack, which is much easier to actually find out. Also for, we'll end up with a service who do not know how to do opportunity encryption, so there's also a way how to, we can just add a server that will do it for the other people that don't know it. You can actually use an OE security gateway to protect, for instance, your Windows server from. So one of the things to prevent a mental and middle attack is to actually have a third party you can trust to get the information from. We'll use DNSsec. So how does this work? First, we're going to put a special record in the reverse tree, in the DNS tree for our IP number. The example that you see here is the key from my desktop at home. It has 193.1.1.10.1.5.7.17. And it says, and it takes the record that says, I can do IPsec, opportunity encryption. My gateway is this IP number, which is the machine itself, and then the key follows. And of course, this is signed by a signature record. The DHCP server on client, the ISC server actually supports some of this stuff, sending it back and forth to actually establish this even when I'm turning on my laptop in this network here. I will get some random IP and I can actually update my reverse. It doesn't partially work here because we're in added, but we've worked around this by tunneling our own slash 24 in here. So people actually get WaveSec up and running later on, actually have a real IP. So if both parties have the key in the DNS, they can query it and set up a tunnel. So you don't always control your reverse. Actually, most of us do not control our reverse unless we have servers. So we had to come figure out a way how to do this when you have no control of it. So we can't work around it. There has to be one guy in the connection that actually controls this reverse and have something in there. Once you have that, the other guy can just have something in the forward. I guess I'll go away with the blame. So what we can do is we can put our key in the forward. This example here shows my laptop via XT-NetNL, which has a key in the forward. In this case, we don't point to a security gateway because we don't know which IP we are. So the entry right now is 127-001, which basically means ignore me. And again, I put my key in the DNS. XT-NetNL is signed, so it's pretty secure. So now, if my laptop puts in a random network, gets an IP and I go talk to my servers at home, which have all the support for what we need it, I just tell them, hey, I'm via XT-NetNL, grab the key from the DNS, and then we can talk securely. One thing to note is that actually, if I turn on my laptop here and my server for some reason decides to talk to me first, my server does not know that I can do operatives encryption because my IP does not advertise that. So it will send a packet in a clear. Once I get it, and I send an answering packet, then of course I will notice that the remote server can actually do OE and set up OE, but it's a really odd situation when one packet actually flows in a clear. So one problem of operatives encryption, of course, it takes some DNS lookups. And for some servers, that's really too much of a load, especially busy web servers. So there's a way to actually do only passive OE, which means that do not try to initiate OE to everybody who connects to you, but if somebody connects to you using OE, then sure, let's go ahead. And this is actually what we use on for instance the FreeZFound.org website. If you go there, if you don't have OE, you will just get a server. If you do have OE, you will get a nicely encrypted secure channel. So we're going to use, this is a form of OE to protect the wireless. This is a diagram of basically what we're setting up here at the conference. We've got the internet, we've got our local network, we've got our laptops. We use, we send a DHCP request that actually contains our key in the request. The server, our own DHCP server, which we added to this network, sees that somebody's asking for OE, and it will next to the regular DHCP server also send an answer, say sure, you can use this IP number, and actually you can use this WaveSack server to do opportunity encryption. And my client, my laptop will receive both of these DHCP answers. I will prefer the opportunity encryption one. It will get the key from the DHCP server from the answer as well, and has both keys to start and initiate a connection to the WaveSack server. Once it initiates the connection, the WaveSack server, which when it gave the IP number to the laptop, actually also put the key it got into the reverse. So it actually knows the key as well. So it knows its own key and the laptop's key. So both parties know both keys and they set up an intersect tunnel, and my laptop will tunnel the default route through the tunnel, which means that even if I'm talking from my laptop to another laptop within the same wireless network, I'm actually talking through tunnels. There were some people who did a man-in-the-middle attack on the DHCP part. If they're somewhere here, I would definitely like to talk to them. Because I just heard about this like a couple of months ago about the utility air check which actually plays, I think a man-in-the-middle DHCP server. So it's really interesting to have those people talk to me. And to answer those people's problems with it, how do we defend against this? Well, the good news is that the DHC working group at the IETF decided to use DNSSEC to secure the DHCP. So once those standards start getting used, we actually have a sort of trusted way to do DHCP and this man-in-the-middle attack is no longer possible. For now it is. So if these people are here, I would really like to see my laptop being a victim of this. So most people at home have like one IP number and they often ask us, like, can we use opportunist encryption? It doesn't work. Actually it does work, but you have to be very careful on how you set it up. Most people do netting on the external interface because it's easier to configure just anything that goes external netted to this IP number. However, if you're doing IPSEC, IPSEC is meant to protect packets from being rewritten. So actually you cannot rewrite those packets. So you have to be sure that you're using net on the internal interface at home so that you first rewrite your packets to your external IP number, then use IPSEC to continue to talk to the world. And probably you won't control your reverse of your ADS set or cable model provider either. So you have to use the initiate only version of opportunist encryption. The IPSEC world, at least in the Linux world, IPSEC has been rather, we've had a rather interesting two months. To make the political issue really short, the people who wrote Frishan believed that a decrease from their government that did not go through the parliamentary process was a problem. Basically US government can kill export of crypto at any time. Therefore they did not want US citizens to write a code so that US government could never claim any full control over it. The Red Hat people being mostly US citizens didn't like that they wanted to fix bugs if they could so they didn't include Frishan. So there was this stalemate that happened for a couple of years, which is now basically being broken by the Red Hat kernel people by basically making their own IPSEC stack. We're talking to them, we're hoping that we can keep everything working. There are patches out there which should integrate really quickly in the next couple of weeks that makes all the extra opportunist encryption hooks that Frishan put in the standard IPSEC to also be part of the new Linux kernel IPSEC stack. So everything I'm saying here should work for either stack, whether you use Frishan or whether you use the new kernel stuff it should just work. And hopefully it also makes porting it to BSD a lot easier. So what do you need to support the extra opportunist encryption extensions? First of all the kernel part which I just talked about. Second you also need to have some support to do the DNS lookups once you get back as to see if you can actually get the keys from DNS and start things from there. So far the only ID that's supported is the Frishan Pluto. Hopefully this will also soon change and then some support for Raccoon will be added. You need to have at least access to one forward zone to put in your key so that you can do initiate only our opportunist encryption. Preferably not some dynamic DNS thing but like your real-owned zone which would be a lot better to use. Most people who want to experiment with this actually have one zone so that should be fine. And if your ISP is going to filter out a lot of stuff then you're in trouble. You should have Ike ports open, UDP 500 mostly and ESP. So how does the opportunist encryption work technically on Linux? Basically all of this predates net filter in the two four kernels. This was written for like the two zero kernels so there's no nice net filter hook-in. Basically what happens is we wanted to catch all the packets before they go out so that we can do crypto on them and see if we can actually set up a tunnel to the remote end. So we need to catch all packets. If we can't get a tunnel we just pass them through and if we do get a tunnel we just first set up the tunnel and then fling them through the tunnel. So how do you catch all packets? Well, the Frishon people came up with a really clever idea. Just grab the default route, cut it into smaller parts so that their preference is higher and grab all the packets. It's the two green lines you can see in the route command that says the first half of the entire ISP space flinging into the IP sacrifice and the second half of the entire IP space flinging into the IP sacrifice. So basically you replace your default route with a more specific default route. For people who don't use the IP command this is the old route syntax. So then of course we need to sort of know what's encrypted, what's not, what's the problem. Do we have a tunnel to the other end? I've tried to put all the states in one picture here. First you'll see that my desktop is running OE on the first line. It says trap all packets going from this IP and into anywhere, which means trap the packets, see what we can do with it. The second line you see a pass E route. This is what we call an E route, an encryption route. So a pass here, a trap means do something with it. A pass means we cannot do crypto with it, just let the packet flow. The tunnel actually means we've set up a tunnel and the IP listed on the right side is actually the gateway. Remember, if you do OE you can also do OE to another server. So if you wanna protect like a Windows farm with a Linux box, then basically my laptop would set up an OE connection to the OE gateway to the Linux machine there and then it would decrypt and be sent to the Windows farm. So on the third line you can actually see that dot 77 is the security gateway for dot 10 and my laptop has a connection to it. So packets from dot 17 to dot 77 are encrypted. They're decrypted by dot 77 and sent to dot 10. We see another pass route, which is to my name server dot two. And we see the next one is a hold route. This is an interesting one. Hold basically means we determined we can do crypto. We should have an IP sector up but for some reason it's not working. So we don't want to fall back into the clear because this guy obviously advertised that he can do crypto. So something's really wrong and we just don't want to send packets. So hold the packet and until the situation gets fixed do not send anything in the clear to this guy. And the other two are just more examples of established tunnels. So to refine this a little bit better, Frisuan starting from version two support something called the policy groups and makes things a little bit easier to say, okay this guy's been misconfigured for so long. I know he advertises he can do crypto but he really doesn't. So I just send it in the clear and you can just put them in a clear file and it will just always work, always send clear or you can do the other way around to say no matter what's being advertised, my own super secure network should always be encrypted and if not just completely block it or which should be your default is try to be private but if that fails, it's okay to do it in the clear. So how to install Frisuan? Most distributions actually already have Frisuan support, Debbie and Susan, Andrea, Connectiva. They all have binary RPMs you can just install because the political issues, Red Hat doesn't have binaries yet. We just make binaries for all the RPMs that Red Hat ships so if you wanna just install binaries you can just go to the URL mentioned there and install it on your Red Hat machine. Every time Red Hat comes up with a new kernel we make matching modules for this or you can install it yourself from source. So if you really want to install it from source just grab the software, make sure you have the GNU Mathematician library installed, GMP, Devil, you need to have the files. Make sure that you build a kernel. Most people come to us when they can't build it and they have other problems because they're using a Red Hat kernel, they're using another kernel, something doesn't work, or actually the kernel just doesn't build itself. First build a standard kernel, then apply the Frisuan patches. There are various ways of doing it. If you just want modules you can do make old go which will just use the same defaults you just used on your previous build on a kernel just add the IPsec stuff as modules. For some people who wanna next to OE do other things like Netroversal, even though Netroversal with OE doesn't work yet. If you need NetT support, Netroversal support, you also have to, there's a patch in UDP patch which actually patches the kernel itself, not any modules. So you actually have to build the entire kernel, not just the modules. But for just OE this is not necessary. So for 2.5, the last few weeks you've been playing with it, there are definitely a lot of bugs that needs to be fixed, but for the alternative IPsec stack it sort of works. Basically, make sure you get the latest patches and just build a use line with make programs and don't build any kernel stuff. So once you've installed it, if you haven't installed it by RPM which will do most of these things for you, you will need to create the DNS records needed for the opportunity encryption. You can, first you generate your secret and your host key with the command list there. Then to make it easy, if you just use the IPsec show host key minus minus txt and then the IP number that's your security gateway, you get the entire DNS record that you need to give to whoever's maintainer of the key or the forward, the reverse or the forward zone. So we make it really easy to just cut and paste your key. Do cut and paste it and not edit it because many people make mistakes when editing it. There's some issues with spaces and bind that are really annoying. For people who directly want to pass to the ISP, you can use the IPsec milky command or you can just directly send it to your ISP and say, give me this record. Though for FreeSound 2, we've made it even easier to use OE FreeSound 1.9, that's what's shipped on most of the distributions. So I just put this in here. This is the only configuration you need to actually get an opportunity encryption tunnel set up on once you've installed the binaries. You make a connection called me to anyone. You basically say, my outside world, you use the interface of my outside world as the interface to do crypto on with the left is the default route. For the right, we say, do operative encryption, do authentication by RSA-SIG and just start this connection. This will use the OE based on the IP number, so on the data in your reverse, so that if the other side queries the text record for your reverse, it will work. If you're doing the initiate only one where you actually have your key in a forward, not the reverse, you need to specify the left ID. And then you need to specify to add and then fully qualify the main name where the record can be found. The left ID then gets used to the IEC negotiation. For FreeSound 2, we basically configured everything for you. It's basically, we just try every few seconds to see if there's the proper DNS records for us to use and if it is, we just use it and we just try to do OE. So the only thing you basically need to do is install it. Mail the key to whoever can put it in a DNS zone file and that's it, you're all set to go. There's nothing you need to do. If for some reason you want to disable it, you can do auto is ignore to stop that connection. If you just initiate only version, unfortunately you need to redefine the connection yourself and add the left ID a bit again. So now to what I think interesting bit, the WaveSec. Now if you want to use WaveSec here and encrypt your local traffic, what do you need to do? First you need to get a patched version of the DHCP. Unfortunately the IEC DHCP developer, Ted has been very busy and it's not really maintaining it. He has these two patches from us waiting for half a year and he still has to apply them. Grab the patch, recompile your DHCP server on client. Add the configuration listed below, which is just, it's a file you can download from the WaveSec org site. So don't worry about it. You need to set up a DNS so that the DHCP serve access permission to change the DNS records for the reverse so that when it gets the key it also puts it in the reverse tree. You need to know somewhat how dynamic DNS updates works. Check the URLs below or grab an example configuration again from the WaveSec site. Since the WaveSec servers actually need to do crypto on multiple interfaces, you specify the interfaces. So instead of using the percentage default route you specify whatever interfaces they're in use. Unfortunately we still need to define every single connection on the WaveSec server, which means that we have to pre-define everybody who can connect. So for a slash 24, you actually have to make 250 connection definitions. We're working on making this nicer, doing it in a nicer way. One problem we have is jump-starting. How can you do a DNS sec, or how can you do lookup keys when you don't have a tunnel yet? Or when you're negotiating the tunnel? So the easiest way we found is to just let port 53, the DNS and the ICMP and the IC negotiation package just flow through outside of the WaveSec tunnel. These are the IP tables rules actually do that. Otherwise your connection attempt will be stuck in another connection attempt and you won't get through. So for freeze run as a client for the WaveSec machine, you also have to get a patched version of DHCP. If you're running Red Hat, make sure to delete the older client, the DHCP CD, so that is not in their way. Be careful that the lease files are stored differently, so make sure you delete all the lease files. For older versions of Red Hat, you need a patch to the if-up script. Red Hat 9 and some of the battles before 9 actually support DH Client, but just don't install it. So once you've installed it, you can just use the standard scripts. And we need to configure the DH Client to actually do all this OE stuff. So once you insert your card, DH Client gets started and it actually starts to set up the WaveSec connection. We do that by using a dhclient.com file. Some of the stuff is generated for you automatically. You just use the command hyperexure-hostkey minus minus dhclient and put it into your dhclient.com file. Stuff should also work for FreeBSD in Kame, though it needs a lot of manual configuration still. If people wanna try it, come talk to us for these specific details. Also, of course, Microsoft Windows would be really nice to support as well, except that they cannot grab the keys from the DNS and then use that. So we have to figure out something else. We're thinking of doing something here with X509 certificates and X509 patch to FreeSwan. If we find out something, then we'll put it up on the WaveSec box. Again, talk to us a few if you wanna experiment with Windows. We think we should have something running in the next few days, but we don't know for sure. So how do you test your OE setup? Because one of the important things, if it doesn't work, if you set it up wrong, you will just have no connections to the world. So there are many common mistakes people make. We try to catch them in the command hyperexure-hostkey which verifies your setup. This is an example where you see that the key has not been put into the DNS. We check for some common mistakes, like is IP forwarding enabled if you have two interfaces? If you're using NAT or masquerading on the machine, are we sure that we're not destroying the IDsec packets? It's generally a good test run to see if it works. Another way of testing OE is actually to go connect to the machines that support OE and see what they tell you. There's one machine currently, which is called Untappable, actually in the NL, that actually has all the DNSsec support as well. It's an example that I show here. I have connected, I've pinged the machine, and then I tell that to the go for port, then the go for port just gives me all the output. And you can see that I actually had, when I did this at the IP number 1921394638, and I was actually in a properly signed DNSsec signed zone file. And so that machine knows that my RSA identity that was put in the key in DNS actually came from a secure DNS. If you just browse through Untappable, actually the NL actually tells you whether you came in through OE, whether you're coming in plain text, or whether you're coming in using OE plus DNSsec. Some other test sites that should support OE, more and more sites are using it, so this list will become longer. So there's still some problems that people run into when they use OE. The first problem is that once you start OE, and you wanna set up a tunnel, you need to do a DNS request. Usually that DNS request starts the initiation of yet another tunnel. So for a few seconds, while you're not able to actually go to your DNS servers, everything will fail, and you need to wait for that failure to be complete, and once they're passed around to your name servers, then suddenly all the other connections can actually be set up because then you get DNS answers. So once you start pinging, don't worry when it just doesn't work immediately, just check your log files and see if it works after a few seconds. FreezeFence still has some problems integrating properly with the scripts from various distributions when a card, the laptop PCMCA card is inserted and removed. We're working on getting that better supported. People also often make mistakes in getting the keys into DNS, like I said. Spaces, there are some spaces in the text records that work around a few bugs and older versions of bind, but people tend to either not grab them or leave them out or miss paste them. So be careful when you're cut and paste. Another annoying bug is that, apparently there's some issue. If DH client has run from the command line, everything works, but if it comes from a kernel generated event, like the hop-lock stuff when you insert your card, on some machines, for instance, my laptop, we're getting errors on P open and P close, which we haven't found a reason for. And due to the update on the ITF use of the key record, we had to change some things since we're officially not allowed to use the key record by Psec anymore. So that change went into freeze on 201, which means that 200 cannot talk to 201, so if you're running older servers in the OE, make sure you at least use 201, which knows how to talk to older machines. And problems we've also seen is people who have just too many tunnels inside each other, and then you get either fragmentation or empty view problems. If you run into that, and it especially happens when you have like PPP over ethernet or ADSL tunnels or PPP stuff, usually when you're provided with really yucky things, make the packets a little bit smaller, usually problems go away. So for like, we'll really do our best to generate a log message that actually makes sense for every single event that happened. So the log files are really to the point when they point out an error. So really try to check your log messages. It's really in there, what's wrong. Run the IPsec verify command I showed before. Disable all the firewall rules to make sure that your firewall is not blocking packets. And if that really doesn't help, you can use IPing to see if your ISP filters QDP 500 to prevent you from running IPsec. Make sure to stop freeze one when you do that because otherwise freeze one will grab the port. And if all of that just doesn't give you the right answer, there's one thing you can do is that's run the command IPsec bar, which will basically point, it will put all the state of your IPsec subsystem except for your private keys on your screen. And if you just put that on a website and ask people on a mailing list or the IC channels, they will look through it and they can probably see what the problem is. One very important thing to do, people see the Clip's Debug and the Plural Debug variables and enable that. Then those people are posting 10 to 15 or 20 megabyte files with debug information that the people helping you on the ISC channel really do not want to read. The debug functions are only for developers, so please do not use them. It's not going to give you more information that you need. So if you want to try out openness encryption, if you want to try out the WaveSec, grab either me or Ken Bantoff here in the front, we'll be gladly helping you set up your IPsec tunnels and secure you from all the evil hackers here at the conference. So I hope people will see the value of end-to-end host encryption and see that openness encryption can really reduce the administration task of setting up a massive amount of tunnels, whether it's inside your organization or just to out to the world and to the internet. We hope that BSD will soon support this as well. We're talking to some people and so let's hope that basically in the near future everybody is talking encrypted and we're all safe from evil hackers or evil governments. So are there any questions? Then I guess I end early. Okay, thank you very much.