Seven People Who Hold the Keys to Worldwide Internet Security(theguardian.com) |
Seven People Who Hold the Keys to Worldwide Internet Security(theguardian.com) |
I've written a bunch about DNSSEC on HN (and elsewhere) and won't preemptively repeat myself. You might consider just taking my word for this.
I recently had the occasion to attend a meeting of a body recommending standards for the Dutch government. (Serving) DNSSEC has been on their "use or explain"-list for well over a year (and the Netherlands apparently leads worldwide DNSSEC adoption.) At the meeting, the other attendees expressed their sincere regret that the DANE proposal, although a great idea, was still too immature.
As you probably know, DANE says that you "MUST" implement "trust this certificate, no matter what any CA says" over DNSSEC; combined with the fact that DNSSEC servers usually hold the signing keys online (NSEC3), implementing DANE is significantly less secure than just trusting the CA's. In fact, the Netherlands put quite a bit of effort into a government PKI infrastructure after our previous CA (DigiNotar) got pwned; it's not clear that requiring e.g. municipal system administrators to handle their own cryptographic keys is an improvement over what we have now.
Which is to say, don't discount well-meaning public servants; "given enough thrust, pigs can (temporarily) reach 6% of cruising altitude." </snark> [1,2]
[1] https://tools.ietf.org/html/rfc1925
[2] http://www.networkworld.com/news/2012/092412-ipv6-traffic-26...
Post-NSA-revelations, DNSSEC-based browser security is lunacy.
Reports like this just add to public misconception.
Someone spun some crazy PR for this one.
DNSSEC doesn't add security, nor does it prevent our business from operating to the fullest extent.
Namecoin is but one of many ways to decentralize DNS while even while having one centralized registry.
Peaked. And that probably includes the sysadmin who was required to watch it.
Where are the articles on the new ridiculous TLD's?
A while back the IP address for the FTP copy of the root.zone changed.
And sure enough, the file is now full of crap like .buzz, .house and .kitchen
I cannot even read through the whole zone anymore. It's too long.
There are some gems in there though. And some fool paid $185,000+ for each one.
I have been running my own root for years and this is why.
Snip, snip. No more .buzz
Very easy to set up up your own custom root and to filter out the crap TLD's. But, like with the ceremony in this article, some folks think that ICANN has some sort of "authority" on how people use domain names.
Whole .com zone (=public information) fits on a USB stick.
And the HOSTS file remains as a failsafe, if you have to use someone else's resolver.
And most of the entries in the com.zone are garbage anyway: parked names with ads.
Imagine how many different domains the average user will visit in their lifetime. It is but a small fraction of all the names registered.
But let's pretend ICANN is relevant.
God help us if ICANN should cease to exist.
2. Load it into tinydns or nsd. I have a sed script that translates BIND format into tinydns format, but if you search you will find someone has written one in C.
3. Point your resolver at your root.
4. Create or delete TLD's at will, not to mention many other benefits.
Running your own DNS gives lots of control. Most malicious or deceptive practices that tarnish the internet rely on DNS. When you control your own, you can neutralize a very large percentage of it.
Redirecting .apple.com to your own httpd will show you just how bad this company has gotten.
You can also redirect ad servers like .doubleclick.net and voila, you will have free apps with NO ADS.
Can someone explain how this step doesn't invalidate all of the hours of ceremony and procedure?
"Later Okubo will transmit the key on a secure channel to Verisign and this signed key will be made live across the internet."
If I'm mistaken about this, I hope the secure channel is very very very secure!
However, judging by other comments here, I'm not sure there really was any "importance" to "dilute". It's probably just a way for apparatchiks to justify all-expense-paid vacations twice a year.
Thus if you have IP A you will get fake certificate generated by government owned CA, if you have IP B you will get to the real site. If you are IP A you will get pwned by MITM attack malware the site will look genuine to the browser.
The mitigation for the attack you outlined is that such attacks will be detected, and the CA will get blacklisted. That may not actually work in the real world.
Also, this is how non-events try to gain "importance".
Care to expand on that?
That's why I've presented you with the experiment.
If you think you might care about such things, try it yourself and draw your own conclusions.
If you use iOS, you might need this, just to get on your own home LAN:
/test/library/success.html <HTML><HEAD><TITLE>Success</TITLE></HEAD></HTML>
On the other hand, DNSCrypt is utterly useless and worthless. Wow, my ISP can't see that I'm looking up "www.example.com", oh... but my ISP can see that I am connecting to x.x.x.x on port 443 and sending "www.example.com" in the SSL handshake because of SNI. So now, both my ISP and OpenDNS (double the third parties) can see that I'm connecting to www.example.com, even if I'm using HTTPS. How exactly is this supposed to help my privacy?
DNSSEC and DNSCrypt both attempt do completely different things. DNSSEC is much better at doing what it is trying to do (even though it's far from perfect) than DNSCrypt.