httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marc Stern - Approach <>
Subject Re: Bug 35083 - SSL error trapping
Date Wed, 10 Jan 2007 10:57:41 GMT
Hi Joe

>> 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.
OK, although it may be a step back if we decide to trap other stuff later.
For example, negotiation errors will not set the variable SSL_CLIENT_VERIFY.
I really wonder if we are not better to not use existing variable and 
directives - so adding a new variable like SSL_STATUS.
Also, comparing strings is not very pretty (what if OpenSSL error 
message changes, even slightly); I would recommend an error code.

>> 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.
aybe I misunderstood; I thought you were suggesting that the 403 had to 
be managed in the conf file with "SSLRequire".
So, we relax the check with "SSLVerifyClient optional_...", then we 
redirect to 403 with "SSLRequire".
In this case, if we ever break the "SSLRequire" (you know administrators 
;-), then all certificates are accepted.
I understand it works, but isn't that too complex for a normal admin, 
and potentially dangerous ?

>> 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?
You're right, although I would recommend (cf. 1) a new variable 
containing a return code.


View raw message