[Date Prev][Date Next] [Chronological] [Thread] [Top]

RE: TLS client certs, SASL EXTERNAL

At 01:48 PM 2002-01-26, Howard Chu wrote:
>> -----Original Message-----
>> From: Pierangelo Masarati [mailto:masarati@aero.polimi.it]
>> > succeed. It seems to me that we need a middle "client cert is
>> optional" state
>> > in here, so that the server can ask for a client cert but will not
>> complain if
>> > none is available. Or we can just change the default state to
>> "always ask for
>> > optional client cert" for simplicity. Opinions, anyone?
>> I'd prefer to have a third option (say "ASK", or "no" "yes" "critical"
>> for consistency with the tls options), to allow more fine grain
>> configuration.  I wonder what solution breaks the least number
>> of installations :)
>OK, I agree with that. I'm actually looking at 4 options now:
>        no/never - same as old default, the server never asks for a client cert.
>        allow - server asks. If a bad cert is received, ignore it.

I'm not sure this about this one, that behavior might be
counter to the specs (though I haven't checked).  Anyways,
I think the client should be told its cert is bad.  Also,
as some clients blindly go on, killing the connection is a
good here.  However, as long as appropriate security
considerations are noted in the documentation, I can live
with it.

>        try - server asks. If a bad cert is received, kill connection.

>        demand - same as "yes" - Must receive a valid cert.
>In the "allow" and "try" cases, it is OK if the client has no cert. The
>difference is just when a cert is presented. In the try case, if a bad cert is
>received, fail the connection. In the allow case, if a bad cert is received,
>just proceed as if no cert was received. This may be useful when a foreign
>client has its own cert but the server doesn't recognize it; the normal
>verification behavior would prevent the foreign client from ever using TLS with
>the server.
>The OpenSSL library directly supports the never/try/demand conditions. It will
>take some tweaking in the callback routine to support the allow case.
>  -- Howard Chu
>  Chief Architect, Symas Corp.       Director, Highland Sun
>  http://www.symas.com               http://highlandsun.com/hyc
>  Symas: Premier OpenSource Development and Support