httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Laurie <>
Subject Re: mod_ssl custom authentication hook
Date Wed, 09 Apr 2003 16:30:32 GMT
Kris Verbeeck wrote:
> Ben Laurie wrote:
>>> We are trying to do custom ssl certificate checking, in stead of 
>>> using the
>>> standard callback.  We have introduced an optional function
>>> (custom_ssl_verify), and a new nVerifyClient type 
>>> that verify type is set, and there is an implementation of 
>>> custom_ssl_verify,
>>> we set that as verify callback using modssl_set_verify().  However, 
>>> we are
>>> experiencing some odd behaviour:
>>> For each request, our callback is called 3 times.  This is not really an
>>> issue, because we do caching, but it makes us wonder if we're doing
>>> something wrong.  Of more concern is the fact, that though we set
>>> SSL_VERIFY_CLIENT_ONCE in the verify options, for every request
>>> (every image, etc on the page), the server re-requests client 
>>> authentication.
>>> This is obvious from what we see in ssldump output.  Everytime the user
>>> must retype his passphrase for their client certificate's private key 
>>> (if he
>>> has set one of course).  The standard code path (SSL_CVERIFY_REQUIRE) 
>>> only
>>> seems to request client auth once.
>>> Is there anything we're missing?
>> Are you somehow preventing session reuse in your version?
> Our own custom verification function just returns false if
> authentication failed (which will trigger session abort).  This is also
> what is done in the default verification code.
> We did some more testing, also with the default verification code and
> discovered the following:
> - If you configure SSL client authentication on the level of a virtual
> host, the server only asks the client certificate once.  So, no problem
> here.  This seems to work both for the default code and our own custom
> verification code.
> - If the client authentication is configured on the level of a directory,
> the server asks the client certificate for every request (html, gif, css)
> in that directory.  This happens with both the default verification code
> and our one custom hook.

Well, that makes more sense. If it is configured per-directory, then it 
is not known at initial connection time whether a client cert is needed. 
So, it is bound to have to think about it again once the request is 
known. If it concludes that it does need something new, then it will 
force a renegotiation.

This occurs in ssl_engine_kernel.c:ssl_hook_Access(), and as you can 
see, is pretty complex. Renegotiation can be triggered by things other 
than client certificates, of course, so it'd probably be worth figuring 
out what actually triggers the renegotiation.

Another issue is that OpenSSL didn't (not sure if this is still true, 
I'd have to check) keep client certificates in the session structure - 
in Apache-SSL I added them "by hand" as it were, so it could be that 
renegotiation is interacting badly with that.

> So maybe this is just a configuration issue?  Is it possible for mod_ssl
> to cache the directories for which it has authenticated the current
> session?  We need this fine-grained config (location directive) but we
> do not want to trigger multiple client certifciate pop-ups at client
> side for every request.
> We also tried enabling the OptRenegotiate option but then only the first
> request succeeded and all subsequent request failed and reported
>    [error] Re-negotiation verification step failed
>    [error] Re-negotiation handshake failed: Client verification failed
> in the Apache error_log.

With that option set, in fact renegotiation doesn't happen at all, the 
cert is just rechecked. Does your custom verification actually get called?

>> Looking at this has made me think of something else, though: really, 
>> verification ought to _always_ be done by a hook, and that hook should 
>> be supplied by an appropriate module - the standard one doing the 
>> verification we know and love, of course.
> Yep, our thoughts exactly.
>> Fixing that may make it clearer what your problem is, of course. I'll 
>> think about how to do it.
> Thx.  Keep us posted.

I've been looking for a while now. Non-trivial. :-)

But I'm not giving up yet.




"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

View raw message