Silverman Responds To 'End of SSL And SSH'

guido_sst writes "Richard Silverman, co-author of O'Reilly's SSH, The Secure Shell: The Definitive Guide , has written a response to Kurt Seifried's article entitled 'The End of SSL and SSH?' at at Security Portal written after the release of dsniff 2.3. You can read the original article at SecurityPortal, the original Slashdot coverage on Slashdot, and Silverman's response at O'Reilly.." We had link to the story as well.

Comments

Implementation vs Essense

[Comp Bio Guy]

I think the core of Silverman's defense is that SSH et al is vulnerable to MITM by design, and not by necessity.

It becomes clear shortly that Seifried is talking about MITM. The existence of MITM is not a flaw in either protocol; in fact, both protocols include mechanisms to counter MITM. What is true is that, in most implementations, users may choose to override those mechanisms for the sake of convenience, forgoing MITM protection. One might take issue with this decision, but it is an implementation issue, not a protocol design flaw.

He then goes on to explain that it is necessary to allow connections without third-party verification at the present time due to a absence of a convenient, trustworthy, free, and universal authentication service. Nevertheless, the clients provide significant warnings to the user when something fishy might be going on.

In a nutshell, there are methods by which SSH can already support forms of 3rd party verification. It can be used in such a way so as not to be vulnerable to MITM. It is not implemented by default by design.

Re:FUD

[rknop]

...Third, at least my version of tera-term with ttssh, stores the key the first time you connect, and will warn you if that key ever changes in a future session....

You make good points. And, yes, for these reasons, SSH will continue to be much more secure than FTP or Telnet. However, as I understood the point of the stories pointing out the flaws in SSH, they work around these sorts of protections. It's not a technical break (the way that sniffing a telnet password is). It's a social engineering break. Sure, SSH clients warn you if a host key has changed. However, most users when faced with the warning question "Host ID has changed, connect anyway?" will just say "Yes" and go onward. Even if only a small fraction of users do this, it might be enough to make it worth it to crackers getting passwords. And, I predict that much more than a small fraction of users will do this without thinking.

Remember, users don't like *any* hassle at all. I have hard time convincing people to use SSH in the first place because they think ftp is so much more convenient, and because they don't have graphical sftp/scp clients on their Macs/PCs/whatever. This mentality is not a mentality that will proceed with caution when warned that a host ID has changed.

Additionally, if this is the first time you're connecting to a site with SSH, a man-in-the-middle can send you their spoofed host key, and you will never know the difference. Again, I don't expect this to happen very often, but a *lot* of people are connecting to sites all over the net.

So, yes, we shouldn't be alarmist, and it's stupid to say it's the end of SSH since SSH is still more secure and harder to break than telnet. But we should also be realistic about the flaws in SSH, and the fact that the breaks mentioned here are not breaks of the protocol per se, but social engineering breaks based on reasonable assumptions about the laziness of users.

-Rob

SRP is the answer!

[Paul Crowley]

AFAICT this article is wholly correct, point by point, and entirely the right response to the alarmism it counters. Plaudits to the author.

I said this last time, but it may be worth emphasising again: we do have other tools that can address this, tools that allow both client and server to authenticate each other without the user having to remember any more than their passphrase. These tools are called "strong password protocols". The best known is SRP, but others exist or are in development, including B-SPEKE and AMP, and while they are already efficient and seem damn secure work is proceeding to make them even faster and give us better guarantees of security.

Where one end can't carry around good strong information for authentication, like a user logging onto a previously untrusted computer knowing only a passphrase, strong password authentication is the appropriate solution.
--