Posted
by
Soulskillon Tuesday January 29, 2013 @03:01PM
from the rome-wasn't-built-in-5-years-either dept.

alphadogg writes "Five years after the disclosure of a serious vulnerability in the Domain Name System dubbed the Kaminsky bug, only a handful of U.S. ISPs, financial institutions or e-commerce companies have deployed DNS Security Extensions (DNSSEC) to alleviate this threat. In 2008, security researcher Dan Kaminsky described a major DNS flaw that made it possible for hackers to launch cache poisoning attacks, where traffic is redirected from a legitimate website to a fake one without the website operator or end user knowing. While DNS software patches are available to help plug the Kaminsky hole, experts agree that the best long-term fix is DNSSEC, which uses digital signatures and public-key encryption to allow websites to verify their domain names and corresponding IP addresses and prevent man-in-the-middle attacks. Despite the promise of DNSSEC, the number of U.S. corporations that have deployed this added layer of security to their DNS server is minuscule."

DNSSEC is a flaw too! Once I watched a keynote from Daniel J. Bernstein at FISL pointing out all the flaws that make DNSSEC vulnerable. So he pointed to a better solution called DNSCurve: http://en.wikipedia.org/wiki/DNSCurve

He doesn't get it. People who tout SSL keys in DNSSEC are very aware of the hierarchical nature of the DNSSEC trust relations and who we would be trusting if we used DNSSEC to distribute SSL keys. The point is that we're already trusting the very same people now, in addition to the CAs, and they're not even using trustworthy DNS yet. When you get a certificate from a no-frills CA, you only need to be able to receive mail at one of a few local parts under the domain that you want the certificate for. Bam, ev

That isn't a criticism of DNSSEC. That is a criticism of using DNSSEC for things other than DNS resolution. Domain names and IP addresses have to be allocated in a centrally managed fashion, so to avoid conflicts. DNS already has a hierarchical design by nature and DNSSEC simply makes it more secure.

SSL key distribution/validation on the other hand doesn't have to be centrally managed, so adopting a hierarchical control structure like DNSSEC for that task is a suboptimal solution. In fact the problems in th

In fact the problems in the CA system we currently have directly stem from such a hierarchical trust scheme. We would be much better of going with a truly distributed system for SSL key validation.

I'm unconvinced. (I'm particularly unconvinced by the handwave-assert-jedi-mind-trick style of argument there, but that's by-the-by.) The fundamental problem is that it is very hard to work out if the assertions in a public certificate are true; all you can tell is that the information was digitally signed by someone or something. With a web of trust model, either you have non-transitive trust (which totally doesn't scale at all!) or you have transitive trust, in which case all it takes is for one person to

Having delved into both deeply, implementing DNSCurve in one server and partially having implemented DNSSEC elsewhere, I can give you a better comparison.

DNSCurve secures the channel between a recursive DNS cache and upstream authoritative servers. It does not attempt to secure the client->cache channel, although there have been related proposals (modifications of the same basic guts DNSCurve had) to secure that channel as well. DNSCurve is designed for a world where you implicitly trust your cache. E

DNSSEC was designed around real world constraints, not the mythical world where every resolver can talk to authoritative servers directly or only through trusted recursive servers. Yes, there are ISP that force you to use their name servers.

DNSSEC is designed to cope with untrusted authoritative servers. Most people don't have the resources to provide the servers necessary for fault tolerance. With DNSCurve you have to trust those operators to not change the data as any change they make can go undetecte

BTW dnssec adoption is amongst the highest for.nl in absolute numbers of domains, simply because there is a bounty for every domain signed. If you have a few hundred of domains the costs to implement are lower than the discount given till mid 2014

Math fail detected: 250*10^6 domains, 5*10^6.nl, 10^6.nl with dnssec. So atleast 0.4% of all domains are dnssec:5/250/5 == 0.004 * 100% == 0.4%.nl is in the 5 top of most used country TLDs..nl is used for about 70% of the domains targetting the dutch market. So dnssec implementation is huge for the local market. And while it still might not be perfect, it is better than just plain DNS.

Whether it's the AC's numbers or your numbers, you're both talking about less than a percent as though it's greater than a margin of error in the real world. Export your expertise and let's all work on dotcom next.

Like I said, for the local market dnssec presence is huge, and last time I checked NLD is still part of the real world and it still has some influence on it (especially considering its size).

But.com has everything in place to do dnssec. So if an owner of a.com wants to get dnssec support, they should get a dutch dns provider, there are many that give the customer the option to activate dnssec.

No catch, just a discount per domain registered for dnssec (0.28 EUR/year). I have about 1k.nl domains, I spend a few days figuring out what dnssec was about, how to implement, test and maintain it. Activated it on the corporate domain, some personal and a couple of test domains and waited 2 months to see if there were problems (none). So now it is active for all domains saving us 420 EUR till the discount ends in 2014-06. For us it was not enough to cover the expense of my time, but this had to be implem

If you just kept reading instead of getting distracted by flash, you'd have seen the next link point to human readable text explaining (briefly) how dnssec works and how to implement it for a specific named. I just have to hope you read past flash this time.

Many potentially targeted organizations will not spend the time and money to make the necessary changes without prodding. I've seen this in payment security too: A lot of companies are shocked and dismayed when they find out that they are supposed to store credit card numbers in some way other than in plaintext in a database accessible to anyone with the single database login that everyone in the company has.

The only thing that will prod them is experiencing a cost of doing nothing that is higher than the cost of implementing the solution.

It broke access to several DNSSEC enabled websites that were misconfigured. After a few months of support problems where we suggested the websites fix their issues and they ignored it, it was requested by management that we turn it off.

It's a very bad design as it stands now. It's unable to return any error but NX Domain for DNSSEC errors for reasons of backword compatibility, which is stupid since you need a DNSSEC enabled resolver to make the request.

It also has an incredibly steep learning curve that even experienced public key administrators face problems with.

Would either the parent or GP like to list some sites that were broken with DNSSEC? There are some decent tools to test DNSSEC queries, so I'm surprised the DNS admins for the broken zones have left it broken. There's not really any half-assed zone signing with DNSSEC, you either sign the entire zone or you don't.

"its certificate system is just as broken as the SSL cert system is now"

Can you explain this? DNSSEC hasn't got much common with the SSL cert system. There is only 1 root authority, the weak point during a key change. Each domain/tld has their own (multiple) keys. tld and domains should regenerate the short Zone Signing Keys fairly often (a couple of weeks), while the bigger Key Signing Keys should be regenerated about once in a year. If a tld is compromised it only has to create a new KSK, individual domai

Too many people in there. Somebody will either mess up or be corrupt. A PKI only works in practice if there is a single CA or a very small number of CAs under tight control. Ignoring the non-technological angle is just incompetent.

But there are no CAs in DNSSEC. There are only public/private keypairs under control of the owner of the domain.www.example.com. has 3 pairs/signatures to check:

.

com.

example.com.

example.com. tells the com. authority what it's public KSK is.com. tells the root zone what it's public KSK is.The public KSK of the root is known by all people/software that want to check dnssec signatures (the weak point since how do you securely distribute and update that one?).

The public KSK of the root is known by all people/software that want to check dnssec signatures (the weak point since how do you securely distribute and update that one?).

The usual way with PKI is to have two identities involved in the root. One, the master, has a public key very widely known and with a very long life, and only ever used to validate the "operational key"; the master private key is kept offline in a safe somewhere. Perhaps with armed guards or something like that. The operational key is what is used to validate child domains, and as such is in use a lot more and so is more exposed. On the other hand, you can generate new ones (with only the hassle of the arme

"Or how do you think the signature of com gets onto the public key of example.com? Magic?"

It doesn't. And you are confusing a web of trust with CA, it's like PGP. com. can only tell a dnssec user what it thinks the public KSK of example.com. is. That should have been communicated in a secure way to com. It is oneway trust between direct parent-child relations in the dns tree.

Indeed. The problem I see with things like DNSSEC is that it implies trustworthiness that may well not be there, hence I understand why people are not bothering with it. (Aside from it being another protocol monster form a really clueless tram...) It is also generally not needed for things like remote access, just use 2-sided authentication.

Except the largest cable ISP in the US, Comcast, has DNSSEC resolvers enabled for customers by default, and they manage to deal with these problems.

They even track and publish informaiton of (large) failing domains and in the backend work with website owners to notify them of the deficiancies. As a Comcast customer, I notify the Comcast DNS folks whenever I have DNSSEC problems, as they have a large amount of clout and will use it to notify website owners.

We beat Comcast to the punch by about a year. I'm happy that they turned it on and can afford to support it, but 90% of the customers you have are dumb and don't care why it doesn't work from your ISP, they just care that it works at Starbucks and doesn't work at their house.

Being a huge monopoly has an advantage when it comes to telling customers to pack it up when they have DNS issues. I too am a comcast customer and I run my own resolver (for flexibility, not because they implemented DNSSEC)

It also has an incredibly steep learning curve that even experienced public key administrators face problems with.

There's a way to do it in the name server itself, but here's a way for newbies:

1. in named.conf.local, change file "example.org.zone"; to file "example.org.zone.signed";2. where you would do rndc reload example.org after a change, you instead do zonesigner --usensec3 -zone example.org. example.org && rndc reload example.org3. read the key-signing key zonesigner created, log in to your registrar, add a DS record by pasting data from that file4. if you want the keys to expire (zonesigner's default), s

SIDN (the maintainer of.nl) offers a small discount to domains that use DNSSEC. This was sufficient motivation for a few large hosting companies to enable DNSSEC across all their domains. In just a few days a fifth of all Dutch domains switched over. By now 26% of the.nl domains (1.381.790 out of 5.153.408) use DNSSEC.

Agreed. Implementing DNSSEC is a royal pain in the ass for the authoritative server operator. If it was easy, many would have done it.

Additionally, your domain registrar must support DNSSEC to list the digest records or even public keys with the registry so they can be listed in the TLD-root zone. Once you sign a domain, you cannot transfer the domain to a non-DNSSEC-implementing registrar.

What? When you transfer a domain, you usually KEEP the existing nameservers. It's often not wise to use DNS provided by your registrar -- because then when transferring the domain, you need to pre-copy the zone to a new DNS provider.

Yes, you can move the DNS zone from a set of nameservers to another set of authoritative servers, and reducing TTLs for the SOA and NS records are advisable before making that change. However, the registry operators almost always set 48 hour TTLs on the set of authoritative nam

Indeed. Security is even more dependent on simplicity and clarity than reliability is. Today, we have not even really mastered software reliability and then some people think a complex security mechanism is a good idea? Talk about really not getting it.

If your security depends on DNS working, you are screwed anyways. That is likely the main reason nobody uses DNSSEC: It does solve the wrong problem.

1. The sane way for remote access it is to require 2-sided authentication on connection, making DNSSEC entirely redundant.2. For the open web, things are a bit differently, but there you can land on a malicious page any time and the only solution for that is a not vulnerable browser or a secure browsing environment.

There is also the small issue that DNSSEC is badly borked and a nightmare to install and maintain. In addition, the other PKI (SSL certs) is badly broken, and there is really no reason the DNSSEC PKI would fare any better if widely deployed. In the long run, it is very likely that DNSSEC is just a waste of time and effort.

2-sided authentication was mandated in the early IPv6 specs by the IPSec mechanism. Sun offered an alternative, SKIP.

Since then, both have been ported to IPv4.

IPSec is occasionally used by VPN clients, but that's about it. Most VPN clients are run on laptops or other portable devices, often over a wireless link. This is where Sun SKIP was stronger than IPSec, which is ideal for a wired network but gets noisy when you've links that aren't guaranteed stable and error-free.

And this is relevant how? IPsec is known to be another protocol monster by clueless designers. How IPsec ever passes the IETF process is a mystery to me. Numerous people must have messes up simultaneously.

TLS (as in OpenVPN, for example) and SSH for UNIX provides a much better basis for 2-sided authentication, and both are in widespread use.

The problem with IPv6 adoption is its design, not politics. It was designed as a replacement instead of IPv4 backward-compatible extension. An administrator and end-users have to go through hoops to make this garbage work, and that's why nobody wants to. Why should/would they? IPv6 should have been designed such that neither administrators, nor end-users would have to do much to upgrade.

IPv4 is intrinsically incapable of being secured. So, if you want to design a secure IP protocol, you cannot have one that is backwards-compatible.

IPv4 is also necessarily fragmented - there is no correlation between IP address and location within the network, leading to bloat in router tables, inefficient routing decisions, excessive latency and greater vulnerability to MitM attacks via router poisoning.

How "major" is the flaw when there are few reports of it being used in attacks? People will change their behavior when there is a real reason to do so. Until there is an upswing in DNS cache poisoning, most will see no reason to go to the expense of converting. As another poster pointed out, there are plenty of other techniques attackers are using to impersonate websites.

There are few reports of people flying planes into office blocks. People changed behavior, not because there was a reason, but because it was highly visible.

There are many reports of drunk driving fatalities every day. (More die in road accidents per day than have died in terrorist attacks in the past decade.) Nobody changes their behavior because these deaths are NOT highly visible.

People don't give a shit about risk assessment (and aren't capable of it anyway), people only care about the emotional, visibl

When I say 'reports' I refer to the data on successful attacks, not necessarily 'news'. Despite your assertion, there are several sources of such data. And you'll have to provide a citation regarding how much fraud is taking place with no indication of how. According to some of the other posters here. moving to DNSSEC is not 'very low cost maintenance', so doing it when the apparent threat is very close to zero is in most cases going to be judged a waste of time.
Regardless, my intended point could be phra

Most of the vulnerabilities we live with are stupid and are only there because humans are incapable of assessing risk. (Those times I refer to myself as an elf, it is because I completely disavow any association with such monstrous stupidity and there are no existent homo sapien subspecies recognized that I could otherwise label myself as. As it is, I am debating whether to lobby the scientific establishment on nomenclature because there's bugger all evidence of any wisdom amongst the humans I've encountere

Well that's not true. Humans assess risk all the time. For example, I drove today even though I know there is a chance I could get in a fatal accident. Just because the assessment of others doesn't agree with your assessment doesn't mean they are stupid or wrong.

First, look up the research and don't base your arguments on Anecdotal Evidence (even your own). The peer-reviewed research says they are stupid and wrong, therefore they are stupid and wrong until there is sufficient evidence to reject that hypothesis. Given your use of Anecdotal Evidence, it is clear that such a rejection may take a while.

Second, I am old enough to be tired of the utter ignorance of the world around me. I've been deep into science for longer than most Slashdotters have been alive. Hell, I

And the Dans are both tools (Kaminsky and Bernstein). And to the guy who suggested hosts files with nasty scripts copying things to and fro, ummm... NO. Sounds like some of the horror stories I've heard of how things are cobbled together at a certain large Seattle-based internet retailer, and it's the kind of hair-brained idea a DevOps fan might dream up.

DNScurve, as pointed out above, doesn't do nearly as much as DNSSEC does. In particular, DNScurve still allows "NXDOMAIN recirection" but DNSSEC doesn't. In addition, Bind, NSD, Unbound, and PowerDNS (non-recursive) have DNSSEC support, but there is not a mainstream DNS server out there with DNScurve support.

djbdns hasn't been updated since 2001 and even the unofficial forks do not have patches for all three CVE security holes in DjbDNS [nist.gov]. Since DjbDNS' goal was security, I consider it a

The Kaminsky attack took advantage of what was essentially bad randomness in DNS resolver implementations.

DNSSEC solves the problem of DNS being plaintext (and consequently vulnerable to man-in-the-middle attacks) in the first place. If you want to call that a "vulnerability", it's one that's been around (and known) for as long as DNS; I guess ~30 years? Current internet culture requires more security so DNSSEC throws a layer of cryptography on top of tradit

I'm not sure you understand how DNS works - the reverse entries are delegated to the IP space owners, so it's just as likely that the in-addr.arpa records are being poisoned, and so your reverse lookup check doesn't buy you much. It's better than not checking, but a well organised poisoning attack will be modifying PTR records to cover SSL full-circle checks anyway.In fact, you're still trusting that DNS is sound to check your hosts files are coming from the right places, and then adding further vulnerabili

1) Symantec is the only one of those sources I would even remotely trust, and I'd still be checking every single entry, even with them.2) You _are_ relying on "ON A WORLD FULL OF UNPATCHED DNS SERVERS", unless you only ever visit the _exact_ hostnames _specifically_ entered in your hosts file, and _only_ if those site _only_ have links and included references (javascript sources, etc) which are _exactly_ listed in your hosts file.

Do me a favour - run wireshark on your PC, filter for port 53. See how often y

"...you even ADMIT I do get better security via my methods"Umm, I didn't. I said quite specifically that your security is likely worse than just using DNS. But hey. If that's how you choose to configure your hosts, then that's great. Good luck to you.

I'll be out here in the badlands running with an empty hosts file, javascript switched on, frames enabled, cookies allowed, and Flash installed. Living the dream, baby.

"ACTUAL STORAGE CENTRAL POINT FOR THEM"Again, there is _no_ central storage for in-addr.arpa. The reverse records are delegated just like the A records are. Do you honestly think the root servers hold every single PTR record on the public internet?

You know, for someone who makes a lot of noise about hosts files and DNS, I'd expect you to at least understand how DNS works.

I'm sorry but you fail to counter any points. Hosts file = inefficient and random subdomains CANNOT be countered by a hosts file.

As a spammer, I could setup a wildcard entry "* IN A " and just use simple PHP to set every image and every advert to use.domain.com. Hosts file cannot solve this. There is no argument here, this is FACT.

Your attempt to counter the localhost DNS server point by saying that the server itself would be compromised is a joke. You demonstrate complete misunderstanding of computer logi

Actual line #2:As a spammer, I could setup a wildcard entry "* IN A [ip]" and just use simple PHP to set every image and every advert to use [random].domain.com. Hosts file cannot solve this. There is no argument here, this is FACT.

Okay I see you have no citations for those points, just guesswork. I accept this as you conceding the argument in my favor. That is acceptable.

Any operating system tricks to cache data are not exclusive to just a hosts file so any points made there are moot and disregarded.

Besides, the SPEED difference of any of these system would be unmeasurable (unless you have citations? oh you don't don't nevermind that then), its not what I am arguing. An internal DNS system (not affected by any sort of poisoning vulne

Please don't turn this into an e-peen competition. My kids are into that sort of thing. I have been writing software for over 35 years, so lets just put that to rest, it's immature.

Indexing vs "favourites at top" has no argument. Indexing was designed to speed up search, linear searching is the base at which indexing is compared to. Sure, for those at the top, its faster, for those at the bottom its slower, you can't predict the browsing habits of your users, so this sorting won't work. Overall, indexing is

(It does so, every 500ms, & NO programs' or malware-in-general that's NOT a driver powered rootkit's going to get past that, since the timer registered with the OS is as 'fast as it gets' in usermode, period!)

Oh, you opened yourself up for being owned now:)

Any other process capable of writing to the hosts file is running as administrator. Therefore it kills your applications PID, and disables any service. The end.

Yes I understand it is the same. You are now desperate enough that instead of claiming APK is superior, that you are now happy enough to say that it has the same protection as other software. The very point I was making.

Also, you are now slipping up on some important parts..You just stated:

Plus, it can't be done - Not every 1/2 ms while my app runs... no way, no how!

Hahahahhaa APK, what a surprise - here you are, regurgitating the same tired old rubbish.

Get this through your thick skull, nobody wants to read your shite about the fucking hosts file any more.

We've seen you spew this crap over and over and over and over again, don't you think it's time to give it a rest? Face it APK, you're a fifty-year-old man-child with an obsessive pattern of behaviour and a compulsion to make an annoyance of yourself that you should have gotten under control by your age.

I won't grow up, [youtube.com] (I won't grow up)I don't want to go to school.(I don't want to go to school)Just to learn to be a parrot,(Just to learn to be a parrot)And recite a silly rule.(And recite a silly rule)If growing up meansIt would be beneath my dignity to climb a tree,I'll never grow up, never grow up, never grow upNot me!Not I,Not me!Not me!I won't grow up,(I won't grow up)I don't want to wear a tie.(I don't want to wear a tie)And a serious expression(And a serious expression)In the middle of July.(In the mi

Dude.. I've just read post upon post of agressive flaming here, mostly from you. Expressing yourself in such an insufferable know-it-all kind of way detracts hugely from any technical merit your software may have, which I'm not disputing because I haven't looked at it. I'm simply extremely distrustful of anyone who keeps repeating that they're unquestionably right on everything they say. Sounds too much like a priest I knew as a child.