How web servers prevent man-in-the-middle attacks

This uncertainty about the authenticity of a remote host is not a unique problem. Most of us have connected to a secure web server at one time or another. We look down at the bottom corner of the browser and we see a little padlock. It gives us a warm fuzzy feeling that we know we have connected to a secure web server. So, how do secure web servers solve this problem? A secure web server uses a certificate issued by a trusted third-party Certificate Authority (CA) such as VeriSign and the client is responsible for checking that certificate upon connecting. In Internet Explorer and other browsers, you can review a list of certificate authorities that are deemed to be trusted. When you initially connect to the web server, the browser checks the certificate it receives from the remote server to see that it has been signed by one of the known trusted authorities. It also checks to see if the certificate has been revoked or expired. If a certificate has been revoked or expired, a dialogue will pop up indicating there is a problem with the certificate. You can also get a pop-up dialog if the certificate doesn't match the host you are connecting to.

In general, Secure Shell servers don't have the same type of key infrastructure that web servers depend on. Most Secure Shell servers rely on host keys that are created automatically by the server after installation. And these host keys can't easily be verified the first time a client connects.