Edward Diener wrote: > > 1) You need someone to confirm that having a client use a > > known-compromised > > private key to authenticate over SSL is no worse than the > > client using no > > key at all. It seems to me like you'd almost have to try to make this a > > problem, but who knows -- maybe it's never been thought about.
> Whether a client private key is used or no client key at all, there is > still the issue of figuring out the username/password. No, there isn't. If using a known-compromised client key compromises the SSL connection, then an attacker can get a username/password simply by reading it out of a compromised SSL connection. On another note, something still seems fundamentally wrong with your approach. Since every customer has a username/password, and you don't trust your customers, you still cannot allow someone to mess with an arbitrary data just because he has a valid username/password. Being able to find the guilty party after a compromise is certainly one part of security. But when you design a security system, it's more important to make compromise difficult. No sane person would argue, "I don't need locks on my doors because I have a camera pointing at it". DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
