httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kaspar Brand <httpd-dev.2...@velox.ch>
Subject Re: [PATCH] Further refinements for SNI
Date Sat, 26 Apr 2008 16:28:10 GMT
Joe Orton wrote:
> I hacked up a quick test based on Dirk's make_sni.sh; this adds 
> "SSLVerifyClient" & SSLCACertificateFile to the second and third named 
> vhosts.
> 
> And this confirms my original suspicions: I can access those vhosts 
> without having to present a certificate, i.e. the configured access 
> control restrictions can be bypassed.  If I move the SSLVerifyClient/etc 
> to the first vhost, it works as expected.

Right, I can reproduce this issue. It's occurring when the client does
*not* include an SNI extension in its ClientHello, which can happen with
both "old" (i.e. non-SNI capable) clients as well as with SNI-capable
clients (if they're trying to downgrade to TLS without extensions or to
SSLv3, e.g.).

>From my understanding/analysis of the code, there are two ways how the
correct vhost configuration can be assigned to an SSL request_rec:

a) in ssl_callback_ServerNameIndication(), which is called very early in
the SSL handshake. This makes sure that the correct SSLVerifyClient,
SSLVerifyDepth and SSLCACertificateFile are set before the server
verifies the client cert, and will result in a handshake error before
any HTTP request has been sent. This method only works for clients which
include an SNI extension in their ClientHello, of course.

b) in protocol.c:ap_read_request(), where the correct vhost is selected
based on the Host: header sent in the HTTP request. Access control for
this case can only be handled after the request has been read, and is
done in ssl_hook_Access(). Unfortunately, ssl_hook_Access() currently
doesn't honor the SSLVerifyClient/SSLVerifyDepth directives at the vhost
level when the vhost config has been updated in ap_read_request() - it
only enforces those set in per-directory context (<Directory>,
<Location> and friends). Depending on the new
SSLVerifyClient/SSLVerifyDepth settings, ssl_hook_Access() will trigger
a renegotiation (to request a client certificate if the default/first
vhost doesn't uses the default settings, i.e. no clientauth).

There are two solutions for the issue you're experiencing, in my view:

1) for the second and third vhost, add an enclosing <Location> block
   to the SSLVerify* directives:

   <VirtualHost 127.0.0.1:4433>
       SSLEngine On
       ServerName nut.my-sni-test.org:4433
       DocumentRoot /home/kbrand/sni/htdocs/nut
       SSLCertificateChainFile /home/kbrand/sni/root.pem
       SSLCertificateFile /home/kbrand/sni/ssl/nut.crt
       TransferLog /home/kbrand/sni/logs/access_nut
       SSLCACertificate /home/kbrand/sni/root.pem
       <Location>
           SSLVerifyClient require
           SSLVerifyDepth 10
       </Location>
   </VirtualHost>

2) apply something like the attached patch, which makes sure that
   ssl_hook_Access also honors SSLVerifyClient/SSLVerifyDepth directives
   set at the vhost level, after a new vhost config has been assigned
   by ap_read_request (maybe there's a more elegant way to write it,
   code-wise, but it should demonstrate the basic principle)

Kaspar

Mime
View raw message