Getting A Perspective On Man In Middle Attacks

Researchers at Carnegie Mellon University have proposed a system whereby you can ensure that when you attach to a server that uses SSH or a self-signed digital certificate and you haven't verified the authenticity of the host identity beforehand, you aren't subject to a man in the middle attack.A man in the middle attack occurs when the attacker can direct the client/server traffic through their system with the goal of viewing or modifying the traffic. In the case of SSL or SSH man in the middle attacks, that includes decrypting and encrypting as well.

Dubbed "Perspectives," the system validates through a Web interface, Firefox 3 plug-in, or a custom OpenSSH client, that the key you received is the same key they received through one of their notaries, a notary being a system that requests, and maintains a history of, public keys on demand.

From the model is summed up the paper Perspectives: Improving SSH-style Host Authentication with Multi-Path Probing. "While our model allows any network or notary component to be compromised, we borrow from Abraham Lincoln and assume that an attacker 'can fool all of the [components] some of the time, and some of the [components] all of the time, but it cannot fool all of the [components] all of the time.' That is, we assume that attacks are either: (1) localized to a particular network scope or (2) of limited duration, since a larger attack is more easily detected and remedied."

Perspectives, Meet Context

The trust you can place in Perspectives needs some context. I don't think Perspectives is a replacement for the public key infrastructure in use today. Certainly there could be improvements in how certificate authorities verify certificate requesters prior to issuing signed certificates. But there have been no instances of widespread cases where CA have issued fraudulent certificates. I think a widespread fraud would be difficult to pull off and rapidly identified. Targeted fraud could occur against CA's that don't perform thorough validation.

About the only thing I like about Extended Validation certificates, which I am NOT a fan of, btw, is that issuers of EV certificates have agreed upon a method to verify certificate requesters as authentic and authorized for a given domain.

For all practical purposes, the way digital certificates signed by public certificate authorities are used in SSL works well.

However, when you go to an SSL-enabled Web site with a self-signed certificate or SSH server for the first time, what you want to know when presented with a certificate or key is whether it came from the server you intended to talk to or a mand in the middle. Without a trusted method to verify the key, you simply can't know. In the PKI, the CA is the trusted source of identification. As an outside entity that is using a different path to retrieve the same content -- in this case, a key -- the likelihood that an attacker could commit a man in the middle against both your computer and the Perspective Notary, is small. But that attack model assumes that the MITM attacks are close to the clients -- your computer and the Perspective Notary -- and distant from the server. What happens if the MITM is close enough to the server that both your computer and the Perspective Notary both pass through the same MITM? More important, if the target's DNS server has been compromised and directs traffic to the MITM, then the fraud may not be detected.

Perspectives does maintain a database of key histories, but if the SSL or SSH server is unknown to Perspectives, a man in the middle could subvert the veracity of the service. The chances of a SSL or SSH server going up and a MITM server going up just as quickly are small, but not impossible.

It's certainly an interesting approach to verifying keys based on multiple retrievals. If the service becomes populated, it might even become useful over time. However, I wouldn't recommend it for anything other than casual trust. If you are connecting to a shopping cart that doesn't have an SSL certificate from a well-known CA or are connecting to a service to share sensitive information for the first time and can't verify the key in an authoritative way, like validating the key thumbprint against a known good copy, you are simply jeopardizing any trust you want to claim.