Re: "The End of SSL and SSH?"

[Adam Shostack <adam () HOMEPORT ORG>]

On Tue, Dec 19, 2000 at 01:01:13PM -0500, Perry E. Metzger wrote:
| Kurt Seifried in an article on SecurityPortal shrilly entitled "The
| End of SSL and SSH?" claims that SSH needs a PKI to be secure.
|
| The claim is that because people have built man-in-the-middle attack
| software (see http://www.monkey.org/~dugsong/dsniff/) that can
| intercept SSH sessions, that SSH is insecure. After all, if a MITM
| attack happens, the user will be informed of this, and since the user
| can choose to ignore the warning that a host key has changed and log
| in, SSH must be fatally flawed. Without a PKI, Seifried claims, there
| is no way to know if a host key is authentic.
|
| This argument makes absolutely no sense to me.
|
| The problem is simply one of the user interface allowing a user to
| ignore a security failure. If a remote login utility using a PKI
| prompted the user with "host key is not certified, log in anyway?", it
| would be no better than SSH implementations. If A kerberized remote
| login utility prompted a user with "remote key is incorrect, log in
| anyway", it too would be no better.
|
| If this is truly the extent of the flaw Mr. Seifried things requires a
| full PKI to fix, I'd like to know why setting
|
| StrictHostKeyChecking yes
|
| isn't a near-complete fix to the "End of SSH" Mr. Seifried predicts.

While that may fix the problem presented, there is a problem that I
think a PKI could help address.  (I say this despite being quite
doubtful of most of the claims made for PKI.)

I believe that keys should be replaced from time to time.  This
replacement allows you to constrain the effect of key thefts that you
do not detect.  If you use SHKC, then you can not replace keys like
this.  Note that I'm not arguing for CRLs, but for short lived keys
that are replaced in an authenticated way from time to time.  What
that time to time is depends on the cost of authentication, cost of
use of the higher level keys, vulnerabilities and risks created by key
theft, etc.

If there were a way to sign all host keys within a domain, then you
could put the domain key in your ssh.domains file, and trust keys
signed by it.  With all the risks that that entails.  I think that the
balance is better than never rotating keys.

Adam


--
"It is seldom that liberty of any kind is lost all at once."
                                                       -Hume