On 10/8/11 1:16 AM, Michael Sierchio wrote:
On Fri, Oct 7, 2011 at 7:40 PM, Kristen J. Webb<kw...@teradactyl.com> wrote:
My understanding is that a TLS connection with a server cert
only identifies the server to the client. This leads to a MiTM
attack, where the mitm can impersonate the client because the server
has not verified the client.
Your understanding is flawed - while in the scenario you mention there
is no binding of a client identity to a public key, SSLv3/TLS are not
vulnerable to MITM - no third party can manipulate the stream without
being detected.
Yes, thank you. Upon further investigation I find that not using
client certs means that the server cannot prove the identity of the
client. So I think that the attack I am looking at is more of a
client impersonation, where a rouge client pretends to be the real
client. All it takes (I think) is for the rouge client to have
enough information about the server (e.g. our application installed)
and be able to present itself to the server as the client under attack.
Since the server cannot distinguish, then the rouge client could use
our application to manipulate the server. It seems that the only
way to help prevent this is to use client certificates to prove the
identity of the client. The problem I am having with this is that
managing certs for a few servers is easy, while managing it for
1000's of clients is not. I'm looking for the way around this
and still keep things secure, but maybe there is not?
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
--
Mr. Kristen J. Webb
Teradactyl LLC.
PHONE: 1-505-242-1091
EMAIL: kw...@teradactyl.com
VISIT: http://www.teradactyl.com
Home of the
True incremental Backup System
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
