You are correct about IE 5.x not checking the CRL by default, but be
careful in using this.
I recently found a bug with Windows 95, 98, and NT where if you checked the
box in Internet Options to tell IE to verify the CRL, it would do so, but
if a CRL link was provided, all other certificate verification would be
bypassed - including the certificate CN/hostname comparison, making the man
in the middle attack very easy to pull off. Essentially, you would think
you are getting more security, but you are losing it instead.
This would only work for these OS/browser combinations, but that is a hefty
piece of the web surfer pie.
Win2K did not have this problem.
MS was notified, but I haven't checked for patches since then (I don't use
IE - or Window$, if I can help it).
Just thought you would want to know.
L
> 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]
> Automated List Manager [EMAIL PROTECTED]
--
Louis LeBlanc
Fully Funded Hobbyist, KeySlapper Extrordinaire :)
[EMAIL PROTECTED]
http://acadia.ne.mediaone.net
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
