Plüm, Rüdiger, VF-Group wrote:
> As I said further down below I see also good and valid use cases for the
> combination
> SSLVerifyClient optional
> and
> %{SSL_CLIENT_VERIFY}
> And this combination should be safe even if this comes at the price that
> some configuration are not possible without SNI. But yes, we may disagree
> on this :-).
If that's the only remaining issue which needs to be sorted out, then
I feel quite confident that we'll be able to agree on a solution
within very reasonable time :-)
> I would only love to see that the parts in your patch were you
> used r->connection->aborted are adjusted accordingly.
Using modssl_set_verify to restore the setting to "verify_old" seems
fine, AFAICT (the client is free to retry the request over the same
connection, but we'll send him a 403 again, anyway... that even saves
us additional handshakes, in case of stubborn clients repeating
their requests).
Here's another idea for trying to cut that Gordian knot:
if ((r->server != handshakeserver)
&& renegotiate
&& ((verify & SSL_VERIFY_PEER) ||
(verify & SSL_VERIFY_FAIL_IF_NO_PEER_CERT))) {
SSLSrvConfigRec *hssc = mySrvConfig(handshakeserver);
#define MODSSL_CFG_CA_NE(f, sc1, sc2) \
(sc1->server->auth.f && \
(!sc2->server->auth.f || \
sc2->server->auth.f && \
strNE(sc1->server->auth.f, sc2->server->auth.f)))
if ((MODSSL_CFG_CA_NE(ca_cert_file, sc, hssc) ||
MODSSL_CFG_CA_NE(ca_cert_path, sc, hssc)) &&
(verify & SSL_VERIFY_FAIL_IF_NO_PEER_CERT)) {
ap_log_rerror(APLOG_MARK, APLOG_INFO, 0, r,
"Non-default virtual host with SSLVerify set to "
"'require' and VirtualHost-specific CA certificate "
"list is only available to clients with TLS server "
"name indication (SNI) support");
modssl_set_verify(ssl, verify_old, NULL);
return HTTP_FORBIDDEN;
} else
/* let it pass, possibly with an "incorrect" peer cert,
* so make sure the SSL_CLIENT_VERIFY environment variable
* will indicate partial success only, later on.
*/
sslconn->verify_info = "GENEROUS";
}
I.e., if someone configures a non-default vhost with "SSLVerifyClient optional",
and checks for %{SSL_CLIENT_VERIFY} in an SSLRequire expression (hopefully
with 'eq "SUCCESS"'), then non-SNI clients will still be banned.
Kaspar
