> 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?

No, that's probably due to a misunderstanding. In its current form, the
patch will set the correct SSLVerify parameters for the named vhost very
early in the initial TLS handshake (in ssl_find_vhost, which is called
by ap_vhost_iterate_given_conn). If "SSLVerifyClient require" is
configured at the vhost level and there's no certificate from the peer,
then the initial handshake will already fail (as you would expect).

A second handshake (triggered by ssl_hook_Access) only takes place if
there are per-directory specific settings (SSLVerifyClient, but also
SSLCipher) which differ from the per-server setting. Maybe the following
- somewhat artificial - pseudo config helps to illustrate the difference:

  <VirtualHost *:443>
    # Server 1
    SSLVerifyClient optional_no_ca
  </VirtualHost>

  <VirtualHost *:443>
    # Server 2
    SSLVerifyClient require
  </VirtualHost>

  <VirtualHost *:443>
    # Server 3
    <Location />
      SSLVerifyClient require
    </Location>
  </VirtualHost>

For server 2, there will only be one handshake, and it will fail right
after the CertificateRequest if the peer doesn't supply a valid client
cert. For server 3 (only shown for illustration purposes, doesn't make
much sense in a real-word config), a second handshake is triggered by
ssl_hook_Access, as the SSLVerifyClient parameter is a per-directory
setting in this case (there's an implied "SSLVerifyClient none" default
setting at the vhost level, which is used during the initial handshake).

> 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.

Absolutely agreed. That's exactly what the SSL_set_verify call in
ssl_find_vhost is for (which I added after your previous comments, this
was indeed a problem with the old version of the patch).

I hope this helps to clear up some of the confusion - let me know if you
still see issues with the current implementation.

Thanks,
Kaspar

Reply via email to