httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Orton <>
Subject Re: Bug 35083 - SSL error trapping
Date Tue, 09 Jan 2007 14:30:00 GMT
Hi Marc,

On Mon, Jan 08, 2007 at 02:15:44PM +0100, Marc Stern - Approach wrote:
> 1. The current idea is to trap validation-related errors, like 
> certificate expiration/revocation.
> Shouldn't we also trap negotiation errors, like incompatible 
> ciphersuites and protocols between browser and server ?
> Maybe other ones ?

I would not try to solve everything at once; just concentrate on the one 
problem of handling verification errors.

> 2. Recommendations are to use one directive to relax the check on 
> certificates (or on ciphersuites, ...), and other ones to trap errors by 
> checking environment variables and redirect the 403 errors to a specific 
> page.
> a. Doesn't this introduce a security risk, in case the check on 
> certificates is relaxed and the other directives are not set (or changed) ?
>   This is against the principle of secure by installation ...

I don't see a problem here.  The proposal was to add a directive to 
relax/restrict the set of verification errors which are considered 
"acceptable" for an "SSLVerifyClient optional" configuration.

That directive will then control whether or not the 403 is returned.

> b. This solution would redirect all errors to the same page.
>   Isn't it better to trap the error and redirect to a specific 
> (customisable) page ?
>   Note that this trapping could be implemented in a separate module.

I'm not sure what else is needed here.  It should already be possible to 
access the verification error string e.g. from mod_rewrite using 
%{SSL:SSL_CLIENT_VERIFY}.  I'd guess this could be done during the 
handling of the 403 and could allow a rewrite to a custom URI - or is 
there something which prevents that?



View raw message