SSL Man-in-the-Middle Attack

I don't quite understand the Man-In-The-Middle Attack when using SSL, as describe here: http://developer.netscape.com/docs/...slin/index.html


If the rogue program intercepts the communication between the server and client and replaces the legtimate keys with its own, the digital signature of the certificate would show that the certificate have been tampered with, is it not?

If the client is connecting to a server for the first time, then it wouldn't have a previous record of the server's key to compare to the one it's receiving, hence it can't know from the certificate that it isn't communicating with the server it intended to.

The man-in-the-middle is doing the SSL negotiation with the legitimate server using its keys, and the victim is doing SSL negotiation with the man-in-the-middle using the man-in-the-middle's key (which it thinks is the legitimate server's key). As far as both parties are concerned, they are talking to legitimate clients/servers. Neither the legitimate server or the victim are any the wiser.

Assuming we are connecting to a Root CA Server, wouldn't my browser already store the public key of this server? Hence rendering a Man-In-The-Middle Attack futile.

You're not, because that's not the way SSL works. The SSL client doesn't contact the "Root CA Server" (I assume by this you mean a trusted authority such as VeriSign?) - the SSL client has a list of root CA's that it trusts, and it checks if the certificate has been signed by one of those. If so, then it proceeds. If not, then it may issue a warning, saying that the certificate wasn't signed by a root authority.

Hmm so for the client to check if the certificate is genuinely signed by say Verisign, it would have the public key of Verisign, right?

And if the man in the middle changes the key of the certificate, then the certificate would be invalid, because the message digest is different.

I am also confused by the article in URL when talking about the Man-In-The-Middle attack.
The client is supposed to get a certificate, vouchered by a trusted CA, from the server. So if the man-in-the-middle want to intercept, it then has two options (from my imagination):

- give the client a tampered certificate intercepted from the true server
But the client will find out that this certificate has been tampered with from the CA's digital signature.

- give the client a certificate with his Man-In-The-Middle public key
But the client will find out it has different Distinguished Name from the server if the certificate is vouchered by a trusted CA and then terminate the session
(Unless the client doesn't know the DN of the server. Is it why the article talk about checking domain name of the server and the one on the certificate?)

So how does the Man-in-the-middle attack still occur?
I'm just learning about InfoSec and is VERY NAIVE. So please forgive me to ask naive questions.

Think of a proxy server. The client initiates communication with the proxy, indicating it really wants to talk to server xyz, the proxy initiates communication with server xyz and then acts as a virtual circuit betwixt the twain for the duration of the communication. Since this is voluntary no one gives it much thought, but the exact same principle is involved in the man-in-the-middle attack. The 'evil-proxy' listens to the communication stream from the client looking for an attempt to contact server xyz (there are many ways to do this; networking protocols are, by themselves, very insecure). When it finds such an attempt, it hijacks the connection attempt (meaning it acts like server xyz as far as the client's network is concerned), then makes the connection to xyz itself. Since everyone has an acceptable certificate (ever research how easy it is to get one?), none of the signatures at any location show any false flags. Though the link talks about verifying the domain of the server, that is also not very difficult to spoof, so the upshot is you cannot guarentee that you are communicating with the target server unless you have an independant way of obtaining its certificate (in which case it is then trivial to detect). Further, particularlly in the case of HTTPS, client users are very likely to click on the 'OK' button when the client browser tells them that the domain does not match the certificate making the warning almost useless.

So the way to avoid this kind of attack is really to get a certificate from a trusted CA before you further communicate with a particular server? How do applications do it nowadays since it's not difficult to spoof someone else's domain name?

Not before further communication, before any communication. Applications mostly do it poorly now, but since there are so many other easier ways to hack, the bad guys are not spending a lot of time doing it. However, there are plenty of mainstream attacks that are in place and scripted, so even those with little to no programming experience can give them a try. If you are casually surfing the web, just keep in mind that the little security icon is not proof that you are secure.

...it is also worth noting that even if you don't have a little security icon, you can have secure communication too (via cgi/java apps, etc.).

There is no garenteed security software system, especially across the web. The best you can do is check to make sure there is a "reasonable" amount of security.

For instance when i buy things online i talk to others that have bought things from them before that i trust, I check to make sure the company has been around for a while, i do a dns lookup (and compare ip's) to make sure i am looking at the right site, then i look at their cert, then i make sure they are using a current version of apache and that my order goes over https, then i make sure I have to enter the security code on my CC.

Those are just some basic things that everyone can do to make sure that anyone can (and should) do to make sure that the company at least has a legitamite appearance.

The only secure computer is one that is turned off and that has no way to turn it on... and no physical connections, and that is buryed under a steel reinforced slab of concrete =P

So in response to: How do apps prevent MITM attack?

If you are running the app on your network, one model is to distribute keys/certificates through an alternate method then using the application (which will download the key/cert again).

So you can FTP 10 public 4096 bit key/certs to your 10 servers, during configuration before using the app. Another way is using USB keychains and phyically adding them.

Using bizitine generals as an analogy to the problem:
http://www.cs.cornell.edu/gupta/byzantine.htm
http://citeseer.ist.psu.edu/lamport82byzantine.html

The best solution for software (and possibly a revision of https) is to use a similair solution to bizitine generals in order form a circle of trust between computers. So in other words your client will contact a list of x random # of servers it has on a server list. Then it will validate that the response from all the servers are the same. This technique is called "Trianglation" of your results.