Re: Opt in(/out?) for TLS protocol per vhost (was: svn commit: r1868645)

[Rüdiger Plüm <r....@gmx.de>]

On 10/28/2019 10:54 AM, Yann Ylavic wrote:
> On Mon, Oct 28, 2019 at 9:24 AM Stefan Eissing
> <st...@greenbytes.de> wrote:
>>
>> Ok, let me summarize:
>>
>> - SSLProtocol on base server applies, unless vhost has its own setting
>> - no SSLProtocol on base server, SSLProtocol on vhost applies
>> - no SSLProtocol on base server, no SSLProtocol on vhost, possible SSLProtocol on base vhost applies
>
> That's it, I'd call "base server" the "global server", though, to
> avoid confusion w.r.t. to c->base_server (the "base vhost" in the
> above).
>
> For 2.4.x, this means that there is a behavioural change when:
> - SSLProtocol is specified in a non-base vhost (but this is the point),
> - no SSLProtocol is specified in a non-base vhost AND one is specified
> globally (here the global applies, whereas previously the base vhost's
> applied).
>
> Once/if backported, I plan to completely remove the base vhost from
> the game, in trunk (usual merging applies).

So you want to revert r1868929 after the backport?

As far as I can tell r1868929 keeps the inheritance behavior closer to the
previous 2.4.x and trunk behavior, but is different compared to the
inheritance behavior of already SNI respecting directives like e.g. SSLCipherSuite.
Removing r1868929 would bring both (the directives respecting SNI so far
and the ones that NOW respect SNI) to the same inheritance level, correct?

Regards

Rüdiger

Re: Opt in(/out?) for TLS protocol per vhost (was: svn commit: r1868645)

[Yann Ylavic <yl...@gmail.com>]

On Tue, Nov 5, 2019 at 9:19 AM Rüdiger Plüm <r....@gmx.de> wrote:
>
> On 10/28/2019 10:54 AM, Yann Ylavic wrote:
> >
> > Once/if backported, I plan to completely remove the base vhost from
> > the game, in trunk (usual merging applies).
>
> So you want to revert r1868929 after the backport?

Yes, exactly.

>
> As far as I can tell r1868929 keeps the inheritance behavior closer to the
> previous 2.4.x and trunk behavior, but is different compared to the
> inheritance behavior of already SNI respecting directives like e.g. SSLCipherSuite.
> Removing r1868929 would bring both (the directives respecting SNI so far
> and the ones that NOW respect SNI) to the same inheritance level, correct?

That's it, and consistent with all other RSRC_CONF directives merging.
The difference between 2.4 (with r1868929) and trunk (without) would
be only if no global SSLProtocol is configured.
In this case any vhost with no SSLProtocol either would take the
default value (the hard coded "ALL -SSLv3" currently), instead of
first name based vhost's (which wouldn't be involved anymore for
SSLProtocol).

Sounds good?

Thanks,
Yann.