March 6, 2007 at 4:30PM DNS spoofing explained in simple terms
What follows is an excerpt from an email I sent to somebody explaining DNS spoofing. It’s been edited to protect the innocent.
I wouldn’t have any worries if we had a cert on our end so we could negotiate a completely secure connection, but unfortunately that’s not the case.
As things stand, any connection we might make to your servers is not completely secure because we don’t have a cert on this side to prove that the server we’re connecting to is who and what it says it is.
Because of this, a DNS spoofing attack is a non-trivial but relatively easy way to subvert the protection provided by SSL. All the bad guys have to do is make our server think that their server is your server. Once they’ve done that, they can connect to you pretty much invisibly and shuffle stuff back and forward between the your server and ours. Now they’re monitoring the traffic between our two servers.
This particular exploit doesn’t depend on SSL itself having any weaknesses. Once the connection’s up and running, it’s rock solid. However, it’s a rock solid connection to the bad guys who are then relaying the information we sent them across a rock solid connection they made with your server.
That’s a man-in-the-middle attack and it next to no processing power to mount.
For a slightly contrived real-world example of how DNS spoofing works, consider a situation where you’re going to visit a friend who happens to have an evil twin (the person attempting the DNS spoofing exploit) neither they nor you know about. Your friend has moved to a new street and all you have is their postal address and you don’t know where their house is on the street (i.e., you have their hostname but you don’t have their IP address). Your friend’s evil twin has been stalking either you or you twin and knows you’re coming, so they renumber all the houses on the street during the night so you’ll go to the house they’re lying in wait within (this is similar to DNS spoofing).
Now you head off to visit your friend, but because the houses have the wrong numbers, you end up going to the house your friend’s evil twin is in rather than your friend’s house. Once you step in the door, you’ve no way of knowing that the person you’re with is actually a bad guy because as far as you know, you’re talking to your friend.
To get around this, some way to identify the other person is who they say they are and not impersonating the person you want to talk to. In SSL, this is what a cert is for. The digital signature isn’t enough as it only proves that the parts of the message included in it haven’t been tampered with. This, however, is no guarantee that the rest of the message has been left intact.
Nothing I’ve described here requires anything other than a server and a bit of ingenuity, and the kind of people who’d like to get their hands on this kind of information have both in spade.
Now those of you in the audience might think that one way around this would be to only allow connections from certain IP addresses, but you’d be wrong because the attacker could use IP spoofing. The only real way to securely talk to another server is for the client to have a cert so that it can prove it isn’t lying about who it is.