On Mon, Feb 05, 2001 at 09:12:42AM -0500, Michael T. Babcock wrote:
> Greg Stark wrote:
> > The attack you are referring to is defeated by the client checking the
> > identity that is contained in the certificate. I do not know why you are so
> > sure that this checking is not normally done. IE and Netscape Nav. do it,
> > for example [...]
> IE 5.x does not, by default, check to see if the server or signer certificate
> is revoked. These must be turned on in the advanced options. This is a real
> problem because it means an attacker can break into a web site, steal their
> certificates and do what they wish to do without the certificate owner able to
> do anything about it because they can't revoke their certificates in a
> meaningful way.
That should be an exceptionally rare circumstance and, presuming
the secret key is passphrase protected (all of ours are), still requires
that the attacker steal the passphrase as well as the secret key. The
certificates are useless without those. The secret key should be tougher
to steal (root access on the box or maybe stored in a smart card where
it can be used but not read). The passphrase is normally only entered
when the server is started.
Alternatives... You could try to steal the key out of memory
(where it is no longer protected) but you have to find it first, or
you could trojan the box to sniff the passphrase and then force the
server to restart. An advanced cracker/intruder could do it... But
he's probably got better/easier things to do.
Gee... If you have reached that level of authority on the box,
why bother with a man in the middle attack at all? You have the end
point. Game over! Drop in a root kit, hide yourself real well, and
really do some REAL damage, no MITM required! You got that level of
authority, trojan the web server! That's a hell of a lot easier and
yields a much better return than attempting very iffy MITM attacks.
That could even defeat the cases where you can NOT obtain the secret
key (smart cards).
The threat you describe is not a realistic threat since once
an individual can achieve your base requirements (level of authority
capable of stealing certificates, secret keys, and passphrases) he
already has done far more damaged to you and is capable of continuing
to do far more damage to you on your own box than he could with those
purloined keys and certs.
Not that it should be totally dismissed, mind you. PKI is
intended to provide support for revocation lists and such and what
you describe is a limitation in the application implimentation, not
a limitation in the SSL protocol. The information (just like CN and
the start and end dates) is there (well, you have to access a CRL to
check for revocation). It's up to the end point application to check
it and what to do with it when it fails.
So... In the end, what you describe is not an SSL problem but
an application problem. Just like Kurt Seifert's paper describes MITM
attacks that depend on user stupidity (ignoring warnings about CN not
matching or expired or unknown CA).
The cryptography and the protocols are fine. It's what we do
with them as end users. As Bruce Schneier likes to say "If you believe
that cryptography can solve your problem, you don't understand your
problem and you don't understand cryptography."
> --
> Michael T. Babcock (PGP: 0xBE6C1895)
> http://www.fibrespeed.net/~mbabcock/
Mike
--
Michael H. Warfield | (770) 985-6132 | [EMAIL PROTECTED]
(The Mad Wizard) | (678) 463-0932 | http://www.wittsend.com/mhw/
NIC whois: MHW9 | An optimist believes we live in the best of all
PGP Key: 0xDF1DD471 | possible worlds. A pessimist is sure of it!
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
