Re: [reSIProcate] Security class and client-side authentication (longish)
- From: Bob Bramwell <bob@xxxxxxxxxx>
- Date: Mon, 25 Oct 2004 13:54:26 -0600
Random responses to random thoughts inline:
Cullen Jennings wrote:
Random thoughts inline
I think we should consider a design meeting to sort some of this out.
Sounds good. How should we go about this?
A TLS server certainly can act act as a client and is a superset of that.
The S/MIME certs are different from the TLS certs
The Identity header uses the TLS cert but performs S/MIME like functions
The system needs to support CA certs and self signed certs
The system needs to allow a user to install new root certs
See next inline comment...
Some servers support a bunch of domains and need to be able to deal with
multiple TLS certs (one for each domain)
Right. This was part of the intent behind some changes I made to the various
addTlsTransport functions a couple of months back. One can now pass in a
pre-configured Security object that has all the "right" certificates loaded.
Clients needs to be able to store fingerprints of non CA signed servers
certs they are willing to trust
Agreed, but this may be outside the purview of reSIProcate. I'd hate to see a
lot of x509 and TLS clutter in the midst of all the other stuff.
On 10/22/04 5:51 PM, "Bob Bramwell" <bob@xxxxxxxxxx> wrote:
This note is part reality check and part change proposal. Your constructive
feedback will be most welcome.
I am trying to set things up to allow TLS connections to do client
authentication. There are a number of things, notably in the Security class,
that will need to change to accomodate this.
At present a Security object has two public certificates associated with it:
its
publicCert and its publicIdentityCert. The former is used as the certificate
presented to a TLS client when it connects to a TlsConnection created in
server
mode. The latter only appears to be used for signing stuff (computeIdentity
and
checkIdentity functions). No provision is made for a client side certificate
per se.
uhmm the PublicCert would be used for this
Well, maybe not. At present the PublicCert is used as the server certificate.
If we have a situation where the transport is being used as a TLS client and the
server requires mutual authentication, we *may* want a separate client side
certificate, mightn't we? I would have thought that situation might arise in
practice.
However, if the Security object is not actually going to be used to
checkIdentity or computeIdentity (these functions do not actually appear to be
called anywhere by code in the reSIProcate source tree) the publicIdentityCert
*could* be overloaded to act as a client certificate.
Question: *should* the publicIdentityCert be overloaded, or should a
different certificate be attached to the Security object for
this purpose?
No the identity is claims is wrong. It is going to assert something like
"fluffy@xxxxxxxxx" not "host22.cisco.com"
Fair enough, although it is unclear to me that a Security object will ever be
used *both* for TlsTransport certificates *and* for S/MIME signing.
When a Security object is created it is either a server or a client; this is
recorded in the mTlsServer member variable. When a Security object is used
(e.g. by TlsConnection) to obtain an SSL context (using getTlsCtx) the
argument
isServer is passed in the call. Why does this need to be specified in two
different places? What problem is it designed to solve? The mTlsServer
member
variable is only used in getTlsCtx, and it is far from clear what is supposed
to
happen if mTlsServer and isServer have different values.
One can be a server, but not a tlsServer meaning you can act as a server but
you can not accept incoming TLS connections.
OK... I'll have to digest that one.
Considering the situation when a TlsTransport is used both as a server and as
a
client, it would be convenient to have a Security object that returned a
different CTX depending on the role.
How would the TLS context be different for the two roles?
Viz. my comment following "uhmm the PublicCert would be used for this" earlier,
I think (and my understanding may be deeply flawed here) that one *might* want a
"client context" to have different certificates from a "server context".
It therefore seems sensible to remove
the
Security constructor tlsServer argument and the mTlsServer member variable
altogether.
Question: *should* the Security::mTlsServer variable be removed (and all that
that implies)?
You might be right that this is exactly the right thing to do but I have
certainly not got my head wrapped around what you are talking about yet
Did my earlier inline comments help? We can bop this around offline if you
think it might be useful.
The Security object only ever creates one SSL_CTX which it stashes in the
ctxTls
member variable. At present, therefore, if a Security::getTlsCtx call was
made
in "client" mode before a later call in "server" mode, the SSL_CTX provided to
the server would have no certificate information. This seems entirely broken,
and probably reinforces the case for maintaining at least two SSL_CTX's - one
for each role.
I think there is confusion about server and client mode - and I may be
confused on how I remember it being and how it really is - server means you
have a certificate. client mode means you don't. Perhaps these are named
terribly wrong
At present you are mostly correct, give or take the fact that there are still
two places you have to specify whether or not this is a server side Security
object. My original commentary is not quite correct. Whether or not a
certificate is installed is determined by the setting of mTlsServer, effectively
when the object is created. However, the scenario I described is still possible:
1. a Security object is created with tlsServer == false
2. getTlsCtx is called with isServer == false;
a client side SSL_CTX is created and cached with no certificates attached
3. getTlsCtx is called with isServer == true;
the cached SSL_CTX is returned (with no certificate)
I'm not saying I can think of a sensible way to create these conditions, but I
simply don't understand why the design even makes it possible. Any TlsTransport
may end up being used in either mode, depending on how things get routed.
However, when you say "...client mode means you don't", that goes to the heart
of the matter. If I am going to support mutual (client side) authentication I
*must* have a certificate (or several) and at present I haven't.
Finally (I hope) the TLS standard requires that a client certificate is sent
only if it is signed (ultimately) by one of the acceptable CAs provided in the
certificate request.
No self signed certs are fine to send - they just must be received carefully
Ummm... not according to the OpenSSL client_cert_cb man page, and I assume they
base their statement on an RFC of some kind (obviously I haven't looked this up)
The Security class could allow the certificate selection
to be performed by a caller-provided mechanism by using the
SSL_CTX_set_client_cert_cb mechanism.
Question: *should* a user of the Security class be allowed to determine how
certificate selection is performed, or should this be nailed down
beyond user interference in the Security implementation?
Well, let's look at what they would want to be able to control and find a
way to allow that
I think that covers my immediate concerns; at least regarding reSIProcate, as
opposed to those about world hunger, AIDS, global warming, etc.. If anyone
feels like providing me with a better sense of direction I would be greatly
obliged. In particular, if there are M's I should be RTFing please let me
know.
Glad to see some work on this and happy to help (though likely after IETF)
Thanks. I may have to make my changes locally and see how things go. I've been
stalling this for too long already, and at this point I simply have to make
something work! However, it kinda sounds like this is not a widely interesting
problem, so if I check in some backward compatible mods that are later deemed to
be a Bad Idea, I assume no one will get too upset. NOW is the time to tell me
if I'm wrong about that!
--
Bob Bramwell Jasomi Networks (Canada) | This space
Ph: 403 269 2938 x155 #310 602 11th Ave SW | intentionally
FX: 403 269 2993 Calgary, AB, T2R 1J8 | left blank.