[Fwd: Re: "The End of SSL and SSH?"]
-------- Original Message -------- Subject: Re: "The End of SSL and SSH?" Date: Tue, 19 Dec 2000 13:47:56 -0500 From: "Perry E. Metzger" <perry@PIERMONT.COM> Reply-To: "Perry E. Metzger" <perry@PIERMONT.COM> To: BUGTRAQ@SECURITYFOCUS.COM References: <20001218101802.J26453@naughty.monkey.org><877l4w5lzq.fsf@snark.piermont.com><005901c069ea$3f73eec0$ca00030a@seifried.org> "Kurt Seifried" <seifried@securityportal.com> writes:
It is also incredibly difficult for users to ascertain whether the key is legit or not.
Generally, if a key is already in use, it is very likely legitimate. If a key comes up as having changed, it is probably not legitimate. This does leave the question of how do you get keys in the first place. In most organizations, however, systems administration is capable of maintaining such things reasonably well. We could perhaps make that problem a bit better with mechanisms such as on-line key lookup (using a sort of public key version of what kerberos provides for private key protocols), but PKI qua PKI won't improve the situation, and in practice you can (somewhat cumbersomely) get 90% of the benefits right now simply by being systematic about key management.
Most users will happily accept SSL certs that have expired, point to the wrong site or are self signed (all of which could be a man in the middle attack or a lazy admin).
And yet, SSL certs are based on the X.509 PKI architecture. You claim a PKI will fix things, but obviously it hasn't in this instance.
I used to religously sign email's with PGP until I realized that no-one probably checked, how did I know this? I started modifying the email after signing so that it wouldn't verify, no-one ever complained.
I'm hardly surprised. The tools to check are hard to use and the need is rarely obvious.
SSH and SSL are in my opinion poor implementations of security protocols, they also lack a lot of things such as repudiation/etc. To believe they are the best we can do makes me very sad. I suspect in 5 years we'll talk about ssh/ssl like we talk about telnet right now.
I doubt it. SSH and SSL are fine protocols, but are dependent on key management mechanisms. What you are noting is that key management is a hard problem. Well, so it is -- but that doesn't mean that if we change the way we do key management that SSH and SSL would go away. The protocols themselves are fine. In general, PKI is probably not the answer. Among other things, the fact that it requires revocation infrastructure in the first place gives one pause. CRLs do not work in practice. Perry
sunder wrote:
"Kurt Seifried" <seifried@securityportal.com> writes:
It is also incredibly difficult for users to ascertain whether the key is legit or not.
Generally, if a key is already in use, it is very likely legitimate. If a key comes up as having changed, it is probably not legitimate.
This does leave the question of how do you get keys in the first place. In most organizations, however, systems administration is capable of maintaining such things reasonably well. We could perhaps make that problem a bit better with mechanisms such as on-line key lookup (using a sort of public key version of what kerberos provides for private key protocols), but PKI qua PKI won't improve the situation, and in practice you can (somewhat cumbersomely) get 90% of the benefits right now simply by being systematic about key management.
what you SHOULD do (for ssh) is: generate keys on a stand-alone machine that's known to be secure. put them on floppy/cd/smartcard/whatever and distribute them around the servers by actually walking up to them (i.e. no network). set SSH to paranoid settings (e.g. automatically rejecting unknown keys, etc.). done. it's a bunch of work, but you only have to do it once. of course, intruders, malicious insiders, etc can still exchange the keys. but that's not an encryption problem and is true for every other piece of software on those machines (if you had an intruder, you've gotta toast and setup up anew the machine anyways).
Most users will happily accept SSL certs that have expired, point to the wrong site or are self signed (all of which could be a man in the middle attack or a lazy admin).
And yet, SSL certs are based on the X.509 PKI architecture. You claim a PKI will fix things, but obviously it hasn't in this instance.
and obviously, there's simply no software or infrastructure fix for user stupidity. even if you take the choice out of the user's hands, someone will simply write a software that enables it again and land a bestseller (or best-downloader).
I used to religously sign email's with PGP until I realized that no-one probably checked, how did I know this? I started modifying the email after signing so that it wouldn't verify, no-one ever complained.
I'm hardly surprised. The tools to check are hard to use and the need is rarely obvious.
I disagree. many e-mail clients automatically verify, provided that the key is on the keyring. it's just another key-management problem.
participants (2)
-
sunder -
Tom Vogt