I'm working on securing massive NameVirtualHost sites using SSL. The SNI support should be avoided since we needed a stock Apache 2.x / mod_ssl solution, so it prevent us to take a look at mod_gnutls/gnutls.
Question : How hard will it be to have SNI support conditional and activated/disabled by an Apache directive ? Leaving this as disabled by default will preserve the current situation but will allow advanced configuration to use SNI. Just a suggestion. Regards 2009/4/7 "Plüm, Rüdiger, VF-Group" <ruediger.pl...@vodafone.com>: > > >> -----Ursprüngliche Nachricht----- >> Von: Kaspar Brand >> Gesendet: Montag, 30. März 2009 18:15 >> An: dev@httpd.apache.org >> Betreff: Re: SNI in 2.2.x (Re: Time for 2.2.10?) >> >> 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. > > I reviewed your patch and found some issues with it. > > (All cases below use Name based virtual hosting and a non SNI client): > > 1. Renegotiation due to more restrictive cipher requirements: > > Lets say the first virtual host allows cipher A and B. > The handshake with the client decided to use A. > The virtual host the client switches to later also allows A and B. > But /restricted in this host only allows B. > In this case a request to /restricted does not cause a renegotiation > but it should. > > 2. The verification depth check causes unneeded renegotiations which > break the ssl v2 tests in the perl framework (No dicussion here please > whether we should still support SSL v2 :-)) > > There might be further issues but I currently have no time to check. > > I think we both agree that without this patch from you name based virtual > hosting with SSL is definitely unsafe. > I haven't analyzed any further if the above issues are fixable or not > and I admit that I currently have no resources to do so. > > Regards > > Rüdiger >
