An Illustrated Guide to the Kaminsky DNS Vulnerability

Ya.. Plus I'd trust the government less then I would to some anonymous stranger. Much less
likely to get screwed over.

----------------------------------


We all knew that DNS was not secure. Hell even IP addresses, which the DNS is just pointing
at, is not a trustworthy and can be spoofed. 

If we know the IP Addresses can be faked, then how the hell are we suppose to depend on DNS?!
It was exploded as a myth years ago that IP Address-based security was dependable in any way.

The answer is:

_We_Don't_. That's all. It's not dependable, it's a convenience. That's all it ever was,
that's all it was ever meant to be. It never was secure in the past, it never will be secure
in the future. 

That's _it_. As long as we all acknowledge this and realize the implications then we can move
on. 

This is why we have SSL/TLS. This is why we have cryptographically secure ways to identify SSH
servers and VPN servers and so on and so forth.  If DNS was ever considered secure then why do
I care what sort of hash my openssh returns when I try to connect to it?

This is why we have GPG signatures in email. This is why there are protocols for the secure
transfer of program packages.

That's why none of this stuff depends on DNS, none of this stuff depends on IP addresses.
People figured this out decades ago. 


etc etc etc.

-----------------------------


Now you may say "Well how do people know which sites are trustworthy?"

Well they _don't_. Saying things like "Only download software from trustworthy websites" is
bullshit advice. It's the blind-leading-the-blind style advice. 

It ranks up their in the top "bad and misleading security advice of all time" along the likes
of 'Only click on attachments from people you trust' or the classic lie, 'The anti-virus found
some stuff, but it cleaned it up so you should be ok now' or the huge blunder 'Hey, Lets stick
the gpg keyring on the same server as the deb package.. that way we know the package is
secure!!!'

You can't trust websites. I can't trust websites. I can't trust the content on them isn't
going to infect my computer if my browser has a flaw. I never could of, I never will. That's
why I update my browser every time I think about it, which is allot. 

Unless I am talking to a SSL website and am able verify their certificates I can't trust that
the person I thought made the site actually made the site. And even with strong and correct
certs that means I can't trust it any more then I can trust the certificate authority. (which
is to say, a little bit, enough to only make me slightly nervous)

And if 'Grandma' can't figure all that stuff out then they can't trust any website.

If you want to keep people safe then develop a way for a light on the top of a monitor to
flash the bright words 'NO this place is Bad' every time a user visits a website or gets email
and then flash the bright words 'Only Slightly Bad' when they get pgp-signed emails and visit
https sites that have correct certs.

No single technique is good enough. I think my bank is reasonable. The authenthication works
like this:

There's a client-side certificate, that you need to install the first time you visit the bank,
due to how web-browsers work, this certificate is only presented to the proper bank. (unless
there's a bug in your browser offcourse, but that's a different problem from phishing)

When you go to the bank, the browser presents the certificate, and the bank greets you, by
name, and with the time of your last visit. A MITM-attack could not replicate this. My browser
would not present the certificate in the first place, since the domain is wrong, and even if
it did, the certificate-authenthication-mechnism is secure against MITM-attacks anyway.

You enter your password. The usual problems of poorly selected passwords etc apply. But here's
the trick; when you do a SMS is sent to your mobile phone with a 5-char random hex-string that
you need to enter.

End-result is reasonably secure, and only a tiny bit more cumbersome than the basic
username-password thing.

To impersonate ME to the bank, an attacker would have to find out my username and password,
get hold of my client-certificate AND get access to read SMS-messages sent to my phone (for
example by stealing the phone). Each one of these ain't impossible (a trojan on my machine
could even do the first two). But getting all three -- preferably without me even noticing, is
going to be hard.

To impersonate the bank to ME, the attacker would have to hope I don't notice that I'm not
greeted by name, like I normally am, in prominent letters on the login-screen. And even if
this succeeded, and he got my password, he'd still need my mobile-phone AND my
client-certificate to be able to make any progress.

Not perfect. But good enough, methinks.

if both parties have certificates you are secure against MITM attacks

http://en.wikipedia.org/wiki/Man-in-the-middle_attack#Def...

thats why you want the government to issue these, so that everybody has 
one.

in denmark they actually did it. but all the complex infrastructure was 
used for was as a openid alternative. the cryptography of the system is 
never really used, as it is too complex. the next version is not going to 
use certificates anymore....

As far as I know a RSA smart card based encrypted public key communication should be
man-in-the-middle proof. If the bank followed protocol the public keys are verified through
another channel (telephone/mail).

This is anything but "security theater".

SRP protocol [1] allows to prevent man-in-the-middle attack using just a password. Moreover,
the password is never leaked. Even if the attacker manages to gain full control of, say,
bank's computer, he still would not be able to guess the password.

When combined with a pin-code and a smart-card, it allows to have a system which not only
verify the identity of the other side without reveling neither pin-code not card's key, but
also makes the card completely useless without the pin and the pin without the card.

[1] - http://srp.stanford.edu/

I just realized why I am so mad about this issue, when, as another 
commenter has pointed out, there are clear solutions to all these problems 
which do not involve daft brain dead ideas like embedding CA lists in 
browsers which is so obviously a bad idea that how it happened must be a 
vital consideration: what happens is:

Security consultant says this way is secure (independent academic peer 
review) ...

Marketing/business/management say:

1.Joe Sixpack will never understand it
2.Its too costly
3.Its too complicated
4.Its not what the rest of our industry is doing

And a chorus of vested interests, tool merchants, snakeoil salesmen and 
Micro$oft join in and a new, not quite secure system is rolled out to be a 
couple of weeks to shouts of surprise and outrage from 
Marketing/business/management and the public (a) see another security 
foobar and (b) loose further confidence and with good reason.

Much as Sarbanes Oxley is oppressive, until individuals in management are 
made civilly and criminally liable for these mistakes the same bad 
arguments will continue to prevail.

If the DNS is failed, or flakey you can always use the IP address
if you know it, so a poisoned, or group of poisoned DNS servers is, in 
fact, a denial of service, far less serious than a break in or  ability to 
mount a MIM attack.

That is why it is important that clients, as well as servers have 
certificates but even certificate-less clients can take measures to
prevent MIM attacks, since, simply you can refuse to talk to her! by
checking the IP or the certificate but this is still iffy and 
inconvenient, much better to just get into the way of partner trust chains 
and challenge response.

Once this is the norm, even Joe Sixpack will learn it!