httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Henri Gomez <>
Subject Re: SNI in 2.2.x (Re: Time for 2.2.10?)
Date Tue, 07 Apr 2009 13:32:20 GMT
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

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.


2009/4/7 "Plüm, Rüdiger, VF-Group" <>:
>> -----Ursprüngliche Nachricht-----
>> Von: Kaspar Brand
>> Gesendet: Montag, 30. März 2009 18:15
>> An:
>> 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
>> > 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

View raw message