Thanks for the detailed response and sorry for the slow follow-up, Kaspar. I'll just deal with the main issue for the time being:
On Wed, Jan 02, 2008 at 05:36:22PM +0100, Kaspar Brand wrote: > > Has a configuration > > with an SSLVerifyClient specified in the named vhost been tested? > > Yes, and one specific configuration actually made me tweak the code in > the servername callback further: when modifying the SSL connection, > OpenSSL's SSL_set_SSL_CTX() will only adjust the server cert from the > context, but not additional settings like verify_mode and the verify > callback. These are relevant when SSLVerifyClient is configured at the > *per-server* context (i.e. at the vhost level), and the previous version > of the patch failed to enforce such a configuration, at least in cases > where SSLVerifyClient for the first (=default) VirtualHost was different > than for any subsequent VirtualHosts. This still seems like a big issue to me. There are other settings in the SSL_CTX which are relevant to the initial handshake - and indeed, later renegotiations - notably the CA used for client cert verification, and the list of CA cert names which is sent to the client (to allow selection of a pertinent client cert). If I understand correctly, the current code is relying on ssl_hook_Access to perform a *second* handshake which will ensure that the named vhost's access control configuration is enforced, if necessary? This seems like a hack - it should be done in the initial handshake, since it theoretically can - and requiring a second handshake invokes the spectre of PR 12355 and associated problems. I don't think it's even a sufficient hack: ssl_hook_Access will not check for situations where per-vhost settings have changed from the initial handshake (since without SNI, this cannot occur). e.g. for a config where the initial vhost has a different SSLCACertificate* to the named vhost, and 'SSLVerifyClient require' in both; ssl_hook_Access will do nothing. (It may seem pedantic to bring up pathological config examples like this, but silently failing to implement the configured access control, however crazy, is certainly a security issue.) joe
