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
