Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Security IT

Secure DNS a Hard Sell 142

Posted by ScuttleMonkey from the underdeveloped-ideas dept.
ebresie writes "Computer Business Review Online has an interesting article about the lack of acceptance for Secure DNS." From the article: "Speaking during a workshop on the technology, Keith Schwalm of Good Harbor Consulting, a former US Secret Service agent, said that even the financial sector, traditional security early-adopters, are not rushing DNSsec."
This discussion has been archived. No new comments can be posted.

Secure DNS a Hard Sell More

Secure DNS a Hard Sell

Comments Filter:

  • Nice, but not necessary (Score:5, Interesting)

    by ehaggis ( 879721 ) on Wednesday December 07, 2005 @02:24PM (#14204347) Homepage Journal
    DNS, if configured correctly, works well. Blind zone transfers and poor setup are usual culprits with exploits. A secure(r) DNS would be nice, but I think there are bigger security fish to fry.

    • Re:Nice, but not necessary (Score:5, Informative)

      by razvedchik ( 107358 ) on Wednesday December 07, 2005 @02:37PM (#14204437)
      I disagree. What you are talking about is the research part of a good or determined attacker. In this instance, the zone transfer is just more information on what to attack. This definitely is not a big risk.

      However, there is much more associated with DNS that you can do.

      If I am a user, what I want is 100% confidence that I am connecting to the correct server. I'm trusting in the DNS chain all the way up to the root server and then on to the authoritative server. What's to keep an attacker from routing me somewhere that I don't want to go?

      A good example is a piece of malware that changes the local DNS cache to point ebay to another server that does a man-in-the-middle attack? To the end user, it's completely invisible.

      It's fairly easy to do on a LAN by using one of the mitm tools. What you are doing is setting up a rogue DHCP server and DNS server, then you give the target computer a lease with a machine you control as the DNS server. If you control DNS, you can tell them to go anywhere you want, including sniffing their traffic, altering the content of the traffic enroute, basically whatever you want.

      • Re:Nice, but not necessary (Score:4, Informative)

        by timeOday ( 582209 ) on Wednesday December 07, 2005 @02:46PM (#14204510)
        If I am a user, what I want is 100% confidence that I am connecting to the correct server. I'm trusting in the DNS chain all the way up to the root server and then on to the authoritative server. What's to keep an attacker from routing me somewhere that I don't want to go?
        Secure protocols like ssl already solve the problem at a different level. DNS spoofing might get you connected to the wrong server, but when they fail the key-based challenge you'll know anyways. Even with secure DNS, those higher-level protocols would *still* have to carry out the checks they do now, since even after looking up the correct IP address, your IP packets could be misrouted. So what does secure DNS really buy you?

        I'm not saying the authentication protocols already available (say in ssl) are entirely satisfactory, but duplicating them in DNS won't make them any better.

        • Re:Nice, but not necessary (Score:3, Interesting)

          by mellon ( 7048 ) *
          Most people can't tell if they are connected using SSL or not. One of the nice things about secure DNS is that if the DNS response is spoofed, it just doesn't come back. So if you have someone spoofing a zone, you don't see answers to the zone, rather than seeing and accepting the wrong answers. This leads to trying to figure out why "the internet isn't working," which leads to the revelation that someone is spoofing DNS, which leads to the problem being corrected.

          To spoof you without secure DNS, all
          • "Most people can't tell if they are connected using SSL or not"

            Those are beyond salvation and I don't think that secure DNS was developed with them in mind.

            I mean, someone which will accept following an hyperlink coming on a html e-mail from somebody unknown to him that says "your.bank.of.confidence" while obviously opening a browser pointing to "your.hacker.of.the.day" won't benefit any more from using secure DNS.
        • The way I look at it is like PKI (remember when it was the silver bullet to everybody's security concerns? It always make me cringe when people started talking PKI for a company with 15 employees). It works great if you are a huge organization like the government, but if most people will not see any benefit of it at all. But then again, most government agencies have their own Certificate Authority, which makes DNSSec and PKI easier to tie into.

          And, to be honest, I like SSL better than DNSSec because ther

        • Re:Nice, but not necessary (Score:4, Insightful)

          by bogado ( 25959 ) <`bogado' `at' `bogado.net'> on Wednesday December 07, 2005 @05:44PM (#14205933) Homepage Journal
          If you have a malware that poisoned your DNS cache, it might as well install a new trusted key in your browser. The malware site can then have another key that is signed with the key that the malware have already installed and you will have a secured connection.

          But starting with a corrupted computer to begin with is a bad example anyway. The malware could simply substitute the ie.exe program for a new one that show what he want.
        • SSL does not solve DNS issues. Nothing prevents determined hackers from installing an SSL certificate on their phishing website to look like the real thing - most users don't know the difference anyway.
        • SSL does nothing to prove you're connecting to the right site if the attacker gets a cert from a CA. Most of the CAs now have "instant" SSL certs which have zero identity checking and a lower price. Very few users pay attention to the SSL icon, but even fewer open up the certificate properties and verify that the organization name on the cert is from who they think it is.
      • Sure, but DNS as it stands is much better in terms of scalability and redundancy. If you add a lot of authentication and double checking, the whole system becomes less efficient.

        Your scenario is plausible, but if someone is in a position to execute a Man in the Middle attack, then they can just snoop your traffic by redirecting it through a proxy under their control...Why bother with a DNS redirect? Cache poisoning exploits have been around forever, but they're not all that common either.

        I think the reason
      • A good example is a piece of malware that changes the local DNS cache to point ebay to another server that does a man-in-the-middle attack? To the end user, it's completely invisible.

        That's your problem though, not mine as a server admin. Besides, a simple SSL server would foil that attack and pop up a warning that the server names don't match the certificate. Again, if you as a user are so completely braindead that you ignore the warning then it's your own damn fault for getting your information compr

        • "...That's your problem though, not mine as a server admin. Besides, a simple SSL server would foil that attack and pop up a warning that the server names don't match the certificate...."

          If I am truely in the middle, i can rewrite URL, present other certificates etc, ( spoof the certificate authority too even ), all this software technology exists Load balancers content switches ssl concentrators all have to legitmately do this now.

          All that being said, this is currently not the biggest threat, although pull
      • What's to keep an attacker from routing me somewhere that I don't want to go?

        An SSL certificate.

        The cert name and the DNS name must agree.

      • so this would stop china from its middleman dns attacks? where do i sign up?
        one way they filter sites is to return false dns information for lets say one site: no-ip.com:

        ;no-ip.com. IN A

        ;; ANSWER SECTION:
        no-ip.com. 86395 IN A 169.132.13.103

        ;; AUTHORITY SECTION:
        com. 172800 IN NS g.gtld-servers.net.
        com. 172800 IN NS h.gtld-servers.net.
        [snip]

        and request it again:

        ;; ANSWER SECTION:
        no-i

    • SecDNS doens't address poor set-up. It attemtps to assert zone authority through record signing. Right now, you don't know if DNS is resolving the correct address or not which makes poisoning such a nasty threat.

      RUMOR has it that Verisign can't sign the records fast enough, however. Public key operations are so slow, that by they can't get through the whole .com zone before they begin to expire. Anyone know any different?
      • Rumor is false, with hardware accelerator .com can be signed in
        about 1 hour on a fast AMD system.
        The distribution of the zone is a bigger issue, but most of the time only fragments of the zone would be signed at the same time.
      • RUMOR has it that Verisign can't sign the records fast enough, however. Public key operations are so slow, that by they can't get through the whole .com zone before they begin to expire. Anyone know any different?

        That's not true... They have indeed signed the whole .com zone in practice on some fairly decent machines and it was on the order of hours (if I recall; I think 6), not months which is the more likely signature life time they'd pick

    • lol no this is not a virus You mean like that? :)
    • These are a serious problem. It would be relatively trivial for someone to poison DNS by spoofing a server that is pointed to by other DNS servers. The poison will then run downstream, affecting all servers that (ultimately) derive information from what should have been the master server. Because many corporations use SSL only after a person has entered login data, it would be possible for someone to use this to masquerade as a legit bank, with the bank's actual human-readable name but pointed to their own

  • Hard to understand (Score:5, Insightful)

    by Mr. Flibble ( 12943 ) on Wednesday December 07, 2005 @02:30PM (#14204398) Homepage
    Enough of my customers don't understand REGULAR DNS, nevermind secure DNS. The only way that this is likely to be adopted is to have the top level name servers eventually require the secure extensions. I doubt, however, that that will happen.

    As it is now, I have my users going to their registrars and "deleting the 'A' records because: "There is no A on my website."

  • bigger fear (Score:5, Interesting)

    by keithhackworth ( 902524 ) on Wednesday December 07, 2005 @02:32PM (#14204407)

    I run my own DNS server at home because I have a bigger fear that my ISP's DNS may be hijacked rather than my bank. It seems like that would be the easiest hole to crack for hackers.

    I would hope that if my bank's DNS servers were hijacked that they would work with me to get any money I lost back. However, if my ISP's DNS servers were hijacked, I don't know that the bank would be as cooperative.

    Keith

    • Re:bigger fear (Score:5, Interesting)

      by Dolda2000 ( 759023 ) <fredrik@dolda2000. c o m> on Wednesday December 07, 2005 @02:41PM (#14204464) Homepage
      That oughtn't be a great problem, however, since your bank (hopefully?) uses a SSL certificate to ensure you that you are on the right web site. If you click past the SSL warning that says that the certificate doesn't match the domain name when you go to do some on-line banking, you really shouldn't be all too surprised to find all your money gone the next day.

      • Re:bigger fear (Score:5, Informative)

        by hal9000(jr) ( 316943 ) on Wednesday December 07, 2005 @02:49PM (#14204533)
        But if your ISPs DNS has been poisoned, then the attacker can resolve any host to the IP address of thier choice. If I control your ISP DNS server and I tell it that www.amazon.com resolves to 192.168.10.1 which is a web server I control, then I can send you a certificate claiming to be from www.amazon.com, and the DNS name will match the FQDN in the certificate. That wouldn't be a problem.

        You will get a error dialog in the browser because YOUR browser certificate store probably doesn't have the signing CA certificate the attacker used to create the SSL cert for the rogue web server in the first place. But that is a different problem altogether.
        • You will get a error dialog in the browser because YOUR browser certificate store probably doesn't have the signing CA certificate the attacker used to create the SSL cert for the rogue web server in the first place.
          Yes, well, that was exactly what I was referring to. One shouldn't even begin to suspect that a bank would have a web server certificate that wasn't signed by one of the big CAs.

          • Re:bigger fear (Score:3, Interesting)

            by baadger ( 764884 )
            How much hard checking do these CA's really do? The user won't notice if it's a smaller CA as long as the root cert is in their trusted list.
            • Yeah, and that is especially a concern with all the DNS registrars. Can they be trusted to really identify that some one is who they say they are beyond taking the information off of a credit card statement?

              • Re:bigger fear (Score:5, Insightful)

                by Agelmar ( 205181 ) * on Wednesday December 07, 2005 @04:08PM (#14205138)
                This is a valid point, especially when you look at the number of small fish in the pond. You have small registrars, you have small CAs (do you really trust Unizeto? I don't even know what it is, and yet by default Mozilla gives it the same trust as it gives Verisign.) Even so, I posit that it really doesn't matter how much trust I can place in the CAs and the registrars, because the (unfortunate) end result is that most users, when presented with a certificate error, simply click OK. We train users to do this. Many corporate and educational entities set up their own CAs, and then when users see a message in their browser about an untrusted CA, the tech staff just tells them to 'click ok'. As such, the user is now conditioned to click 'OK'. What have we done? Totally diminished the usefulness of the trust aspect of SSL.
            • " How much hard checking do these CA's really do?"

              Quite a bit actually. I quote Godaddy.com's Wildcard High Assurance 256bit SSL Cert "The Validation Process verifies: domain name and domain control; identity and authority of requesting person or company". I think some of the personal verification steps include credit reports and the like. Funny that I was JUST thinking of this last night.

              • " How much hard checking do these CA's really do?"
                Thawte just wanted a fax of our phone bill. Ours even had the wrong company name. I told them to look up our newly filed "doing business as" statement, but I don't know if they did.

                Maybe if we claimed to be Chase.com they would care.
            • How much hard checking do these CA's really do?
              I would believe that browser developers don't put CAs in the root CA set without very good reason. I haven't been requesting any certificates myself (I run my own CA instead for home use), but I believe that all the CAs in the standard browsers' root CA lists do very stringent control of the applicants.

              After all, if they didn't, they wouldn't remain in the browsers' root CA list for very long.

      • They wouldn't even have to get the warning.

        www.spoofedbank.com that looks like Bank of America can get a certificate on their own and the end user wouldn't even know. How many non-slashdotters never or even know how to read a certificate? They just clicky through.

        Of course there would be somewhat of a trail if the cert is signed by a CA and that's the only way they won't get a popup.
    • I guess I am really clueless, but don't banks use a security certificate so that a user like myself won't be misled into thinking that a spoofed site is really the bank? For example, I am a customer of bankX.com and I let my browser verify the site, if it's the right site I get the right response, if it's the wrong site I don't get the proper response.

      I do this with my machine at work too, I use ssh with a public/private key set-up. If someone highjacks my machine I will be informed when I log on --- actual

    • Re:bigger fear (Score:2, Interesting)

      by iambarry ( 134796 )
      That's why your bank uses HTTPS with a server certificate. They assume that DNS is going to be owned by an attacker.

      The lock in the browser confirms that the site in the URL is the one serving the page.
    • Wait. So your solution to the insecurity of DNS is to run a another DNS server? That sounds a bit insane to me. What if someone hacked the root DNS servers? It's been done before.

      Seems like a more sane solution would be to add your banks IP address to your /etc/hosts file(s) and then set the /etc/nsswitch.conf hosts entry to 'files dns'. Then, if the bank's IP address changes, confirm it with the bank's IT department.

      • What if someone hacked the root DNS servers? It's been done before.

        If the roots get signed, they'll certainly going to be using off-line signing so the private half of the signing key won't be kept on the servers themselves. Thus, an attacker couldn't modify the data without people that were already aware of the public key wouldn't detect (and if they tried to change the key validating resolvers with the root keys installed as trust anchors would notice the difference and ignore the answers; end result a

    • How about performance issues? I found that running my own DNS server actually increased my internet speeds. The computer was spending less time trying to find the websites and was actually getting to them. Then again, the internet providers in South Eastern Idaho are pretty brain dead. So it was no suprise. At the time that I put up the DNS server, I was living with room mates, and they actually connected to the server, and within about a month I had an entire building connecting to my FreeBSD 4.6 box. The

  • Same as Sony (Score:5, Insightful)

    by Nom du Keyboard ( 633989 ) on Wednesday December 07, 2005 @02:40PM (#14204457)
    While the vulnerabilities in the DNS are well known, the absence of widespread attacks, regulations, and proven business models are holding back DNSsec adoption

    One could have said the same thing about music CD DRM (e.g. the Sony XCP RootKit) -- or the 9/11 terrorist attacks for that matter.

    There's not a problem with it -- until there's a big problem with it. Then everyone asks why wasn't something done to protect us against it?

  • secure domains (Score:4, Funny)

    by digitaldc ( 879047 ) * on Wednesday December 07, 2005 @02:42PM (#14204477)
    "Some registrars talk of adding a "significant" add-on fee for DNSsec "expert services", while others talk of making domain registration a case of picking from two services -- a domain name and a "secure domain name", the latter costing more."

    So you have domain, secure domain, and when that gets compromised, you will then have super secure domains, ultra secure domains, and supermax domains?
  • The goal of all this is to prevent phishing and other exploits? I think SPF will make a much bigger difference in cutting down on internet "crap". SPF seems much more likely to make a difference, and good luck getting secure DNS implemented in a significant number of domains.

  • A solution looking for a problem? (Score:4, Insightful)

    by 26199 ( 577806 ) on Wednesday December 07, 2005 @02:43PM (#14204483) Homepage

    We already have authentication systems. Why should DNS, which every website uses, be doing something which only a tiny fraction of websites need?

    Besides -- technology can't stop phishing. A combination of education, authentication and client software that can with 100% reliability inform the user whether authentication has happened is the answer. Authentication is by far the easiest problem of the three. Education is more or less impossible, and reliably informing users is next to impossible. (In a web browser, anyway. If you let websites display images and run active content, how do you stop them fooling a user, even a well educated one? How do you guarantee it's impossible to do so?)

    • Many phishing sites do offer authentication, just not to the place you thought. I've seen a couple that operate in MIM mode and they're growing in complexity as they try to avoid many of the new software applications that are out to catch them.

      Changing the way authentication happens from 2-factor to 3-factor is the only viable means for defeating most of the current phishing sites, but a slight expansion to some of the new MIM sites will be able to manage that as well. Then what? DNS is definitely not th

  • A Modest Proposal (Score:4, Insightful)

    by Nom du Keyboard ( 633989 ) on Wednesday December 07, 2005 @02:43PM (#14204485)
    What it might take to bring about adoption would be a .sec TLD that only operates with DNSsec, and any other major security improvements. Banks and others might prefer to be associated with a domain that is secure from the beginning, spurring its adoption. This way the market place would decide since it would have a real choice.

    • Re:A Modest Proposal (Score:3, Insightful)

      by schon ( 31600 )
      What it might take to bring about adoption would be a .sec TLD that only operates with DNSsec

      The thing is that this isn't really feasable, because you have to replace all the client software to make it work - and at that point you might as well mandate IPV6 with IPSEC.

      Think about it: DNS is only as secure as its weakest link, and that link is the desktop. If your suggestion is implemented without making every desktop aware of the .sec TLD's requirement to use DNSsec, all an attacker has to do is convince

  • Perhaps better marketing? (Score:4, Interesting)

    by Halo- ( 175936 ) on Wednesday December 07, 2005 @02:44PM (#14204493)
    I know this is a rather stupid thing to be hung up on, but the referenced link (DNSsec.org [dnssec.org]) was so visually cluttered and ugly that I couldn't muster the desire to spend much time there.

    Security is always harder to sell than most products, because you are usually trying to convince a customer to spend more time and money for something without out a tangiable return. (If my DNS hasn't been spoofed yet, why pay money? And even if they do secure it, they don't have an easy way to say: "this saved us X dollars this year, and thus was worth the investment")

    Add in an "official" website which is hard to read, and painful on the eyes, and you've got a hard sell indeed. As petty as it sounds, a better web presence might help ease acceptance.

  • I will admit that a first glance DNS is a real PITA, but a little persistance like with most things and you'll come out smelling of roses. Watching the first AXFR is quite something.

    I thought about doing Secure DNS but seems highly irrelevant on a private home network.

    at the end of the day, it is lazyness, lack of understanding the Whole PictureTM and the old mantra of "Why change what works already".
    • I tried to setup dnssec at one point and just screwed up my working system, as the documentation didn't match the behaviour of the server.

      The biggest killer is having to pay verisign for the privilege.. Domain $15, certificate to authenticate domain $100. Yeah, that'll fly..

  • dnssec and nym ala dan (Score:5, Interesting)

    by arakis ( 315989 ) on Wednesday December 07, 2005 @02:46PM (#14204507)
    Dan is the man in DNS. He pretty much explains why they don't have implementation here:

    http://cr.yp.to/djbdns/forgery.html [cr.yp.to]

    You might not like Dan, but he doesn't get things wrong very often.

    • Re:dnssec and nym ala dan (Score:1, Insightful)

      by Anonymous Coward
      I disagree. Qmail is a prime example of getting things very wrong.

    • Re:dnssec and nym ala dan (Score:3, Interesting)

      by mellon ( 7048 ) *
      Bwahahahahahaha!

      I find Dan highly amusing, and would find a world without him a sadder place, but that's an opinion piece, without an iota of basis for any of the assertions he makes.

      The one factoid he presents is the Microsoft ActiveX key spoof, which is indeed interesting. It also isn't addressed by his proposal, so I'm not sure what good it is. As for querying multiple servers to validate a lookup, that's a fun idea, but you still haven't cryptographically authenticated the information, and all it wo
    • I'm sure Dan is a nice guy, but his work (Qmail) has made me pull my long hair out by the handful. I prefer, that when I install stuff onto a UNIX machine, that the package I am installing doesn't EAT MY COMPUTER. Every time I've succombed to people's opinions about Qmail, and how great it is, and want to give it a try, I am again reminded that sendmail already works, is already installed, and already configured, and that I've just fucked up everything by installing Qmail. As an added bonus, qmail generates
      • However, I think BIND works okay, and I am perfectly happy with my DNS the way it is.

        "Not connected to the internet", then? BIND is notorious for remote root exploits [google.com]. This by you is "okay"?
        • Bind 9 is fine.

        • Re:BIND "okay"? (Score:3, Informative)

          by mellon ( 7048 ) *
          "Not connected to the internet", then? BIND is notorious for remote root exploits. This by you is "okay"?

          Do you mean BIND 8 or BIND 9? Looking at your google query, I see about four different hits that actually have to do with BIND, and they're all about BIND 8, and they are all the same root exploit, not four different root exploits. Along with them is a root exploit for tcpdump - are you proposing that we stop using tcpdump as well?

          Seriously, if you want an open source name server, BIND 9 is an amazin
    • You might not like Dan, but he doesn't get things wrong very often.

      Unfortunately, he doesn't get things right very often, either. His programs are generally thought to be somewhat secure (only "somewhat" because he likes to blame found vulnerabilities on the underlying OS, which does jack all to actually fix the problem), but they tend to earn that reputation by only implementing small subsets of their respective protocols. A DNS server that won't sync to another isn't very useful to most people, but Da

      • Yeah, I used to be a lurker on comp.protocols.ntp, and it was a nice little traditional Usenet group. Everyone polite, informative, etc. Then, one day, this total asshole barges in and starts flaming the regulars. I mean, using profanity and everything. Of course, in ntpd, everything is done for a reason, and it's not perfect, but it's pretty damn good. He started railing on about some leap second issue, and wouldn't stop. Any post that pointed out his shortcomings was typically answered with a stream

  • Money talks (Score:4, Insightful)

    by Billosaur ( 927319 ) * <wgrother@optonline. n e t> on Wednesday December 07, 2005 @02:46PM (#14204514) Journal
    From Computer Business Review: Some registrars talk of adding a "significant" add-on fee for DNSsec "expert services", while others talk of making domain registration a case of picking from two services -- a domain name and a "secure domain name", the latter costing more.

    So in the end, economics will drive SecDNS more than anything else. It seems like a good idea though for some institutions to go to a more secure DNS format. Let's face it: Fred's House of Flowers probably doesn't need as secure a domain as Citicorp or the CIA. The Internet ends up becoming a two-level affair, with the majority of sites being regular DNS sites and corporations and such using the more secure DNS setup.

    • If Fred's House of Flowers has your credit card info, and it's not secure, then it's the weak link in the chain, and it's the place where the attack will happen. I don't mean to say that in order for secure DNS to be useful, everyone has to use it, but certainly if it comes into widespread use and its use makes it a lot harder to spoof secured sites, then the sites that aren't secured are the ones that are going to get spoofed.

      • Fred's House of Flowers wouldn't be doing the credit card processing though. That would be done through a bank or e-commerce firm, and they would supposedly be using the more secure domain. If not, I doubt anybody would do business with them. Social and business pressure would start to force unwilling companies to switch to the more secure format.

  • Redundant (Score:4, Insightful)

    by CyberVenom ( 697959 ) on Wednesday December 07, 2005 @02:50PM (#14204540)
    The problem with SecDNS is that pretty much the same thing is already performed at the SSL level with domain certificates, so there is little argument for changing the DNS system.
    The article says:

    It's possible that a web surfer could think they are visiting their bank or an auction site and hand over their sensitive data, and it would be impossible to tell they were at a malicious site.

    I disagree: there is a good way to tell if that is your bank you are talking to; check that they have the proper SSL certificate for their domain. Or better yet, just look at the color of the address bar in Firefox. If your bank isn't using SSL already, there are reasons far beyond DNS that they should be!
    Also, even with SecDNS in place, physical man-in-the-middle or route poisoning attacks could intercept the communication at the IP level, making SecDNS marginally useful at best. In my opinion, the proper solution would be to encourage more widespread adoption of the existing SSL cert solution for services other than HTTPS. (e.g. SMTP, POP, FTP) Also, it would be good for the industry to have some additional certificate authorities with lower certification prices added to the major browsers' default trust list.

    • Re:Redundant (Score:3, Interesting)

      by Florian Weimer ( 88405 )
      The problem with SecDNS is that pretty much the same thing is already performed at the SSL level with domain certificates, so there is little argument for changing the DNS system.

      Once you've got a DNSSEC-enabled zone, you can put interesting things into it, like CERT RRs with SSH keys. The advantage is clear: you only pay for the delegation (the domain registration fee), and not for each server certificate individually.

      Apart from the threat to existing CA business models, there are also some unsolved techn
    • SSL is helpful for some protocols, but not others. PKI via X.509 is also hard to deploy, and more complicated, and requires distribution of root certs in clients. And the user interface issues
      with SSL in todays browsers is a whole 'nother topic....

      DNSSEC helps secure all DNS-based protocols, even those that couldn't adopt SSL/TLS.
      DKIM (DomainKeys Identified Mail) is the lastest case in point, and if adopted will help drive DNSSEC deployment since it relies on DNS to help stop spam etc.

      http://dki [dkim.org]

  • dear somebody skilled. (Score:3, Funny)

    by blackomegax ( 807080 ) on Wednesday December 07, 2005 @03:05PM (#14204655) Journal
    please go to your local university with a wifi laptop and hack the current DNS system to death.

    its called forced addaptation.
    • Ah, but don't most Universities with wifi force you to VPN before you can access anything? You'd have to be a student to do it and you'd be logged anyway. At least my University is this way.

      On the other hand, there are various places around said University where you can plug in your cat5 and get to the Internet without VPN. Not the places where it's marked as OK to do so, mind you, mostly extra jacks in computer labs. I have a laptop but no wifi, and though I have no intention of doing anything illegal

  • You can't get it. (Score:4, Insightful)

    by mellon ( 7048 ) * on Wednesday December 07, 2005 @03:06PM (#14204666) Homepage
    The main problem with "secure DNS" is that you can't get it. This is because some of the problems remain unsolved - the problem of key rollover is currently generating a huge debate on the namedroppers mailing list, not the least because one of the proposals being advanced is patented.

    On top of that, even if you ignore the signing of the root key, by and large you can't get ad-hoc zone signing - if you want to secure a zone, everybody who's going to see it as secure needs a copy of the zone key, because your top level domain (e.g., .com) isn't in a signed zone.

    On top of that, many TLD providers seem to want signed zones to be a value-added option rather than basic functionality. So as with RSA, lo those many years ago, adoption will be slow because people want to monetize it, rather than seeing it as basic functionality that has to be there.

    So it's no surprise that the end user isn't interested in it yet - they can't get it even if they are interested.
    • The .SE-domain is running a signed zone since a couple of months as the first TLD in the world. Here is all you need to know. [dnssec.nic.se]
      • Yeah, I know, it's very cool, but all my domains are in the US. So I could register in .se, but it would look weird to my users. And it still requires installing the zone key for .se in any resolver that's going to securely resolve DNS entries in my zone, so it's actually not that useful yet. But it is a nice start - I hope more TLDs follow suit.
      • http ://all.your.ba.se/are/belong/to/us

        Am I a bad person if this was the first thing I thought of? (Space added so teh sl4sh doesn't auto-generate link)

    • On top of that, even if you ignore the signing of the root key, by and large you can't get ad-hoc zone signing - if you want to secure a zone, everybody who's going to see it as secure needs a copy of the zone key, because your top level domain (e.g., .com) isn't in a signed zone.

      FYI, there is at least some work being done on getting things signed by something other than your DNS parent. Look for the internet-drafts on "DLV" and the "lookaside" support in bind. It's unclear if this sort of work will a

  • Comment removed (Score:4, Insightful)

    by account_deleted ( 4530225 ) on Wednesday December 07, 2005 @03:26PM (#14204812)
    Comment removed based on user account deletion
    • Everything people trust to be protected and identified by x509 server certs (https, pops, imaps, , etc) has a major weakness: DNS. You can have all the eliptical curve crypto, 4096bit RSA keys, and even someday quantum crypto you want, it all fails utterly if DNS is compromised or spoofed

      Please explain.

      SSL is designed to ensure that DNS spoofing will cause SSL authentication failure. An attacker needs to hijack the domain name and get a matching (signed, trusted) certificate for that domain name in order t
      • Comment removed based on user account deletion
        • All the browser does is make sure the strong cryptographically signed and verified cert's DN matches the totally insecure DNS lookup result.

          Incorrect. The browser checks the certificate domain against the intended domain. The result of a DNS lookup is not part of the trust equation. This is the great thing about end-to-end security, everything else in the path doesn't even matter.

          I agree that the way domains and certificates are purchased is ridiculous. For God's sake why are we still proving email addr
  • DNSSEC is just one piece in an overall risk management process. There are other pressing issues on the same list. As was posted already, until there is an attack that makes securing DNS an immediate issue for an organization or a country there will not be as much action toward it. It is common for risk management to focus on the threats of today and attacks of yesterday. We are wrapped up in the past and not looking at threats and attacks of tomorrow. This appears to be where we are with securing DNS.

    H

  • Actually, existing DNS can be very insecure... (Score:4, Informative)

    by hkhito ( 901607 ) on Wednesday December 07, 2005 @03:29PM (#14204833)
    ... even at very well managed sites. This recent paper [cornell.edu] from Cornell lays out some of the problem, showing how even the www.fbi.gov name can be hijacked by hacking in to seemingly completely unrelated servers, such as one of the name servers at telemail.net.

    So for example, to hijack www.hsbc.com, you don't have to worry just about hsbc's name servers, com's name servers, and the root name servers. You also have to worry about the other servers that hsbc and com have deligated to, and the servers that they have deligated to, and on and on.

  • Another word for "security early adopter" is fool.

    DNSSEC is not secure because it doesn't address the fundimental issues with security and nameservers.

    * It doesn't stop cache poisoning attacks- a client resquesting a name from a poisoned cache won't get the key so they won't know anything is wrong.

    * Breaking the nameserver itself gives you the keys as the nameserver is required to sign the resource records, so in this case, it gives people a false sense of security that they don't have!

    * Finally, as it stan
    • DNSSEC is not secure because it doesn't address the fundimental issues with security and nameservers.

      I'm not sure you've read the specs...

      It doesn't stop cache poisoning attacks- a client resquesting a name from a poisoned cache won't get the key so they won't know anything is wrong.

      Like all security, you need a trust-anchor root. This is the same way that your browser has a list of trusted root CA certificates. DNSsec requires something similar: a list of keys for roots that you trust. It a can se

      • I'm not sure you've read the specs...

        What gives you that idea?

        Like all security, you need a trust-anchor root.

        Wrong. You need what RFC 4033 calls a "trust anchor" if you want to prove identity (that the resource is what it claims to be), not if you want to prove authority (that the resource is being generated by the correct host) or integrity (that the resource data hasn't been altered). Go read ISBN 0471117099 for practical algorithms if you like.

        Meanwhile, existing attacks on DNS have involved subverting
        • You need what RFC 4033 calls a "trust anchor" if you want to prove identity (that the resource is what it claims to be)

          true

          not if you want to prove authority (that the resource is being generated by the correct host)

          The resource can't be signed by an incorrect host (holder of a key; not a host) unless the key has been stolen or broken. Obviously, if you don't have a trust anchor then an attacker can generate any key it wants if you'll believe it. With a trust anchor, however, you won't believe it.

          or

  • A lot is happening with DNSSEC these days. It is being deployed in the ccTLD for Sweden: ".se" Check out

    http://dnssec.nic.se/ [dnssec.nic.se]

    Tutorial/howto: http://www.ripe.net/disi/dnssec_howto/ [ripe.net]

    $ dig @bind.dnssec.se www.ripe.net +retry=1 +dnssec +multiline
    and look for the "flags" to include "ad": ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

    http://www.dnssec-deployment.org/ [dnssec-deployment.org]
    Threat Analysis Of The Domain Name System
    IETF RFC 3833 http://www.rfc-archive.org/getrfc.php?rfc=38 [rfc-archive.org]

  • Why?? (Score:2, Insightful)

    by jskline ( 301574 )
    Why on earth would you expect them to embrace it?? There is NO cost incentive to go to this. Apparently something catastrophic has not yet happened to emtpy the coffers and there-by motivate them...

Slashdot Top Deals

Fast, cheap, good: pick two.

Close