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
