Trend Micro Facebook TrendLabs Twitter Malware Blog RSS Feed You Tube - Trend Micro
Search our blog:

  • Recent Posts

  • Calendar

    August 2014
    S M T W T F S
    « Jul    
     12
    3456789
    10111213141516
    17181920212223
    24252627282930
    31  
  • About Us

    Earlier this week the folks over at OpenDNS announced a preview release of their new tool DNSCrypt. This is touted as a huge step forward for privacy and security across the Internet. The premise is simple, encrypt all DNS traffic between the user and their recursive resolver. It’s a nice idea and all, but I think they missed the mark.

    According to OpenDNS, the code is actually the first real-world implementation of the DNSCurve scheme. The stated goals are to provide privacy and authenticity to the entire DNS transaction. Unfortunately, you can’t just wrap an existing protocol with crypto and expect to be more secure than you were before. In this case you need to look at the entire ecosystem. Sure your DNS query will be private, invisible to other users or attackers on the same network. The problem comes a few milliseconds after you get the result. The privacy you gained by encrypting your DNS traffic evaporates when the browser makes its request of the server. An attacker in a position to see your DNS traffic is likely to have the same visibility into other forms of traffic.

    If you are more concerned with authenticity of the data than privacy, there are better ways to get that as well. DNSSEC is ready to answer your call. A major advantage of DNSSEC is that in the case of some TLDs it can authenticate the result all the way to the root (This list includes an indication of which TLDs are signed). According to the DNSCrypt FAQ at OpenDNS, DNSSEC and DNSCrypt function perfectly in concert: “They aren’t conflicting in any way.”

    DNSCrypt also possesses the interesting side-effect of driving more traffic to the OpenDNS infrastructure. They have open-sourced the client code, but they currently have the only running server implementation. If you are concerned that your ISP is sniffing your DNS traffic are you likely to be any less concerned that OpenDNS is doing the same thing?

    Conclusion

    Unfortunately, just wrapping existing protocols in encryption is not always the answer. In this case I would agree that the DNS conversation itself does become more secure. However, that additional privacy only applies to DNS. Other protocols are just as exposed as they were before.

    If you want to ensure that the DNS replies you receive have not been tampered with, look to DNSSEC. If you are concerned that someone in the path is sniffing your packets and could tie Internet activity to you, consider using Tor or other VPN/proxy services.





    Share this article
    Get the latest on malware protection from TrendLabs
    Email this story to a friend   Technorati   NewsVine   MySpace   Google   Live   del.icio.us   StumbleUpon




    • https://sites.google.com/site/jimerickso/ Jim Erickson

      dnscrypt-proxy is on github and is available for netbsd, openbsd, freebsd, dragonflybsd, and linux.

    • Pingback: DNSCrypt – 不是根本解決之道 | 雲端防毒是趨勢

    • Ben April (Senior Threat Researcher)

      Henry, There are 2 problems targeted by DNSCrypt. DNSSEC solves one of them and ignores the other. DNSSEC does solve the authenticity problem rather well, better than DNSCrypt in fact. With DNSCrypt you know the answer you get is the one that OpenDNS intended you to have. You have no way to know if that is the same answer that the domain owner intended.

      Sure, the DNSSEC roll-out has a long way to go, and I don’t think anyone can say it is perfect. But it is started, the community as a whole is working on it. For better or worse we will have one global solution. DNSCrypt is right now connected to only one vendor and as of this moment is only supported on Mac. As a tool I believe it works, however I am skeptical of its utility.

    • Ben April (Senior Threat Researcher)

      Torch, I agree that endpoint sniffing is probably the biggest risk to TOR users. Depending on your browsing hygiene, and surfing habits this may or may not be cause for concern. It is hard for someone sniffing a TOR endpoint to determine the ultimate source of the traffic if the TOR user is following best-practices (using TOR aware applications, visiting SSL sites, etc.). In the context of this article we are primarily concerned with the “first-mile”. Getting queries/requests into and replies out of the network without the ISP or regional carriers knowing where you are headed, for which TOR will work fine. We have entirely different problems if we try to keep the web-server operator from knowing where we are and what we are doing.

    • Henry Barber

      Good catch ^

      Not only DNSSEC doesn’t solve the same problem, but it also requires applications, operating systems, routers, firewalls, proxies, caches, ISPs, carriers and registrars to support it at scale before being actually useful.
      As we speak, and just like IPv6, there is still a long way to go.

      The fact that even Trend Micro doesn’t support DNSSEC yet is quite telling.

      DNSCRYPT doesn’t completely solve the problem, but it is available now and it is still better than just words.

    • Jay

      The only problem with DNSSec is that it hasn’t been widely deployed yet. For example trendmicro.com has no DNSSec records.

    • Torch

      You suggested using Tor, which is not a great idea because of the exit node sniffing that can / will occur, and when that happens you lose all anonymity / privacy / security.
      I will look further into the DNSCrypt that OpenDNS is working on.

      But please don’t suggest a tool like Tor without stating its biggest flaw.



     

    © Copyright 2013 Trend Micro Inc. All rights reserved. Legal Notice