On Apr 22, 2008, at 5:53 PM, Joe Orton wrote:
On Wed, Feb 13, 2008 at 10:00:23AM +0100, Kaspar Brand wrote:
While I was testing revocation checking for client certs in an SNI
configuration (Dirk, many thanks for make_sni.sh, btw!), I came across a
flaw in the current implementation when CRL information - i.e.
SSLCARevocationFile/SSLCARevocationPath - is set on a per-vhost basis
(don't know how much sense it makes to have non-global CRLs, but anyway...).

Someone bugged me about the SNI support so I finally go round to chasing
this up.

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.

Is this fixed by Kasper Brand his patch ? (See his msg from 13/2) ?

Dw.

--- Begin Message ---
While I was testing revocation checking for client certs in an SNI
configuration (Dirk, many thanks for make_sni.sh, btw!), I came across a
flaw in the current implementation when CRL information - i.e.
SSLCARevocationFile/SSLCARevocationPath - is set on a per-vhost basis
(don't know how much sense it makes to have non-global CRLs, but anyway...).

The attached patch addresses this issue, and it also improves the
logging behavior for an SNI enabled configuration (previously some of
the messages would always go to the first vhost, or wouldn't appear at
all, depending on the LogLevel of the first vhost).

Kaspar
Index: httpd-trunk/modules/ssl/ssl_engine_kernel.c
===================================================================
--- httpd-trunk/modules/ssl/ssl_engine_kernel.c (revision 627257)
+++ httpd-trunk/modules/ssl/ssl_engine_kernel.c (working copy)
@@ -2017,14 +2017,32 @@ static int ssl_find_vhost(void *serverna
             * SSL connection is set up (num_renegotiations == 0).
             * Otherwise, we would possibly reset a per-directory
             * configuration which was put into effect by ssl_hook_Access.
             */
             SSL_set_verify(ssl, SSL_CTX_get_verify_mode(ssl->ctx),
                            SSL_CTX_get_verify_callback(ssl->ctx));
         }
 
+        /*
+         * We also need to make sure that the correct mctx is
+         * assigned to the connection - the CRL callback e.g.
+         * makes use of it for retrieving its store (mctx->crl).
+         * Since logging in callbacks uses c->base_server in many
+         * cases, it also ensures that these messages are routed
+         * to the proper log. And finally, there is one special
+         * filter callback, which is set very early depending on the
+         * base_server's log level. If this is not the first vhost
+         * we're now selecting (and the first vhost doesn't use
+         * APLOG_DEBUG), then we need to set that callback here.
+         */
+        c->base_server = s;
+        if (c->base_server->loglevel >= APLOG_DEBUG) {
+            BIO_set_callback(SSL_get_rbio(ssl), ssl_io_data_cb);
+            BIO_set_callback_arg(SSL_get_rbio(ssl), (void *)ssl);
+        }
+
         return 1;
     }
 
     return 0;
 }
 #endif

--- End Message ---

Reply via email to