> -----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
