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

SourceForge -- broken SSH key distribution

[Big Jojo]

How many people noticed that SourceForge still doesn't have a trustworthy key distribution scheme?

It's easy enough to do. They have HTTPS there, all they need to do is publish the keys for their SSH servers on some HTTPS web page. That way, they'll be authenticating SSH keys through their SSL certificate. End of that risk, go fix the next one.

What they do now is publish their keys on an un-authenticated newsgroup. One that you need to go out of your way to find. And yet, one that any untrustworthy ISP is quite able to mangle, giving them the groundwork for a MITM attack.

These recent articles about MITM haven't shown anything that's not been apparent for the past twenty years or so. Solutions have been deployed for most of that time. So there's really no excuse for SourceForge to have such "bad key hygiene" practices. Their recent upgrade was lousy in that respect. They even changed keys without telling anyone why. (Maybe they were broken into, and their user database used as a lever to break into Egghead!)

From the top free/open software project hosting service, I expect to see better leadership in security practice. Using SSH is a great start ... but it just isn't enough.

FUD

[aozilla]

dsniff 2.3 allows you to exploit several fundamental flaws in two extremely popular encryption protocols, SSL and SSH. SSL and SSH are used to protect a large amount of network traffic, from financial transactions with online banks and stock trading sites to network administrator access to secured hosts holding extremely sensitive data.

Umm, first of all, this is only possible *if* you can actively steal and replace every packet between the two (man-in-the-middle). Second, SSL is generally used with a key signed by a CA, so no breach there. 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. So the user would have to have done this exploit every single time that I have connected. Unlikely (though certainly possible, but my data isn't *that* important). Finally, it's perfectly possible to use ssh with different mechanisms to transfer the key. If I *really cared*, I could put the key on my https server (key signed by verisign), and download the key from there, install it into my ssh client, and bingo, secure connection.

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

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.

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.
--