8 ms·
OpenDNS launches DNSCrypt: secure DNS
- sp332 15y agoI think this could actually break a few things. For example, Netgear routers intercept DNS requests for routerlogin.net and return their own internal admin IP. It's a very useful feature, and it works no matter what DNS service you use.
- derleth 15y agoIf you're technical enough to set this up, you're technical enough to add a special rule in /etc/hosts or local equivalent to fix the problem.
- JoshTriplett 15y agoThat shouldn't work, and breaking it represents a useful feature. Use a sensible local DNS root, not a well-known one like .net. (Does some standard reserved namespace exist for the local network, instead of the various non-standard ones like .home or .lan? RFC2606 only reserves .invalid, .test, .example, and .localhost, none of which work for this purpose.)
- ecaron 15y agoWhile the blog only links to the Mac client, they do have a DNSCrypt proxy that appears fairly complete and should be a good compliment to any *nix system: http://shared.opendns.com/dnscrypt/packages/dnscrypt-proxy/ http://shared.opendns.com/dnscrypt/packages/dnscrypt-proxy/
- webwanderings 15y agoWhoaa...I am not very technical, but the first question that comes to mind is, what would be a difference between this and what Tor attempts to accomplish?
- e1ven 15y agoThey're really unrelated. Tor proxies your traffic through several random machines on the internet, so by the time it gets to the destination, no one knows who sent it. This captures and relays your DNS queries to OpenDNS in a new way. DNS queries are used to translate a site's name ( facebook.com ) into it's internet address - 123.456.789. OpenDNS has run a service which did the translation for a long time, but when you ask them to translate, it passes through your ISP, so your ISP could, in theory, see what domain name you were asking about. This has a way of encrypting the request, so that OpenDNS can answer the translation, without anyone but you being able to see what you asked for.
- mkup 15y agowithout anyone but you being able to see what you asked for. and without anyone being able to replace IP address of facebook.com with IP address of some MitM server (in the ISP network, for example)
- marshray 15y agoOr perform MitM on the raw IP packets without modifying the IP addresses at all. (Like your ISP or any other router along the path.)
- parfe 15y agoMy ISP can see which IP addresses I connect to and can perform a reverse lookup. I don't think the privacy angle has any value. I suppose a shared host could serve multiple sites, but then simple packet snooping would reveal which hostname I am requesting.
- e1ven 15y agoI agree. Something like a full-on VPN would be safer.
- peterwwillis 15y agoSo a vendor/service provider makes a custom proxy for DNS record encryption and breaks the first rule of cryptography. Granted, they're basing it on DNSCurve so at least a few other people have looked at the design, but the implementation is custom... I wouldn't touch this with a 50 foot pole until a dozen PhDs vet it. edit I didn't notice libnacl is provided, so I assume a good chunk of the crypto work is done by this. My comments were probably too harsh. But I would still like to see a professional look over the rest of their code to make sure there's no glaring problems.
- sp332 15y agoTry reading the description of the crypto, it might make you feel better: http://dnscurve.org/crypto.html http://dnscurve.org/crypto.html Basically it follows NSA recommendations for public-key crypto and uses an algorithm developed by Daniel J. Bernstein which adds even more guarantees. So it's not like they're starting from scratch here.
- peterwwillis 15y agoThe problem isn't whether or not they're using a strong crypto algorithm as much as who implemented it and whether there was intense peer-review or not. Anybody can try to implement an algorithm, but most will probably screw something up, which is [one part of] why the first rule of cryptography is: don't do your own cryptography. Luckily, the library they're using (NaCl) is part of a project led by djb, thus we can assume it's going to be competently written and reviewed by him. I hadn't seen this so this makes me feel better about the crypto part of their project.
- marshray 15y agobreaks the first rule of cryptography That would be the "don't bother encrypting that which is not authenticated"? ISTR a free DNS resolver company (I think it was OpenDNS) doing a MitM on my friend's Google searches when he used them. Or are you just against anyone deploying new crypto protocols?
- 15y ago
- MikeCapone 15y agoWhat kind of performance hit would this give, if any?
- dkokelley 15y agoI doubt much, if any. While DNS requests are relatively light, there may be several requests that need to resolve for a single page request. The crypto DNSCrypt looks to be using will use public keys to share a symmetric key, so after the first transaction both sides will have a symmetric key. Symmetric key encryption and decryption should be imperceptibly fast. Also, you only need to "refresh" as often as your local machine's DNS cache clears.
- sudonim 15y agoI've been using DNSCrypt over the past few weeks as a beta tester. I'm pleased that it doesn't have any noticeable decrease in speed while browsing the web. It improves my security and privacy without any cost I can perceive. So why not. Considering it took me a while to understand the value to me, I wonder if it can be packaged in such a way to get broader adoption from the public. Will you have to bundle it with McAfee Internet Security for Mom & Pop to end up using it?
- dsl 15y agoIt also has the option to tunnel your DNS over TCP/443, avoiding all the dumb things wifi hotspots try to do with your DNS.
- tptacek 15y agoIf you're going to run DNS over TLS, you probably don't need DNSCurve anymore.
- dsl 15y agoIt's not TLS.
- tptacek 15y agoIt should be!
- SoftwareMaven 15y ago(Serious questions) What benefit does TLS provide over the elliptical-curve cryptography it uses? Would it be possible for somebody to filter the DNS queries by identifying the use of elliptical-curve cryptography instead of TLS (obviously they couldn't read them, but could they stop them)?
- tptacek 15y agoNone. The advantage to DNSCurve is that it's optimized for the DNS service model (it's tighter and faster). The advantage to TLS is that you already have it. The advantage of DNSCurve over DNSSEC isn't really the ECC (DNSCurve's ECC is better than DNSSEC's crypto by a mile, but neither DNSSEC nor DNSCurve have known practical crypto attacks). The advantage of DNSCurve is that its security model is much more realistic. Instead of trying to make every DNS record a secure document that can be verified in isolation, DNSCurve simply ensures that your browser can make a secure request do a DNS server somewhere (and, by implication, that the DNS server can itself make secure requests to other DNS servers, and on and on incrementally until the whole DNS is secure). Think of it this way: DNSSEC is what web security would be if it worked by signing web pages. DNSCurve works roughly the way web security works now, with a drastically streamlined and (probably) improved crypto protocol.
- pclark 15y agoI installed this on Mac 10.7.2, previously using Google DNS. It works fine when I have the "use OpenDNS servers" box checked, but the moment I click the "use encrypted OpenDNS severs" box my internet connection doesn't resolve anything. I tried to send them feedback but the form doesn't appear to submit. (Hardly reassuring.)
- dsl 15y agoCheck the "DNSCrypt over TCP" box and see if it starts working. If so, something on your network is intercepting DNS queries.
- trotsky 15y agoWhy bother securing your DNS from eavesdropping when an eavesdropper can easily tell what sites you're visiting based on your other IP traffic? It seems OpenDNS is interested in this technology only as far as it deflects from people being interested in DNSSEC, an ietf standard. Why don't they care for DNSSEC? Because it either discourages or prevents DNS poisoning or hijacking (depending on how you set up your client) and Open's business model relies on hijacking NXDOMAIN DNS responses to serve ad filled pages.
- tptacek 15y agoConfidentiality isn't the killer feature/flaw here; integrity is. DNSSEC is a design-by-committee debacle. It's a good thing to have options here. I'm a broken record on DNSSEC on HN; a decent starting point might be: http://news.ycombinator.com/item?id=2078488 http://news.ycombinator.com/item?id=2078488 (Goals of DNSSEC v. DNSCurve) http://news.ycombinator.com/item?id=1523704 http://news.ycombinator.com/item?id=1523704 (Bunch of things I think are wrong with DNSSEC)
- deleted 15y ago[deleted]
- FaceKicker 15y ago> Confidentiality isn't the killer feature/flaw here; integrity is. I initially posted "Authentication, too" in response to this, but then I reread the page and it says it doesn't provide authentication. ...in which case, I don't really understand this at all. What good is integrity if there's no authentication? Doesn't that mean an active network attacker can completely swap out the DNS response for a different one, but just can't modify it (short of creating a brand new one)? If that's the case, it seems completely useless. It claims to protect against man-in-the-middle attacks, but I don't understand how that's possible if there's no authentication. I'm sure I'm missing something here.
- tptacek 15y agoDNSCrypt is a DNSCurve implementation. DNSCurve is manually keyed; "the administrator publishes the server's public key along with the server's address", which is effectively shorthand for "static keying is left as an exercise for the reader". You can't MITM a DNSCurve request, because it's encrypted and signed using a pair of static keys.
- aidenn0 15y agoDo they really claim that the last-mile is the most insecure part of DNS? They specifically mention the kaminsky attack, which was best used against DNS servers, not individual PCs. This is really only an improvement for open wifi, but then you can MITM the IP without having to hijack DNS.
- tptacek 15y agoDNSCurve is a proposal for a solution to cache poisoning (which is a problem that dates back to the mid-90's) that admits to incremental deployment. On day one, it protects the desktops that opt into deployments provided by servers that opt into it. But unlike with DNSSEC, which retains the DNS' architectural distinction between the stub resolver in your browser or OS and the cache server at your ISP, the same security protocol that secures the "last mile" with DNSCurve is also workable between servers. Most notably, deploying that secure option does not require the server to change its database. The day 1 benefit of having a secure channel between browsers and resolver servers probably addresses 60% of the DNS security problem in reality --- that's not a small win, it's an immense win. But even in the long run, DNSCurve is a more workable path to secure name resolution than DNSSEC.
- aidenn0 15y ago"The day 1 benefit of having a secure channel between browsers and resolver servers probably addresses 60% of the DNS security problem in reality" Don't most users use their ISP's DNS servers, making hijacking between the browser and resolvers nearly impossible?
- tptacek 15y agoNo, because the existing standard DNS protocol is terribly insecure. Also, because it's insecure, you can't productively opt on to a more secure provider.