Slashdot Mirror
Kaminsky On DNS Bugs a Year Later and DNSSEC
L3sPau1 writes "Network security researcher Dan Kaminsky has had a year to reflect on the impact of the cache poisoning vulnerability he discovered in the Domain Name System. In the time since, Kaminsky has become an advocate for improving security in DNS, and ultimately, trust on the Internet. One way to do this is with the widespread use of DNSSEC (DNS Security Extensions), which essentially brings PKI to website requests. In this interview, Kaminsky talks about how the implementation of DNSSEC would enable greater security and trust on the Net and provide a platform for the development of new security products and services."
Better than generating fear to reduce the rights of your citizens...
Don't blame me, I voted for Kodos
Sincerely,
Both Political Parties.
THL phish sticks
Kaminsky is incredibly enthusiastic about DNSSEC. ... to the point where someone not too knowledgeable (like I am) wonders if DNSSEC really is that amazing or if he was just high.
The Kaminisky bug is real, and its being used out in the wild. This is not a hypothetical academic exercise. DNS needs to be secured. Its not fear mongering, and its not for profit.
Many of these security consultants you speak of are not consultants at all, but experts working on this stuff in their free time for the betterment of the internet.
Do you even know what DNSSEC is? It is nothing he is trying to sell, it is him trying to completely take care of the flaw he found in DNS last summer. A flaw that could have seriously fubared the net if he didn't go through massive patching with internet providers and large companies. So you know, just about all DNSSEC software is opensource, meaning it is free. He isn't a conartist and it is pretty ignorant to call him one, he spent countless hours last summer trying to get the patch out which he didn't make money off of since he released it for free.
Just because you are wrong and I called you out on it doesn't mean I am a Troll.
.. hit yet.
Security is a tricky thing. You say security people sell you things "you don't need". But if you wait until you NEED security, it is already too late because you have a breach.
Security is not an ER visit, it is a regular preventative exam with your physician. It is something you have to take a pro-active approach with. Yes, this oten means investing time and money in something that has no immediate ROI. But that is the nature of the problem you are dealing with.
(This is Dan)
No, it really is about securing your assets, instead of trying to deploy yet another magic box that conveniently fails just as you try to get it out of testing.
This is not how the kraminisky bug works. You can intercept and redirect traffic with a properly formed DNS label to a legitimate site.
I haven't deployed DNSSEC yet on my external domains because of cost/complexity. When I looked into it, my options for DNSSEC were:
1) implement BIND and do the key management and rotation from the command line
2) spend $10,000 or so for an appliance from secure64 or nixu
3) spend $1k/month for a hosted DNS provider like neustar or verisign
4) install Win2008R2 RC and use it in producition
I work in a windows shop, so I'll probably go with option 4, but I'm surprised there aren't more set-it-and-forget-it tools out there for DNSSEC deployment. I'm open to recommendations.
OK, since Mr. Kaminsky is following this thread, I figured this would be a good place to open up some questions and a discussion between a DNS implementor and Mr. Kaminsky.
Let me introduce myself: My name is Sam Trenholme and I am the implementor of MaraDNS, a recursive and caching DNS server. Right now, I am in the slow process of re-writing the recursive DNS resolver. While MaraDNS has always been as secure as non-DNSSEC can be against Mr. Kaminsky's bug (DJB knew about the problem back in 1999 and I implemented his solution to randomize both the query ID and the source port back in 2001), I am wondering:
How hard is it to implement DNSSEC in my recursive cache? How many RFCs am I going to have to toil over to understand DNSSEC well enough to implement it? About how long will it take me to code MaraDNS to have full DNSSEC support?
I have a bad feeling that DNSSEC is a monster to implement and that we will not see many independent implementations of it; right now BIND and Unbound appear to be the only DNS servers to support it. DjbDNS doesn't support it, of course, and probably never will. My own MaraDNS and PowerDNS also don't support.
What are your thoughts? Has a reasonable effort been made to make DNSSEC easy to implement?
Wow an acronym explained was explained in a slashdot story posting... "DNSSEC (DNS Security Extensions)". Oh, the DNS part wasn't :)
Yeah, I know its a very common acronym.
The kaminsky attack is an attack on a client that is dumb enough to allow to make thousands of dns requests to subdomains of a domain. If the solution is changing to DNSSEC the clients will have to change to DNSSEC too, so we may as well prevent the attack by making the DNS clients smarter. For example a rule could be added that says that if there were more than 10 invalid responses for subdomains of the same domain then when a valid response arrives only to cache the IP for the subdomain requested and not for additional domain names included on the response.
> Do you think the existing system, of X.509 certificates, of SSL CA's, of private PKI's, is at all working? I sure don't.
;) ) even though the cert is valid the browser should give a warning. Wouldn't you want to know if your bank's cert's CA was suddenly changed from one CA to another CA even though the original cert still had 1+ year left to go? But as far as I know, none of the browsers do that.
;).
I don't, IMO they are just a way for Verisign and Friends to collect toll.
But I don't see how DNSSEC fixes that at all, it just makes it easy for Verisign et all to collect yet more toll.
If people were really interested in security they would have the https cert stuff behave a bit more like ssh does, e.g. if the browser notices the cert for myfavbank.com has changed, and now signed by a different CA (from Elbonia
In practice there really is little difference between a self signed cert and one signed by a CA. Like you said - crappy passwords everywhere, and CA's signing stuff blindly. Self signed certs are vulnerable on the "first time", or if/when the cert expires. CA signed certs as currently implemented are vulnerable to the "some idiot CA being tricked/hacked" attack.
Hardly anyone cares, they leave scores of CA certs (30+?) in their browsers, CAs that they don't know at all. And all the certs are left there because people don't want the browser to pop up warnings and "inconvenience" users. And that's the same reason why people pay the CA's money to sign their server certs. It's not about security at all.
Call me cynical, but I feel the same about DNSSEC. Just looking at the complexity and the way it works. It's for collecting toll ala CAs, and it's for making things more complicated so that people can make $$$ from consultancy and support.
But on the bright side I might return to that line one day
Hi Dan,
Stupid question: can whoever holds the root key forge requests from all domains?
e.g. if I am the US government, can I spoof an .ir domain?
Thanks.
I've got verizon and when I look up non-existent TLDs I get back a records of 8.15.7.117, 63.251.179.13, and 67.63.55.15.
Now, maybe that would be cool if I were using their DNS servers but I'm using dnscache running on localhost, so they're hijacking requests to root servers.
So, WTF, and will DNSSEC make any difference in this?
I was actually thinking about this the other day.
Http has absolutely no security at all built into the protocol. It is all hacked together with cookies and the server remembering sessions etc.
The protocol itself is dumb. Make a request... get a response, thats it. Any security is on top of that.
If there was a standard for secure HTTP, all of these gimmicks and schemes could be removed from the hundreds of web frameworks and implemented in the browser / http server.
Cache Poisoning has been around for years, using in the manner he did has not.
Just because you are wrong and I called you out on it doesn't mean I am a Troll.
That's kind of the point. Dan has found a flaw in the basement of your house.
The entire house is in jeopardy, no matter how well built. Every house affected.
Do you :
A: Call Kaminsky a damn liar, denounce his snake oil, sip your turpentine.
B: Stucco and paint every 10 days, whistling to yourself forcefully.
C: Try to jackhammer out the flaw and form up some new foundation meantime
D: Nuke the house from orbit, start from scratch, total web tech re-over in IPv6
I think Dan proposes C and eventually D. Most people stuck on A and B.
But hey, when the internet fails, just think of all the free time you'll have.
But since I don't claim to understand DNSSEC I'll ask it: how secure is DNSSEC against abuse by governments?
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
DNSSEC must be the most wildly overrated technology to ever come out of the internet.
Seriously, it's just terrible from a system administrator's perspective.
It's been a year since I listened to a speech about DNSSEC (from an official ISC representative) at a Linux User Group meeting, so I don't have every last detail on the tip of my brain. However, it provides a little more security in some ways, while making other things worse.
Among the highlights:
- You need to sign your DNS zones every thirty days or so, because the crypto in DNSSEC isn't really that good for speed optimization reasons
- If the signatures on your DNS zones expire, any validating DNSSEC resolver will pretend like your zone doesn't exist (since it was too late to use anything other than NXDOMAIN to indicate signing problems to keep backwards compatibility)
- You therefore need to set up a cron job on a second server to make sure that the DNS zones were signed properly. At the time this bug was published, there weren't any tools to do this in a sane manner, so you'd have to write your own scripts
- If you are an ISP, running a validating DNSSEC compatible resolver will likely end in more customer complaints, since it treats signed-but-expired DNS zones as NXDOMAIN, whereas a standard DNS setup would continue to work. Paul Vixie himself ran into this problem with one of his domains, forgetting to sign the zone in time and having it fall off the internet for anyone using a DNSSEC enabled resolver.
- As one of the new requirements of DNSSEC, it is now impossible to not publish a list of every single subdomain on your DNS zone. This is because every record in the zone has a pointer to the next record, kind of like a circular linked list. ISC maintains that this is no big deal, but there are plenty of people (myself included) that feel otherwise.
- The root and second level DNS providers are probably not going to support DNSSEC, or at least that was the feeling a year ago. As a result, ISC came up with something called DLV, or Domain Lookaside Validation (RFC 5074). This essentially sets up ISC as the official arbiter of which second level DNS zones (like google.com, microsoft.com, etc) are official and can sign their own zones.
ISC may not be selling anything, but they stand to gain significantly if they become the de facto authority on which internet domains are valid, and the presentation was more full of FUD than anything I had ever heard come out of Microsoft. Seriously.
I got the strong feeling that DNSSEC in general really feels half baked and rushed out, rather than something simple and well thought out. I would advise everyone to avoid it like the plague, and hold out for a better solution.
You don't host anything for real paying customers do you?
Let me give you a summary of how interaction with "security consultants" usually goes:
1. Customer gets cold called or sees some FUD on local TV, or portscans or the "consultant" has some dude in Malaysia digging around to find the sites hosted for pennies an hour.
2. Customer gets bilked out of a couple hundred dollars for a 'security audit' (a scan using a common tool with default settings usually)
3. Customer fails to understand any of it.
4. Passes a FUD report on to my desk, and proceeds to piss and moan or wring hands.
5. I have to stop what I am doing and examine the bogus report, then make a time consuming write up, explaining why having port 80 open is not a big deal and that it's typically not possible to be running both IIS and AIX (Unix) on the same box.
6. "security consultant" either tries to sell the user a open source program, Barracuda box (puke) or just laughs all the way to the bank, or even better yet starts bugging me about being honest with the customer (who is now unhappy about the fee charged).
This sequence repeats with every new BS bug, news story, or any time the economy is flush with IT money.
The "security consultant" is never really concerned about security, only money. Most of the time they don't know anything, sometimes they are outright brain-dead stupid and want to do things like put a notice "Please do not hack our web site" on every page because they think it won't be illegal to deface if the notice is not there. (Yes, that's really what they wanted.)
Replace the "security consultant" with the following types; "copyright protection scanning" and "defacement warning monitoring" (THAT is a bullshit scam) and "version back ups" and you have a whole world of suck. Thankfully the economy has been bad for a while so mom&pop shops are slamming the door on a two hundred dollar expense for an audit.
Maybe Kimansky himself won't be doing this, however a legion of other folks will be following shortly behind that will. The dream to update DNS is nice, but it's a stupidly impractical thing to be demanding everybody do right now. Aside from a few articles here and there, the "real world exploits" for this stuff, where someone actually gets harmed... well, where are THOSE reports?
Aside from a few articles here and there, the "real world exploits" for this stuff, where someone actually gets harmed... well, where are THOSE reports?
Since Dan Kaminsky is active in this thread, I'd love to see him answer this question. I'm guessing he's probably bound by non-disclosure agreements and can't give us any details, but I'd like to know if he's seen succesful, real-world attacks out "in the wild" that resulted in real damage done.
Thanks, Sam, I appreciate your taking the time to keep us annoying users informed!
The DNS cache poisoning attack was used the same week it was put into metasploit on a Verizon DNS in Texas where the attacker was forwarding people to a fake Google page with malware on it. Just one I can recall from when this first came out.
Just because you are wrong and I called you out on it doesn't mean I am a Troll.
Q: Why is starting a comment in the Subject: line incredibly annoying?
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
Yes, this oten means investing time and money in something that has no immediate ROI. But that is the nature of the problem you are dealing with.
Not only that, but if you invest and it actually works, you get the impression you wasted money, because nothing happens. :P
It's the same thing with Global Climate Change. If we actually fight it tooth and nail, the best we can hope for is no change from the present. Hardly a reward! ;)
I think my comments to the NTIA on DNSSEC hit the point on Kaminsky and the DNS scam. As others pointed out, this is a group of shysters. MIT's "Technology Review" picked up the "Media Hack" aspect of the Story in December. That article is a good read if someone has a link.
Here are my NTIA comments which detail the Kaminsky/Vixie scam aspects and expose problems with DNSSEC:
http://www.ntia.doc.gov/dns/comments/comment027.pdf
One of the things not detailed in my NTIA comments is that Kaminsky tells people to move to OpenDNS.ORG, run by Vixie associates David Ulevitch and Bill Fumerola. Fumerola is also a friend of Chris Neill. IADL has a page on Neill and his connection to spam-abuse at
http://www.iadl.org/cn/cn-story.html
On .ORG Signing
While the .ORG TLD was indeed recently signed, I could not get .ORG TLD officials to respond to questions about whether there was regulatory approval for their actions. It is also telling that Vixie is involved with .ORG TLD. The .ORG signing appears to be an effort at "persuasion"--Sort of 'See, we did it'. But as my NTIA comments spell out, there are two serious DDoS attacks created by DNSSEC. While one perhaps might block .ORG servers during an attack, one cannot block the root DNS servers.
(This is Dan)
I actually completely agree with your desire to see trust in the edges. That's what's so interesting about DNSSEC -- DNS, by its very design, is all about getting the core the hell out of the way and delegating, delegating, and delegating some more until the organization that manages the namespace can directly control it.
Indeed, in the ultimate vision of DNSSEC, we have full on validating resolvers in clients. The endpoints themselves can finally - finally! - recognize their peers directly, without having to trust anyone or depend on the admitted messiness of the existing SSL CA infrastructure.
The reality about Active MITM is that it's out there. See the BGP work that came out in tune with my talk -- note that all that still works, today, even with my big fix. Active MITM isn't some theoretical attack, and the reality is that everything is vulnerable to it. An ounce of cryptography is worthless without a metric asston of key management. DNSSEC is just the best way I can see to do it.
Regarding the trust anchor size, the reality is that we have 25 years of it not being a problem. That's the simple truth. Everything I did last year could have been done by a malicious root. It wasn't.
Your corporate/intranet myth is funny, because it strikes at the heart of the problem. You think there's just one corporate/intranet to authenticate. It's literally like you're suggesting, email to other companies is complicated, so lets just do email to our own company. Nice, but not good enough. We need cross organizational trust. We need something to bootstrap it. DNSSEC should be that.
(This is Dan)
Trust me, I'm raising more hell than you can imagine about the deployment issues of DNSSEC. Here's the truth:
1) You don't actually need to do all that resigning stuff. When best practices involve increasing your costs 100x, something is wrong. .org is signed. .com is coming, as is the root itself. Things have changed.
2) You don't actually need to have your signatures expire.
3) You don't actually need that cron job.
4) They fixed that zone walking problem with NSEC3. If you have online keysigning, which I expect everyone to have, you don't even need that.
5)
Standby. Seriously, this is coming, and it's not going to be miserable by the time you actually need to deploy it.
(This is Dan)
There's lots of shysters in every field. Doesn't change the fact that there are problems out there that need fixing. Security is in fact a problem.
In concrete terms, just for my vuln, about 1% of one of Brazil's largest bank's customers had their info taken by my bug. That wasn't fun. And China Netcom got hit pretty hard too, go Google that. Of course, there's a lot of data we're missing, because nobody needs to report. But anecdotally, this was a problem, but not the end of the world. Good! I didn't exactly set out to end the world :)
In terms of what I see fixing, I see a lot of technologies repeatedly sold as "and then you get certificates", and nobody does, because it's just such a cross organizational nightmare to manage. Certs aren't working, and it's holding back auth technology after auth technology. Verizon Business' data says that 60% of vulns aren't implementation flaws -- they're authentication flaws, with passwords at the heart of them.
Why so many passwords? Because they work. Well, DNS works too. Maybe we can use it to make all the better things scale across organizational boundaries.
The flaw is really in DNS - the only authentication field in a DNS request is a 16-bit query id, plus the implicit authentication of a 16-bit port number, and IIRC correctly you could also birthday-attack the query-id. Kaminsky's changes to DNS implementations such as BIND (which was build into djbdns etc. since the beginning) get you a few more bits of protection against an attack, but that just means that DNS is "still pretty weak" as opposed to "really really weak".
And unfortunately, IPv6 DNS is no better - it keeps the same basic header for compatibility, adds some new longer record types, and adds some 128-bit addressing, but the QueryID's still the same old 16 bits.
DNSSEC gets to the root of the problem, with cryptographic signatures on the data. It may be overkill compared to just putting in a 128-bit or 256-bit Query-ID field, but basically it's something that's possible actually get deployed, because it's a set of additional data transported in DNS, not a replacement for DNS's transport protocols. The reasons it wasn't done years ago have a lot to do with the NSA/FBI anti-crypto policies of the 90s, and Verisign's reluctance to do a huge amount of work nobody cares about to protect .com, but we're finally getting the root signed.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
DNS doesn't take up a lot of network bits - at the beginning of a data flow, you typically look up a DNS name to find the IP address, then start doing things, and even if all you're doing is a small text email or fetching a small text html page, the protocol headers alone are a lot bigger than the DNS query, and usually the data's a lot bigger. Changing to DNSSEC adds a few hundred bytes to that query, but it's almost always a drop in the bucket.
Of course, if you're a big name server, like one of the root or .com authoritative servers, or a big ISP's caching name server, that's different, since almost all your traffic is DNS. But that's not a lot of servers, though the overall load on them will obviously increase for a variety of reasons. On the other hand, if they get rid of DNS name kiting, a lot of the junk traffic will go down.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Some parts of the DNSSEC process invite clean UI connections - setting the keys, running human-oriented query tool, etc. It's far easier if you include registering the key as part of the process of registering the name, of course. But that's not how most people use DNS.
So you type a URL into your browser, and the browser hands it to a a resolver client, and the resolver client does a query. With Vanilla DNS, if the query fails, the client tells the browser it fails, and the browser either gives you some "can't find bad.example.com" message, or all too commonly hands your query off to a search engine which gives you a page of "Bad Examples For Sale!!" With DNSSEC, there's another possibility which your browser designer had not considered, and which your DNS client may or may not have considered, which is that it gets a DNS response back, but the response's signature is bad, or the response doesn't have a signature even though it should. What does the client tell the browser, and what does the browser tell the user? And does the user have a bloody clue what to do about it?
Another popular misbehaviour today is that the DNS server your resolver client talked to couldn't find the domain, so _it_ gave you the IP address of an HTTP server that responds to URL requests with queries for Bad Examples. This is an annoying behaviour if you're using a browser, but it's much more annoying if you weren't doing HTTP at all - you were trying to send email or telnet/ssh or connect to an IRC server or doing HTTPS on Port 443 or doing HTTP but on Port 8080, etc., and in most of those cases the DNS service's http server doesn't have those other services. Also, you might have been checking the IP address because you got mail from random-junk-dadfsadfdsaf.com, and your mail handler is trying to find out whether it exists (if not, it's guaranteed to be spam.) Will DNSSEC force ISPs to stop using that kind of DNS service/server? Or will you get even more incomprehensible responses, like a bad DNSSEC signature on the original query getting replaced by a valid signature on a DNS response from misbehaving-DNS-service.com's http server?
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Nothing's perfect, but the DNSSEC signature process is mostly out in the open - you can see the public keys for the name servers, and you can check the signatures on the keys for yourself, and you can also get yourself domain names almost anywhere in the world if you don't like a given registrar/registry. So while a government _could_ probably bully a registry into signing a forged certificate for your domain name, it would at least be publicly visible that "your" key had changed.
Also, the government foot-dragging that's delayed DNSSEC deployment and root/com signing for so many years has led to the development of "Trust Anchors", which are a mechanism for getting DNSSEC keys and validation independent of the upper DNS hierarchy, and they provide an extra mechanism for verifying keys.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
here! here!
The "Kaminsky bug" is a hoax. Kaminsky didn't discover anything. The only thing that Kaminsky can put his name on is the hoax. In my NTIA comments
http://www.ntia.doc.gov/dns/comments/comment027.pdf I traced down everything Kaminsky claimed to have discovered to find the true author.
There are no (or rare) "Kaminsky exploits" in the wild. All servers but BIND have implmented UDP port randomization for years. WITHOUT port randomization, one can exhaust the 16bit of Query ID in 65000 spoofed UDP packets--if one does this before the genuine packet is returned, the attack is successful. WITH port randomization, one needs to send 26 million UDP packets if 256 ports are used by the nameserver---much harder. And DNS TCP is invulnerable to blind attacks.
The Spring 2009 2600 Magazine has an article "Spoofing DNS on a LAN" but it is Man-in-the-middle attack, not the blind attack that Kaminsky describes. In the 2600 article, an an ARP message is used to intercept DNS packets. The DNS packets are altered with a new IP address to cause an http request to go to a proxy server for "inspection".
If DNSSEC were used in the same case as the article, the attacker just has to note the IP address given by DNSSEC, and send an ARP for *that* address which would cause its http proxy to intercept traffic to *that* address. Same result. DNSSEC is irrelevant to this attack. In fact, since the attacker can see the DNS request, it can just turn off the DNSSEC flag in the request so that a non-secure response is returned.
It is possible that the requesting resolver might be configured not to accept unsecure requests, but this is very tedious and impractical. Each resolver has be configured with keys and updated at just the right time or "DNSSEC suicide" results. Related to this is an attack on the caching nameserver that can result in Denial of Service to the client.
Worse yet, the DNSSEC responses are very large, and so a spoofed request have easily have a 126X amplification factor. If this response is coming from Root DNS servers, there is no way to block the attack. Blocking packets from the root servers effectively disables ALL DNS.
The "Kaminsky bug" is a blind attack using brute force to exhaust the 16bit of Query ID in 65000 forged packets. This was discovered in 1999 by Dr. Dan Bernstein, and is fixed by port randomization. BIND/Vixie stubbornly refused to implement this change and even harrassed and censored and blocked Bernstein's messages to IETF DNS lists. The next part of the Kaminsky hoax is to alter the Nameserver records provided as glue. But this was discovered in 2006.
Kaminsky/Vixie et al really are making money on DNSSEC and the Kaminsky/Vixie Hoax is just scaring people into adopting DNSSEC, which doesn't solve any problem, but lines their pockets. Other DNS experts like Masataka Ohta have noted that DNSSEC is not secure end to end.
(This is Dan)
To be fair, I don't see much of a difference between NXDOMAIN and SERVFAIL except possibly impact on negative caching. Stuff doesn't work.
DNSSEC planners have been way, way too willing to let things break in order to protect non-critical features. DNS is not allowed to just return SERVFAIL. Luckily, the protocol itself is flexible enough to allow much more stable deployments.
Absolutely true. However, the ability to delegate/federate security is such a powerful force for lowering the costs of proper design and management that making this one technical change will facilitate the operational strength you correctly call out.
Coming up on celebrity death match we have Dan Kaminsky vs. Dan J. Bernstein. Let's stay tuned. In all honesty I tend to agree with the notion that SSL is joke and hence DNS based on SSL is just as bad. SSL suffers from many flaws that most people are either don't know or choose to remain ignorant too based on the popular notion that SSL is safe. SSL relies on you trusting a third party as being secure when it only takes one corrupt employee to violate the sanctity of a PKI private key. Verisign, the globally trusted "omnipotent" master of SSL dropped the ball hard a year to 18 months ago when their subsidiary RapidSSL had their md5 private key broken, this coming from an SSL provider who was (and probably will remain to be) globally trusted by all browsers. This means the broken key can be used to generate SSL certificates for any domain you choose and knowing from my personal experience those certs were not revoked and fresh and updated installs of FF3 and IE8 still accept them. Not only can an employee be corrupted and an SSL provider who is trusted fall prey to cryptographic hash collision but a certificate provider can still be compromised and their are enough providers out there trusted by almost all common browsers that surely one of them must be vulnerable to being cracked and having the private key taken. Additionally DJB pointed out ( http://cr.yp.to/djbdns/bugtraq/19991114052453-12962-qmail@cr-yp-to ) that by using a spoof and having it redirect to a similarly named http host with a proper valid certificate, the average user and even some of the more advanced users can likely be conned into trusting a site based on valid SSL certificates when the site is run by a hacker so, credit to Dan Kaminsky where it's due, this was a brilliant discovery to say the least and I thought so when I read it a year ago but DNSSEC is as much fools gold as SSL always has been.