Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <45A4C6A5.5090508@approach.be>
Date: Wed, 10 Jan 2007 11:57:41 +0100
From: Marc Stern - Approach <marc.stern@approach.be>
User-Agent: Thunderbird 1.5.0.9 (Windows/20061207)
MIME-Version: 1.0
To: Joe Orton <jorton@redhat.com>,
 Development Apache <dev@httpd.apache.org>
Subject: Re: Bug 35083 - SSL error trapping
References: <45A24400.2040806@approach.be> <20070109143000.GA31914@redhat.com>
In-Reply-To: <20070109143000.GA31914@redhat.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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.


Marc