Slashdot Mirror


Secure DNS a Hard Sell

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."

36 of 142 comments (clear)

  1. Nice, but not necessary by ehaggis · · Score: 4, Interesting

    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.

    --
    One ring to bind them - should probably have more fiber and less rings in their diet.
    1. Re:Nice, but not necessary by razvedchik · · Score: 5, Informative

      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.

      --
      I do what the voices on my console tell me to do.
    2. Re:Nice, but not necessary by timeOday · · Score: 3, Informative
      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.

    3. Re:Nice, but not necessary by mellon · · Score: 2, Interesting

      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 I have to do is present a copy of the real web page that has all the https:/// strings substituted for http:/// - at that point unless you're fairly sophisticated, you're going to wind up sending your info to the spoofer, and you're not going to know that you've been spoofed.

      This is not to say that secure DNS is a panacea, but if it were deployed on a widespread basis, it would solve a number of significant problems.

      By the way, speaking of SSL again, it has no root key rollover. Your root keys are preconfigured in your browser. So if a root key is ever compromised, your browser is going to be vulnerable until such time as you download a new copy, even assuming that the root key compromise is detected. DNS also lacks root key rollover right now, but this is a problem that is being worked on, whereas as far as I can tell in the SSL world, at least on a practical level, it's not.

    4. Re:Nice, but not necessary by turbidostato · · Score: 2, Insightful

      "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.

    5. Re:Nice, but not necessary by bogado · · Score: 3, Insightful

      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.

      --
      []'s Victor Bogado da Silva Lins

      ^[:wq

    6. Re:Nice, but not necessary by askegg · · Score: 2, Insightful

      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.

      --
      I don't make predictions, and I never will.
    7. Re:Nice, but not necessary by memodude · · Score: 2, Insightful

      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.

  2. Hard to understand by Mr.+Flibble · · Score: 4, Insightful

    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."

    --
    Try to hack my 31337 firewall!
  3. bigger fear by keithhackworth · · Score: 5, Interesting

    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
    --
    Support bacteria. They're the only culture some people have.
    1. Re:bigger fear by Dolda2000 · · Score: 4, Interesting

      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.

    2. Re:bigger fear by iambarry · · Score: 2, Interesting

      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.

    3. Re:bigger fear by hal9000(jr) · · Score: 4, Informative

      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.

    4. Re:bigger fear by baadger · · Score: 2, Interesting

      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.

    5. Re:bigger fear by hal9000(jr) · · Score: 2

      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?

    6. Re:bigger fear by Agelmar · · Score: 4, Insightful

      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.

  4. Same as Sony by Nom+du+Keyboard · · Score: 5, Insightful
    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?

    --
    "It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
  5. secure domains by digitaldc · · Score: 3, Funny

    "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?

    --
    He who knows best knows how little he knows. - Thomas Jefferson
  6. Not gonna happen anytime soon. by Crispix · · Score: 2, Informative

    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.

  7. A solution looking for a problem? by 26199 · · Score: 3, Insightful

    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?)

  8. A Modest Proposal by Nom+du+Keyboard · · Score: 3, Insightful

    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.

    --
    "It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
    1. Re:A Modest Proposal by schon · · Score: 2, Insightful

      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 your desktop to talk to his DNS server (which is pretty easy, if you think about it) and it's game over.

  9. Perhaps better marketing? by Halo- · · Score: 3, Interesting
    I know this is a rather stupid thing to be hung up on, but the referenced link (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.

  10. Re:Nice, but not necessary-A royal pane. by stefanlasiewski · · Score: 2, Funny

    Windows is not a fish. It's a feature.

    --
    "Can of worms? The can is open... the worms are everywhere."
  11. dnssec and nym ala dan by arakis · · Score: 5, Interesting

    Dan is the man in DNS. He pretty much explains why they don't have implementation here:

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

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

    1. Re:dnssec and nym ala dan by mellon · · Score: 2, Interesting

      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 would take to hack this would be to successfully spoof the NS records for the zone, which isn't particularly harder than spoofing the zone itself.

      The reason that reputation-based security works is that you have an active, intelligent participant tracking reputation; even in that case, it works only so well - many of the spoofs we're talking about here actually take advantage of someone's trust in reputation, by convincing the person that they are talking to someone to whom they are not actually talking. The better a critical thinker you are, the better reputation-based security will work for you; the more you know in the moment about the person to whom you are talking, the better it will work for you. Lacking either of these, as is the case with Dan's proposal, you've got nothing but a house of cards.

  12. Money talks by Billosaur · · Score: 3, Insightful
    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.

    --
    GetOuttaMySpace - The Anti-Social Network
  13. Redundant by CyberVenom · · Score: 3, Insightful

    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.

    1. Re:Redundant by Florian+Weimer · · Score: 2, Interesting

      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 technical problems (cryptographically secured negative answers without providing zone enumeration, for example).

  14. dear somebody skilled. by blackomegax · · Score: 3, Funny

    please go to your local university with a wifi laptop and hack the current DNS system to death.

    its called forced addaptation.

  15. You can't get it. by mellon · · Score: 3, Insightful

    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.

  16. A real shame too by finkployd · · Score: 3, Insightful

    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. It is really odd that so few people seem to care. It is kind of like putting a hundred dollar deadbolt on a screen door.

    The only solution is either get secure DNS, or find a way to securly exchange keys out of band (rendering the point of x509 kind of moot)

    Finkployd

  17. Reason for not rushing adoption by kts.nm · · Score: 2, Informative

    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.

    Hopefully some awareness and early adopters combined with some guidance on cost and benefit will change this.
    --
    -Ke

  18. Actually, existing DNS can be very insecure... by hkhito · · Score: 4, Informative
    ... even at very well managed sites. This recent paper 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.

  19. Re:BIND "okay"? by mellon · · Score: 2, Informative

    "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 amazingly high-quality piece of software. I've never used djb's software, because I hate managing patch trees, and because I like BIND 9's automatic, secure zone transfers, which aren't supported by djbdns. Perhaps there is some value in it, but it's not worth it to me. Also, the cult of personality implicit in naming a product after yourself upsets my stomach. Should I have called the ISC DHCP server tedhcp?

    If you are running BIND 8 because BIND 9 doesn't perform as well, first of all, the difference probably isn't as great as you've been led to believe. Secondly, you can probably afford a high-quality commercial name server, such as the one my employer makes. Personally I don't think running BIND 8 is worth the headaches - it was a credible piece of software in the early days, but by the time version 8 rolled around, it was due for a rewrite, and that's why the ISC in fact completely rewrote it from scratch for version 9.

  20. Why?? by jskline · · Score: 2, Insightful

    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...

    --
    All content in this message is copyright (c) 2008. All rights reserved. RIAA is prohibited here.