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
|