Which is the most vulnerable to MITM attacks, SSL or SSH?
Here's the scenario, you have 20 minutes to set up a web proxy like this:
Laptop -> Chrome Browser -> Web Proxy -> Internet
You must secure the connection between the Laptop and Web Proxy Server, nothing after the proxy matters, it's just the laptop to proxy connection we care about for now.
You can use SSL or you can tunnel the web traffic over SSH, all we care about is security, not performance. Which would you use, SSL or SSH and why?
With SSH, things are done like this:
ssh -N -D 5000 proxy-machine (where proxy-machine is the DNS name of the "Web Proxy" machine);localhost and port 5000.This is convenient, and activated in much less than 20 minutes. It has, however, the following consequences:
ssh command and keep it running as long as he wishes to browse the Internet through the proxy.ssh command must be installed on the laptop (it is standard issue with MacOS X, Linux and all the Unix-like systems, but not with Windows).With SSL, you would have to install some proxy software on the Web Proxy (e.g. squid) and configure it with an X.509 certificate, so that clients (the laptop) use https://proxy-machine:9000/ as proxy URL (the port number can be changed at will, I used 9000 as an example). There is no software to install on the laptop; the browser just has to be configured to use the right URL as an HTTP-level proxy. Be wary of proxy autoconfiguration scripts, they could be ways for the attacker to force another proxy configuration; you'd better configure the proxy manually.
SSL and SSH use distinct protections against Man-in-the-Middle attacks. The SSH client records the public key of the target machine (in the $HOME/.ssh/known_hosts file on Unix-like systems) so that it may check that the server public key is the right one; only the first connection ever is vulnerable. SSH public keys have fingerprints (i.e. hash values) which can be used to check that a key is correct (the idea being that you can phone the sysadmin, and he will spell out the fingerprint; this is tedious but needs to be done only once per SSH server). Until the laptop or the proxy is compromised, or the cryptographic algorithms get thoroughly demolished by irate cryptanalysts, the SSH way is secure.
SSL relies on X.509 certificates. The security comes from the set of trust anchors (aka "root certificates") already embedded in the browser (or the operating system). The certification authorities are supposed to issue certificates only to duly authenticated entities, and the digital signatures are the cryptographic tools by which the browser may verify that certificate contents have not been tampered with, and only accepted certification authorities have been involved. To mount a MitM, an attacker would have to bribe a CA into issuing a fake certificate, with the name proxy-machine, but with a public key owned by the attacker.
The X.509 security relies on a lot more assumptions than the SSH security, which is handled locally and where what happens is pretty simple. But the SSH scenario requires the laptop user to be a bit more aware of what is happening. For me, I would use SSH (indeed, that's what I do); for an organization with many users, I would follow the SSL path (but the "20 minutes" requirement would be a joke).
My two cents:
In order to prevent MITM, find a way to have the fingerprint available on your client host. With SSH it is easy to achieve since it stores the key and will refuse to connect to the server if it has changed, get it right once, and you're good.
Using this command will reduce the likeliness of a successful MITM:
ssh -o VisualHostKey=yes -2
One more point to use SSH, the main implementation comes from the openssh-server, distributed by the OpenSSH project. They designed and implemented it, they are known to audit their code and make each release more secure.
Now, SSL will provide less control than SSH, browser often implement fingerprint checking in a user-friendly way, and rely on a chain of trust to authenticate certificates/sites.
If you have the choice, SSH is less vulnerable to MITM:
The only reason to use SSL from my point of view is to provide an easy way for users to get asymmetric cryptography for their data stream and of course authentication. Usability will always sacrifice security at some point. SSH focuses less on usability and more on security. It's easy to understand that a shell access on a machine is more important than preventing eavesdropping for web traffic. For Techies, it should be easy to use SSH, but it requires you to get an access on a bouncing machine if you want to use it in a proxy scenario, whereas with SSL, their are already many free proxies, it's more convenient.
Personally I'd use SSH for the following reasons.
The mechanism for a MITM attack would be exactly the same for both protocols, as are the mitigation techniques. In both cases, you rely on checking for differences in the host key/certificate upon connect.
However, I would trust SSH more in this case, since SSL relies on the global SSL PKI (certificate authorities, etc.) while SSH simply expects the host key to never change. So while SSH is very vulnerable to MITM attacks for the very first connection, it will reliably detect any MITM attempt for any subsequent connection since the last-trusted host key will be tracked and a comparison done on each connection attempt thereafter.
And while it's unlikely that an attacker will have be able to get a valid SSL certificate for your host name and be able to use it against you, it isn't unheard of and does sometimes happen.
In addition to the previous answers. HTTPS usually isn't filtered, SSH on a non standard port is a lot more likely to be so, which makes the HTTPS solution usable in more cases.
Also, with browser extensions like Certificate Patrol you can be warned of server key changes like SSH and not be at the mercy of a corrupt or incompetent certificate authority.
