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

Getting fooled the first time

[iabervon]

For some reason, Silverman doesn't respond to the idea that, when connecting to a server for the first time, you cannot detect a man-in-the-middle attack.

This boils down to the identity problem: there doesn't have to be an actual server involved at all; you may be actually trying to log into the wrong machine, whether by mischief or by accident, and you'd be none the wiser because you don't know the difference between the different servers. You need to have some way of distinguishing the totally unfamiliar, but correct, server from the totally unfamiliar, but wrong, one.

Now there is a problem with most SSH clients: you might actually know the server you want from experience, but be using a computer which does not have access to this knowledge. You are expecting the client not to recognize the server, but you have more information than the client. In these cases, it would be helpful if the client would get the user involved in the authentication process. OpenSSH actually does this, by putting up for approval the server's key fingerprint, which a user can tell has changed even if the client has no information.

Re:unrealistic assumptions about user expertise

[Todd Knarr]

They don't have to read the protocol spec. They need to read either a) the documentation like I did, or b) a tutorial on basic security practices. One doesn't need to learn how to be a locksmith or know the technical details of the insides of a lock to know that you need to turn the key in the lock to lock it, after all.

PLEASE

[jmd!]

PLEASE...

Stop posting or linking to ANYTHING about Kurt Seifried, or any responce to anything about Kurt Seifried. If you want a responce to any of his articles, here you go: "bullshit". He doesn't have a clue what he's talking about. He's some script kiddie who decided to start writing National Enquirer-style about cracking (which he calls hacking). I recently subscribed to SysAdmin magazine, and guess who's doing the security articles? Guess who won't be renewing their subscription. Any magazine that could publish this crud is obviously not conserned with factual information.

Re:FUD

[john@iastate.edu]

for these reasons, SSH will continue to be much more secure than FTP or Telnet

I get tired of saying this, but there are secure versions of Telnet and FTP...

SSH and SSL not compromised.

[autocracy]

For a little background, DSniff could only compromise SSH and SSL by means of spoofing. In other words, they'd have to use a different key and make you believe it's the right one. This problem can be solved by the user checking the key's fingerprint each time. Voila, no more compromise!

All the attacks that are used for SSH and SSL can be applied to PGP as well, so if you want more specifics on how these attacks work, go grab the documentation for PGP 2.6.2. It's all outlined there.

Note: SSL isn't compromised, but it could still use a stronger key for most applications...

It's all about the Karma Points...
Moderators: Read from the bottom up!

Re:FUD

[srichman]

I believe the article addressed every one of your points.

Umm, first of all, this is only possible *if* you can actively steal and replace every packet between the two (man-in-the-middle).

According to the article, dsniff includes a pretty complete suite of tools with functionality to help you accomplish this, including redirecting targets from the link level (ARP spoofing) on up to DNS.

Second, SSL is generally used with a key signed by a CA, so no breach there.

As the article pointed out, although servers usually have CA-signed public keys, the clients accessing them usually do not. If user A is connecting to host H, user A generates a public and private key for itself and sends is public key to H. If an attacker B intercepts this and instead sends B's public key to H, then H will encrypt everything it sends to A with B's public key. B can then decrypt H's messages, read them, encrypt them with A's public key, and pass them on to A. Neither endpoint is any the wiser, but the attacker can now read half of A and H's conversation (the messages from H to A).

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.

Well, this obviously still only addresses the server key side. Additionally, this is of little use if I use a client from a different location that doesn't have the public key database. E.g., if I regularly connect to a computer in my school's CS department from home with SSH, all is well. But if one day I'm at a public terminal in my school's library and I want to connect to the same machine in the CS department, the public key database on my computer at home does me little good. You really need a trusted CA.

Further, as the article points out, there is a social engineering aspect. Many users (myself included) don't care that much and hit "ignore" when they get "public key changed" warnings. In my case, this is because I'm connecting to a computer lab of homogeneous machines that isn't very well managed from a PKI standpoint: hosts are renamed to other hosts when the computers fail or the configuration changes (not to mention the round-robin DNS alias that references any one of 40 boxen). "Ignore" is always the easiest option; to borrow a phrase, "my data isn't *that* important."

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.

I assume you mean you're retrieving your own personal (client) keys, as retrieving the server's public key doesn't solve any new problems (why trust your CA-verified web server to give you some other server's key when having the server's key CA-signed in the first place would have sufficed?). As I mentioned above, in an SSL conversation in which the client keys are generated for the session, the client key can be spoofed by a man in the middle. This means when you go to retrieve your personal public and private keys from your web server, I could intercept your personal private key. Hell, I could intercept your key and pass a different private key onto you if I wanted. Once I get your private key, I'm set; I can sniff every message sent to you in every "secure" session you enter until you changed your keys, and without having to go through the hassle of the whole man-in-the-middle attack.

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