Ivars Suba responded to me:
1. This doesn't have any effect on non-SSL-protected sites (e.g.
AmEx,... see `Hall of Shame`). And of course assumes users will notice
the use of non-SSL-site...
Vooooowww.. I didn't know that AmEx is not ssl protected ;))
Before user credentials are passed to site, site certificate are sent to
client browser, then certificate are accepted/denied, ssl tunnel is
As is clearly stated in messages you referred to, we all know Amex's
site invoke SSL to encrypt the password. The problem is that a fake Amex
site would not; and the user has no way to distinguish. Essentially,
Amex site is secure against the (unlikely) eavesdropper, but not against
the (much more likely) spoofer or the stronger (but possible) MITM.
So, my claims in Hall of Shame remain. Or do you want to protect the
Amex process? This will be interesting.
Is this site ssl proteceted? Shame Hall isn't so "shamy" ;)
Keep CA whitelist in SSL termination Proxy, and deny all others
(including sef-signed site certs).
You could of course do this filtering without also terminating the
tunnel at your proxy. I agree that such filtering (without breaking the
tunnel) is an advisable thing to do.
80% of users don't know what is the certificate. Imho, much better is
trust this task to SSL termination proxy...
I agree most users don't know what's a CA doing and what's a PK cert.
But my intuition - and research - show that they can learn very quickly
if we use simple words instead of jargon. In TrustBar, we display the
name/logo of the site, followed by the words `identified by` and the
name/logo of the CA. Our (limited) testing shows users understand this
very well. And of course this does not prevent you from also blocking in
a proxy any CAs you don't trust. Let the user decide among these you
can't rule out.
Department of Computer Science
Bar Ilan University
New: see my Hall Of Shame of Unprotected Login pages:
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to [EMAIL PROTECTED]