Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <49D0EFF7.8030902@velox.ch>
Date: Mon, 30 Mar 2009 18:14:47 +0200
From: Kaspar Brand <httpd-dev.2009@velox.ch>
User-Agent: Thunderbird 2.0.0.21 (Windows/20090302)
MIME-Version: 1.0
To: dev@httpd.apache.org
Subject: Re: SNI in 2.2.x (Re: Time for 2.2.10?)
References: <48AA6528.1090301@velox.ch> <49CE81CA.6090708@apache.org>
In-Reply-To: <49CE81CA.6090708@apache.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ruediger Pluem wrote:
> Going through the archive I noticed several attachments with the same
> basename and and a version string attached. Are these patches
> cumulative so that I only need to review the latest one?

sni_sslverifyclient-v5.diff includes all improvements to
ssl_hook_Access/ssl_callback_SSLVerify/ssl_callback_SSLVerify_CRL
which I did in June 2008, yes. Then I stopped updating the trunk version
(due to lack of responses) and only worked on further improvements on to
the 2.2.x patch (latest version lives at
http://sni.velox.ch/httpd-2.2.x-sni.20080928.patch).

> As said several times we consider name based virtual hosting for SSL 
> *without* SNI as not recommended and insecure. This has not changed 
> with the SNI patches applied to trunk.

Other than being the ceterum censeo, what's the rationale here? "Not
recommended and insecure" sounds like FUD to me, and apparently no one
has spent at least a few hours to verify (or disprove) the analysis I
undertook last June.

Locking out non-SNI capable clients from all but the first vhost is
overkill for many configurations (e.g. when no SSL access restrictions
are in place), and will break configurations which used to work with
2.2. People *are* doing things like those shown at
http://wiki.cacert.org/wiki/CSRGenerator to address their needs, and
this would break with your change suggested for 2.4 ("because we always
said..." - yes, I know, that will be your [compelling?] argument).

> Not SNI enabled clients receive a 403 when contacting any of
> the name based virtual hosts (which enables you to set a nice error
> page to explain to the user what happened and which browser to use).

Why hardcode HTTP_FORBIDDEN? Leave it to the user to configure it
as needed, as I outlined an earlier posting:

> * you can use this information in mod_rewrite rules, e.g. for
>   rewriting requests based on the absence of an SNI extension (such as
>   'RewriteCond %{SSL:SSL_TLS_SNI} =""'

Kaspar