I've gave a talk a few DNSSEC and DKIM talks and run a few DNSSEC protected domains. I was involved in getting UCD to finally go DNSSEC which happened recently. I was (AFAIK) the first DNSSEC enabled domain on campus. Ah, rats, for years I was the top hit on google for DNSSEC and DKIM, but campus was hosting my slides and apparently killed the site 8-(.
Some points I wanted to make: * Name servers have two main categories of functionality, Authoritative and Recursive. * Authoritative only servers don't cache * Buffer overflows/bugs in implementation certainly exist, but aren't a major point of concern these days. Bind is large, and complex. But sufficiently audited that the serious issues are getting fairly rare. * DNS based Amplification attacks are a major issue these days * DNS was by design a VERY insecure protocol, even assuming a perfect implementation. * DHCP suggestions for a name server can get used or ignored. Traditional MitM (Man-In-The-Middle) involved, er, a man in the middle. So with a telnet connection someone who was between the source and the destination could listen in, record the username and password, then login from anywhere. SSH prevents this by using public keys to exchange a secret key, which is used for that session. So not only can someone not sniff a ssh connection, but they can't replay a session. DNS has a much more serious issue. The default uses UDP, and UDP packets don't have a source address. So you can't tell where the packet came from. So if you ask a DNS server for google.com anyone on the planet could send you (or the DNS server) a UDP packet that says google.com is some ip address in Russia. So it's really Man-On-The-Planet, they do have to hit a rather narrow time window though. Cache poisoning builds on this. Normally you'd have a very short window between a request and a valid response to lie to the DNS server with a forged UDP packet. But say you can trigger a remote name server, say one for a large ISP to look up foobarbaz.google.com. Then you know that A) it's not going to be cached, B) the DNS server is going to ask RSN, and C) since you know ahead of time you can send a valid looking answer in the very next packet. The trick is you'd send two answers, one for foobarbaz.google.com and one for google.com. At the time (2008ish) most name servers would accept both, and suddenly an arbitrarily large number of users would get the forged results. That however was fixed quite a long time ago, so winning the race conditions are hard. Additional protections have made this even harder, but not impossible. The real fix is DNSSEC. Neither of the above lets a remote attacker change the address a name server forwards to. Not sure of any practical attack that would. Sure a serious buffer overflow could, but at that point you'd likely just take control of the server instead of just redirecting dns queries. DNSSEC used public key encryption to validate DNS requests. A few points: * DNSSEC does prevent cache poisoning * DNSSEC does prevent MITM attacks * DNSSEC does not require a secure network * Room 641A is pretty much irrelevant * DNSSEC can protect against local ISP * DNSSEC can not protect you from those who sign the root. Thus US Gov can get verisign and related to delete/change zones. * However tinkering with the zones is easy to detect. So basically a DNSSEC aware resolver typically stores the key for ".", called the anchor, then does query .com, then foo.com, and so on. At each stages the key above signs the record on the next level. So say for broadley.org (which is signed). The root key is held by verisign I believe, which signs ".". The public interest registry signs the .org domain, and my registrar allows me to upgrade the records for broadley.org. So sure the USA government could pressure a registrar to delete or change my domain. But that has little to do with spying hardware installed in various large network hubs. Additionally even if the government did do that, you could immediately notice the change in signing key and if you knew me you could enquire why such a change happened. So for instance: $ dig +short +dnssec broadley.org ds 16276 5 2 7BCB5E40E630C8F77F168FFA1380BBBF25356A0B474FDDFA6F89FF1D 0AD4301B 16276 5 1 3397132E041EC17D59206FC318047D4D5128EB65 One is a KSK = Key Signing Key, and the other is a Zone Signing Key (ZSK). Similar applies to SSL certificates. If you are worried about secure communications with someone you can store their public key. While a government can publish a new public key, they can't magically produce the missing private key. So even the NSA has to be careful, faking a public key on any kinda of wide scale is lightly to draw significant attention. The more they use it, the less effective it will be. Various national governments have tried this to intercept communications with various email/messaging sites. It worked for the less than wary, but left obvious signs. Google chrome for instance has protection built in for google.com. So even if you have a zillion random CAs trusted by default, google chrome will not allow any of them to report a google.com signed cert, except for the CA they use of course. You can be sure that pretty much any government can likely influence at least one of the CAs that are trusted by your default browser. Thus the importance of tracking public keys. If protecting yourself from some random hacker/cracker/phisher the green url bar, lock symbol, or related signs that a valid SSL cert is present is a good sign. Of course you have to make sure it's paypal.com (with a l) and not paypa1.com (with the number one) and similar lookalikes. In general it's safer to type in a link then to click on anything in an email. But if trying to protect yourself from your ISP/local government then you need to watch the public keys for any suspicious changes. If you are trying to protect yourself from the nsa/usa government you basically shouldn't trust any US based business or closed source software. Sadly certificate authorities are anything but trustworthy. So I prefer the ssh model. You track the public keys of servers you trust and the client screams bloody murder if they change. That way things are secure unless the end points are compromised. Speaking of which SSH public keys are quite handy to store in SSHFP records when protected by DNSSEC. Now for the practical advise: * Do try to keep your private keys as secure as possible * Pick good passwords, never use them for more than one site/service, preferably generated by a machine. I susggest an open source password database like keepass (It works on windows, linux, android, and IOS). * if you are worried about a MitM attack track the public keys, popular browsers have plugins like "certificate patrol" to help with ssl certs. * Do not use ssh passwords, use certificates. Optionally laugh at the brute force attempts. * Do DNS right, use unbound with DNSSEC enabled locally. It's fast, efficient, will validate DNSSEC, and talk directly to the root servers for you. Hard to DoS, not subject to the marketing manipulations by your local ISP. Will not lie to you about NXDOMAIN, and should work even if your ISPs dns servers die. * If you use SSH manage your public keys somehow, dnssec + sshfp is one of many solutions. * Don't click on PDFs from untrusted sources, doubly so in IE. Sadly one of the things I'd most like to see for linux is signed binaries. I'd love to have a certificate file for who *I* trust. That way is someone manages to get a trojan binary on my machine it wouldn't even run. For the cryptogeeks out there, this message is signed with DKIM, and the DKIM records in DNS are signed with DNSSEC. That basically means someone with my username/password wrote this email, or at least someone with root on my mail server. Granted it's not as strong as PGP/GPG which only requires a secure client. But it's popularly supported. Anyone reading this email on gmail should see a "signed-by: broadley.org. I think I've rambled on for long enough now. _______________________________________________ vox-tech mailing list [email protected] http://lists.lugod.org/mailman/listinfo/vox-tech
