On 10/26/11 6:35 PM, Wim Lewis wrote:
On 7 Oct 2011, at 7:40 PM, Kristen J. Webb wrote:
I'm exploring the security of TLS for TCP/IP connections.
I would like to establish TLS connections using server certificates
(managing client certs via external or internal PKI is painful).
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.
My question is, if multiple servers are used, can this attack
(and possibly others) be avoided?
Example:
initiate_server: TLS connect with client
initiate_server: send encrypted data over TLS to client (including
target_server:port)
initiate server: TLS connect with target_server
initiate_server: send encrypted data over TLS to target_server (including
listen port, client, etc)
client: attempt TLS connection to target_server:port
target_server: accept TLS connection from client
client/target_server: verify additional encrypted data (from initiate_server)
to establish a connection
If I understand this, you're trying to use 'initiate_server' to introduce the
other two machines to each other, and relying on those two machines' server
certificates to allow initiate_server to verify that it's talking to the right
machine?
Not exactly, I was trying to develop a method where the transaction could occur
securely w/o a client certificate. I am beginning to believe that this is not
possible. The original idea I had is starting to look like a twisted/reverse
way that Kerberos does these things (I have implemented GSSAPI using host
principles, which takes the need of the client cert out of the process).
I see two problems with this. One is that initiate_server isn't authenticated
to the other machines--- evil_server could connect to target_server, give it
fake encrypted data and client info, and then impersonate the client.
I was assuming that the clients (and servers) would have the "longer term" trust
of the initiate_server via a PEM file that has it's identity.
The other problem is that this isn't really avoiding having a certificate on
the client machine. If you have a trustowrthy certificate on client, which
initiate_server can use to authenticate the connection, why not use that
certificate as a client certificate when client connects to target_server (and
eliminate the role of initiate_server entirely)?
Yeah, I wish I did not need to manage the client certificates. I am interested
in setting up a local CA for client certs. One of my stumbling blocks is
how to manage the install of a new client with libssl.so, but not openssl
installed (so openssl req not there).
Apologies if I don't understand your original motivation, but I don't see how
the introducer scheme helps you any.
If my understanding is up to speed you need to manage client certs to do this
right. Which brings me to my next set of questions about how to manage
this from install to revocation. Having an app that can use certs, it
appears, is nothing compared with how to deploy it and manage those certs ;)
______________________________________________________________________
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
