On 10/27/2011 2:14 AM, Kristen J. Webb wrote:
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?
There are two possible solutions to this problem:
A. Once the client has verified the identity of the server and checked that
a strong enough encryption has been chosen (not something like the
old 40 bit stuff, but there are others that are no longer considered
safe),
it can use the encrypted channel to prove itself using any old method,
such as a plaintext "password" (randomly generated for each non-human
client). This is how many Internet sites use TLS with https.
B. With appropriate attributes, the same certificate could be used as both
server and client certificate. However you must be careful not to do
this
with a public key algorithm that is not secure in that scenario,
others on
this list can tell you which ones are safe and which ones not.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
