SSH? [LWN.net]

SSH?

Posted Jun 19, 2011 2:48 UTC (Sun) by djao (guest, #4263)
In reply to: It's only partially true by khim
Parent article: WebOS: the other Linux-based mobile platform

It's instructive to compare SSL to SSH before you go off overblowing the importance of certificates.

SSH doesn't use certificates at all, self-signed or otherwise. In SSH, almost every real-world user (more or less) automatically responds "yes, trust this public key" whenever connecting to a server for the first time. The procedure is equivalent in both user experience and security to your proverbial one-click acceptance of self-signed certificates.

Are you therefore claiming that the net effect of SSH on security is strictly negative? If so, that's a very surprising, almost ludicrous, assertion. I can imagine someone making some sort of argument that SSH does not provide as much security as a hypothetical optimal variant that used certificates, but to claim that SSH is even worse than telnet is a stance that has no credibility.

Moreover, there is ample objective evidence that SSH in fact achieves better real-world security than SSL. When was the last time you heard of a man-in-the-middle attack against SSH? Have there been any reports of successful SSH key forgeries? Which of SSH or SSL has the greater market share? (Hint: you can't argue that SSH is a less attractive target on the basis of its market share.) Which of the two userbases (SSH or SSL) would you say has better-trained users? (Is this a pre-existing effect, or is it possible, just maybe, that ease-of-use has a positive effect on user training?)

You might want to think carefully about how SSH managed to reach 99% market share without using any certificates or PKI authentication. The easy option is not always insecure. Sometimes it's exactly what's needed.

to post comments

SSH?

Posted Jun 20, 2011 22:13 UTC (Mon) by elanthis (guest, #6227) [Link] (4 responses)

SHH is hacked all the time. It's trivial to do so because the lack of a central key authority puts the onus of verifying the remote host's authenticity on the user, almost every single one of which just says "yes add this host key" without even thinking of checking the key's fingerprint.

That you don't _hear_ about these is irrelevant. SSH is far less prevalent amongst the masses and hence is far less newsworthy. There are papers and CVEs publisheds on it all the time nonetheless.

SSH?

Posted Jun 21, 2011 0:23 UTC (Tue) by djao (guest, #4263) [Link] (3 responses)

That you don't _hear_ about these is irrelevant. SSH is far less prevalent amongst the masses and hence is far less newsworthy. There are papers and CVEs publisheds on it all the time nonetheless.

1. Could you cite any such papers or CVEs?

2. If you consider the big picture (total number or proportion of security incidents against browsers as opposed to login shells), I'm sure the number and proportion of unreported browser attacks far exceeds the number of unreported attacks against login programs. Many of these browser attacks (phishing etc.) have nothing to do with SSL, but that's my point: A security protocol, such as SSL, which fails to achieve widespread mandatory use, is by definition incapable of preventing most attacks.

The best security protocol in the world is of no use whatsoever if an attacker can simply trick unsuspecting users into not using it. This happens all the time with SSL. Failure to achieve market share is in and of itself disastrous for security, and I believe this shortcoming of SSL outweighs all its other achievements.

SSH?

Posted Jun 21, 2011 0:46 UTC (Tue) by dlang (guest, #313) [Link] (2 responses)

there are definantly CVEs with SSH itself, and there are papers that show problems with how SSH is used. There have been a number of well publicised cases where someone's laptop/desktop was compromised and their SSH keys were then used to go login to other systems and continue the attack from there.

but that's not the same as a man-in-the-middle attack, which is the particular issue that was being discussed here.

SSH?

Posted Jun 21, 2011 1:48 UTC (Tue) by djao (guest, #4263) [Link] (1 responses)

You keep mentioning the type of attacks where "someone's laptop/desktop was compromised and their SSH keys were then used to go login to other systems." This is not a fair comparison. The reason SSH keys are attacked in this way is because SSH keys are actually used. Believe it or not, SSL also supports client-side keys for authentication. The reason why you never hear about this feature getting attacked in SSL is because, I believe, the number of people in the world who use this feature in SSL is approximately zero. If they were actually used, then the same attack would also work against SSL.

My whole point all along is that SSL's failure to achieve marketplace acceptance is the one thing that above all else renders SSL useless as a security protocol. It hardly seems fair to attack SSH on this basis. A security protocol or protocol feature, such as SSL client-side keys, which nobody uses is certainly invulnerable to attack, but it also does not contribute to security in the slightest.

SSH?

Posted Jun 21, 2011 3:26 UTC (Tue) by dlang (guest, #313) [Link]

you are misunderstanding me.

I am not attacking ssh because of the cases where the client certs have been compromised, I am mentioning them and saying that such attacks do not count as SSH vulnerabilities (they count as bad deployment decisions on how to use SSH, relying solely on the possession of the client side cert, not requiring anything else)

another poster claimed that SSL without CA validation is meaningless, someone else pointed out that that basically matched what SSH does, and that SSH is therefor vulnerable to the same types of attacks as SSL without CA validation. So the question I am raising is, given that there is far more extensive use of SSH, can anyone show attacks against this supposed severe mitm vulnerability?

programming bugs in SSH don't count (which is what most CVE things are)

attacks that involve compromising the client key don't count as they aren't mitm attacks.