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.

Re:PLEASE

[Christian]

Here here! I've never seen Kurt Seifried say anything new or interesting. He just re-hashes what has been known for years in the most sensationalist way that he can. From what I can tell its just to get more visitors to the SecurityPortal site (to sell more banner ads) and to gratify his ego. It would be different if he at least knew what he was talking about but the vague (yet ominous) way he explains concepts clearly exposes his lack of insight.

What protocol is the IETF draft talking about?

[Kenneth Stephen]

I went to the link referenced in the story about the SSH architecture, but couldnt figure out whether the document was talking about SSH v2 or SSH v1. Or maybe I am asking a stupid question?

It's the people, not the technology

[thorsen]

I'm surprised that noone has mentioned Slashdot's favourite security author, Bruce Schneier. He says the thing that IMHO closes this article: No matter how good a security technology is, it won't help you if the people don't behave in a secure manner.

This fits perfectly here. If people accepts using an unknown key, they're in for it. The problem is that it's a lot easier to do it than it is to get the key in a secure way.

Now Seidfrieds/Silvermans articles does have the simple point that the users need to worry about security themselves and don't expect technology to solve it for them. This can't be repeated too many times, since people still don't think computercrime will hit them in exactly the same way that people think no burglar will target their house and only buy security when it is too late.

So, try to read around the exagerated scoop style of seidfried, and heed the real advice here: Protect yourself, no technology will do it.

Follow up article on SSH/SSL

[seifried]

I wrote a follow up article that addresses many more problems in the implementations.

http://www.securityportal.com/seifried/sslssh-foll owup20001222.html [securityportal.com]

Re:FUD

[red_one]

May I suggest Putty [greenend.org.uk]?
FAQ [greenend.org.uk]

Re:unrealistic assumptions about user expertise

[Todd Knarr]

Then the situation needs to change, Tim. You can get away with it up to a certain point, but past that stupidity simply becomes fatal. This is one such point.

The problem you have, Tim, is that users don't need to know the algorithms and protocols involved to understand the concepts here, any more than they have to understand the internals of a lock to understand that if you don't lock it the buglars can get into your home.

Re:unrealistic assumptions about user expertise

[Todd Knarr]

I'd say it's more like requiring the user to understand that they need to lock the door when they leave and unlock it when they return. If they don't understand that, the door can't be secured period full stop. The SSH documentation was pretty clear on the point that you had to trust the host key and that ignoring the changed message or not verifying the original key was leaving yourself open to someone inpersonating the server, and it's unreasonable to require a security protocol to work when the user essentially ignores the warning to lock the door when leaving.

Re:FUD

[sporty]

Point being is that there are a lot of idiots out there who think that the key is transfered securely, and full proof. But someone on a hub (no.. won't work on a switch >P ) could sniff ssh traffic and get a key.

But you are right, how does a hacker get right in the middle? Its hard. Especially with so much traffic floating around.

---

Thanks to Richard E. Silverman

[charon.de]

Good read and he's IMHO right with every point!

More than once he gave me a short hint in comp.security.ssh, that helped me get things done.

You may knew how great this is, if you have a job like mine, sysadmin of a bunch of Linux servers, which get more and more every few weeks, cause your CTO likes that...:-(

Michael

the problem may be the OS

[bortbox]

> Again, implementations vary, but the message > issued in this circumstance by all three common > Unix SSH packages, is in fact quite a bit more > strenuous than this suggests: > @ WARNING: HOST IDENTIFICATION HAS CHANGED! @ So in Unix, the clients privledges to proceed if the sever host key has changed are souly determined by the sysadmin's policy with the SSH client program? So windows users are more likely to bypass such a message because a) their client SSH program doesn't present the message in a serious enough mannor b) because the user isn't educated enough to know how to set the attributes of a security scheme. A security scheme includes both the server and client systems. What this all boils down to is that SSH provides a safe scheme of encrypted communication when both ends of the scheme are under control of a smart admin. Unfortunately that bites into the realm of personal computing. How many people would download an SSH client that didn't allow them to proceed even if the server's key didn't look right? Given the option, even I would download a "slightly less secure" client program just to have the option. SSH just provides a secure platform in ideal controlled inviroments. That doesn't help me,my backbone is the psycic friends netowrk. bortbox

Re:What protocol is the IETF draft talking about?

[ibpooks]

With the latest version of dsniff you also gain the ability to intercept and monitor SSH (protocol version 1) and SSL connections using the vulnerabilities discussed above. Following is a list of dsniff utilities:

and later...

The simplest solution with SSH would be to stop supporting protocol version 1. Moving to protocol 2 shouldn't be too difficult, as OpenSSH supports it, and most free clients do as well (although not all). You can also use one-time password schemes. Doing so with a secure token would greatly minimize the risk involved, although session hijacking would still be possible, and it would probably be more difficult than switching over to SSH protocol 2.

He's talking about protocol version 1, which could possibly be "fixed" by moving to version 2.

SSH is very secure.

[buckrogers]

Because the way I run it I have to copy my public key to every box that I want to connect to.

Since the original authentication sent me the servers public key encrypted with my public key then it is impossible for the man in the middle to ever see any unencrypted data.

The original article is written very well, too bad it is just wrong.

Re:FUD

[drinkypoo]

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.

What's wrong with tunneling?

Re:It doesn't end

[Free Bird]

fuck you

It doesn't end

[Free Bird]

Despite what the man says, I think SSL and SSH are here to stay. Sure, they need their upgrades, but in the long run, they'll survive as reliable and secure protocols.

Re:FUD

[jbeam]

No, they're called telnet and ftp. And the security model is better integrated than these silly ad hoc solutions.

Bugtraq discussion

[cvore]

This subject has been discussed for some time now on bugtraq, the discussion can be found on bugtraqs archive [securityfocus.com] in "last week" and before

Re:FUD

[John Sullivan]

CA's issue certificates based on one criteria: money.

You give them money, they give you a certificate that says whatever you want it to say... If you want your certificate to say that you're "First Secure Bank Inc.", that's what your certificate will say...

While that is true and does have implications, the mapping you're interested in is not key<->person, but key<->DNS domain. The person<->DNS domain mapping you get from reading national press, TV etc. And CAs generally will try and check details out before issuing certs - the commodity they're selling is trust, and successful attacks against their issuing procedure would send their stock price plummetting.

Just because a cert is signed by a CA does not make it secure

Absolutely, and this applies to *any* system. You must always consider the total system, not individual protocols, if security is important. Personally I'd be more worried about hackers stealing the server's private key (the CA cert proves with a high degree of confidence that it's the legitimate owner's key - it *doesn't* prove that they're the only person with access to it) or viruses/trojans modifying the users CA root key list than CAs issuing bogus certs.

Re:unrealistic assumptions about user expertise

[tim_maroney]

Expecting someone to read documentation on how security protocols work before using Amazon does not reflect conditions in the real world. Manuals have been obsolete for the average end user for years now. No one reads documentation except engineers, and they usually only read it for projects they are working on.

I think it's strange that people can't see the basic difference in complexity and transparency between the algorithm of a public key authentication mechanism and turning a key in a lock. Again, there is a basic failure to grasp the difference between how engineers think and how ordinary people think.

Tim

Re:unrealistic assumptions about user expertise

[tim_maroney]

I don't mean any offense, but I think your message is a good example of failing to understand the difference between engineers and non-engineers. Do you really imagine that end users can or would read a protocol specification? A non-engineer outside the security community doesn't have the faintest idea what a host key is or how an authentication protocol works. Asking them to do so would be like asking them to understand how a lock works internally in order to use their front door.

Tim

unrealistic assumptions about user expertise

[tim_maroney]

This thoughtful piece is appreciated, but I feel it misses the mark. A common error of engineering specialists is to assume that their expertise is accessible to the average user. It is simply not realistic to frame the issue as "user and sysadmin awareness of their responsibility to maintain the SSH known-hosts lists, configure client behavior in accordance with a considered security policy, and think carefully before overriding security warnings about changed or missing host-keys." No non-engineer outside the security community would even be able to understand this issue; it's rather like expecting everyone with a locking front door to perform their own locksmithing. If that is what is required, then in the real world what we have is a radically insecure protocol that only provides security for a small cadre of specialists. In fact, by providing a veneer of protection, it creates a false sense of security which can easily be preyed upon.

Tim Maroney
[e-mail]

Just as vulnerable as always

[Proud Geek]

As long as you don't trust each other, there isn't much you can do about man in the middle attacks. That's why personal certificates are such an important thing. Otherwise, all you can do is know when it is possible to initiate a new one, and when it is possible to repeat one.

I'll admit, usually when I'm asked to accept a new key for a computer, I do. Usually it just means the key has been changed (duh!). But there is always the possibility it is an attack.

What I'm waiting for are smartcards that I can store a personal certificate on, as well as keys for all the computers I use on a regular basis.

Even if it does get replaced...

[AngryPC]

Even if this does get replaced, it won't be for a long time. Everyone is settled into SSL and SSH. There are a lot of browsers and servers to replace.

Re:Implementation vs Essense

[Sven Tuerpe]

Then the question is how to enable the users to take the right choice when configuring their software as well as when being confronted with indication of possible malicious activities. As known from ILOVEYOU and its successors, that is not as simple as showing a warning message and asking for confirmation. Training users won't help much, too; it does not take into account the fact that users decisions are led by their current goals (i.e., read this attachment now, or get connected to this host), and not by taught knowledge.

So how can it be made really hard to take the wrong choice in critical cases without reducing overall ease of use?

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

[[e-mail]]

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.

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 [slashdot.org], 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 [stanford.edu], 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.
--