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

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Yann Ylavic
On Sun, Oct 20, 2019 at 12:50 PM <[hidden email]> wrote:
>
> Author: ylavic
> Date: Sun Oct 20 10:50:33 2019
> New Revision: 1868645
>
> URL: http://svn.apache.org/viewvc?rev=1868645&view=rev
> Log:
> mod_ssl: negotiate the TLS protocol version per name based vhost configuration.

I'm planning to propose this for backport to 2.4.x, but wonder if it
should be opt in/out.

I can see potential behaviour change for existing configurations if,
for instance, one has specified some SSLProtocol at the base server
level but none (relying on the current behaviour) or something
different (somehow working unwittingly of his/her own free will) at
the other name-based vhost(s) level.

Thoughts?

Regards,
Yann.
Reply | Threaded
Open this post in threaded view
|

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

Stefan Eissing
While I like this change and think, ideally, it would have behaved like this all the time, I think we need to make this "opt-in" for 2.4.

If I understand this correctly: if someone has some old SSLProtocol/Cipher/etc. setting sitting in a vhost, *ineffective now since it is not the first vhost*, this change would activate it. So it could expose a site to a TLS setting that is not appropriate for it. One could argue that the first mistake was for the admin to leave that setting there, but...

- Stefan

> Am 25.10.2019 um 09:46 schrieb Yann Ylavic <[hidden email]>:
>
> On Sun, Oct 20, 2019 at 12:50 PM <[hidden email]> wrote:
>>
>> Author: ylavic
>> Date: Sun Oct 20 10:50:33 2019
>> New Revision: 1868645
>>
>> URL: http://svn.apache.org/viewvc?rev=1868645&view=rev
>> Log:
>> mod_ssl: negotiate the TLS protocol version per name based vhost configuration.
>
> I'm planning to propose this for backport to 2.4.x, but wonder if it
> should be opt in/out.
>
> I can see potential behaviour change for existing configurations if,
> for instance, one has specified some SSLProtocol at the base server
> level but none (relying on the current behaviour) or something
> different (somehow working unwittingly of his/her own free will) at
> the other name-based vhost(s) level.
>
> Thoughts?
>
> Regards,
> Yann.

Reply | Threaded
Open this post in threaded view
|

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

Yann Ylavic
On Fri, Oct 25, 2019 at 9:56 AM Stefan Eissing
<[hidden email]> wrote:
>
> If I understand this correctly: if someone has some old SSLProtocol/Cipher/etc. setting sitting in a vhost, *ineffective now since it is not the first vhost*, this change would activate it.

Ciphers/etc work per vhost already thanks to the SNI callback, it's
only SSLProtocol that can't be changed from there due to OpenSSL
internals (AIUI), but still..

> So it could expose a site to a TLS setting that is not appropriate for it. One could argue that the first mistake was for the admin to leave that setting there, but...

Yeah, my fear as well.
Reply | Threaded
Open this post in threaded view
|

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

Yann Ylavic
In reply to this post by Stefan Eissing
On Fri, Oct 25, 2019 at 9:56 AM Stefan Eissing
<[hidden email]> wrote:
>
> While I like this change and think, ideally, it would have behaved like this all the time, I think we need to make this "opt-in" for 2.4.

So now the "how" and name bikeshedding :)

SSLHonorVhostProtocol on/off (default: off) at the server config scope (only)?

>
> If I understand this correctly: if someone has some old SSLProtocol/Cipher/etc. setting sitting in a vhost, *ineffective now since it is not the first vhost*, this change would activate it. So it could expose a site to a TLS setting that is not appropriate for it. One could argue that the first mistake was for the admin to leave that setting there, but...
>
> - Stefan
>
> > Am 25.10.2019 um 09:46 schrieb Yann Ylavic <[hidden email]>:
> >
> > On Sun, Oct 20, 2019 at 12:50 PM <[hidden email]> wrote:
> >>
> >> Author: ylavic
> >> Date: Sun Oct 20 10:50:33 2019
> >> New Revision: 1868645
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1868645&view=rev
> >> Log:
> >> mod_ssl: negotiate the TLS protocol version per name based vhost configuration.
> >
> > I'm planning to propose this for backport to 2.4.x, but wonder if it
> > should be opt in/out.
> >
> > I can see potential behaviour change for existing configurations if,
> > for instance, one has specified some SSLProtocol at the base server
> > level but none (relying on the current behaviour) or something
> > different (somehow working unwittingly of his/her own free will) at
> > the other name-based vhost(s) level.
> >
> > Thoughts?
> >
> > Regards,
> > Yann.
>
Reply | Threaded
Open this post in threaded view
|

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

Stefan Eissing
Can we wait with the naming discussion after I opened my Friday evening Wine bottle?

> Am 25.10.2019 um 10:16 schrieb Yann Ylavic <[hidden email]>:
>
> On Fri, Oct 25, 2019 at 9:56 AM Stefan Eissing
> <[hidden email]> wrote:
>>
>> While I like this change and think, ideally, it would have behaved like this all the time, I think we need to make this "opt-in" for 2.4.
>
> So now the "how" and name bikeshedding :)
>
> SSLHonorVhostProtocol on/off (default: off) at the server config scope (only)?
>>
>> If I understand this correctly: if someone has some old SSLProtocol/Cipher/etc. setting sitting in a vhost, *ineffective now since it is not the first vhost*, this change would activate it. So it could expose a site to a TLS setting that is not appropriate for it. One could argue that the first mistake was for the admin to leave that setting there, but...
>>
>> - Stefan
>>
>>> Am 25.10.2019 um 09:46 schrieb Yann Ylavic <[hidden email]>:
>>>
>>> On Sun, Oct 20, 2019 at 12:50 PM <[hidden email]> wrote:
>>>>
>>>> Author: ylavic
>>>> Date: Sun Oct 20 10:50:33 2019
>>>> New Revision: 1868645
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=1868645&view=rev
>>>> Log:
>>>> mod_ssl: negotiate the TLS protocol version per name based vhost configuration.
>>>
>>> I'm planning to propose this for backport to 2.4.x, but wonder if it
>>> should be opt in/out.
>>>
>>> I can see potential behaviour change for existing configurations if,
>>> for instance, one has specified some SSLProtocol at the base server
>>> level but none (relying on the current behaviour) or something
>>> different (somehow working unwittingly of his/her own free will) at
>>> the other name-based vhost(s) level.
>>>
>>> Thoughts?
>>>
>>> Regards,
>>> Yann.
>>

Reply | Threaded
Open this post in threaded view
|

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

Yann Ylavic
Sure thing! Wine usually disinhibits discussions :)

On Fri, Oct 25, 2019 at 11:45 AM Stefan Eissing
<[hidden email]> wrote:

>
> Can we wait with the naming discussion after I opened my Friday evening Wine bottle?
>
> > Am 25.10.2019 um 10:16 schrieb Yann Ylavic <[hidden email]>:
> >
> > On Fri, Oct 25, 2019 at 9:56 AM Stefan Eissing
> > <[hidden email]> wrote:
> >>
> >> While I like this change and think, ideally, it would have behaved like this all the time, I think we need to make this "opt-in" for 2.4.
> >
> > So now the "how" and name bikeshedding :)
> >
> > SSLHonorVhostProtocol on/off (default: off) at the server config scope (only)?
> >>
> >> If I understand this correctly: if someone has some old SSLProtocol/Cipher/etc. setting sitting in a vhost, *ineffective now since it is not the first vhost*, this change would activate it. So it could expose a site to a TLS setting that is not appropriate for it. One could argue that the first mistake was for the admin to leave that setting there, but...
> >>
> >> - Stefan
> >>
> >>> Am 25.10.2019 um 09:46 schrieb Yann Ylavic <[hidden email]>:
> >>>
> >>> On Sun, Oct 20, 2019 at 12:50 PM <[hidden email]> wrote:
> >>>>
> >>>> Author: ylavic
> >>>> Date: Sun Oct 20 10:50:33 2019
> >>>> New Revision: 1868645
> >>>>
> >>>> URL: http://svn.apache.org/viewvc?rev=1868645&view=rev
> >>>> Log:
> >>>> mod_ssl: negotiate the TLS protocol version per name based vhost configuration.
> >>>
> >>> I'm planning to propose this for backport to 2.4.x, but wonder if it
> >>> should be opt in/out.
> >>>
> >>> I can see potential behaviour change for existing configurations if,
> >>> for instance, one has specified some SSLProtocol at the base server
> >>> level but none (relying on the current behaviour) or something
> >>> different (somehow working unwittingly of his/her own free will) at
> >>> the other name-based vhost(s) level.
> >>>
> >>> Thoughts?
> >>>
> >>> Regards,
> >>> Yann.
> >>
>
Reply | Threaded
Open this post in threaded view
|

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

Eric Covener
In reply to this post by Yann Ylavic
On Fri, Oct 25, 2019 at 4:09 AM Yann Ylavic <[hidden email]> wrote:

>
> On Fri, Oct 25, 2019 at 9:56 AM Stefan Eissing
> <[hidden email]> wrote:
> >
> > If I understand this correctly: if someone has some old SSLProtocol/Cipher/etc. setting sitting in a vhost, *ineffective now since it is not the first vhost*, this change would activate it.
>
> Ciphers/etc work per vhost already thanks to the SNI callback, it's
> only SSLProtocol that can't be changed from there due to OpenSSL
> internals (AIUI), but still..
>
> > So it could expose a site to a TLS setting that is not appropriate for it. One could argue that the first mistake was for the admin to leave that setting there, but...
>
> Yeah, my fear as well.

I am pretty conservative on these usually but I think opt-out would be OK.

--
Eric Covener
[hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Eric Covener
> I am pretty conservative on these usually but I think opt-out would be OK.

I am not even sure opt-out makes sense vs. just moving the directives
not expected to be used.
I guess some obscure config could reach the same VH over a non-SNI
alternate address AND different protocols are desired? Seems pretty
unlikely.
Reply | Threaded
Open this post in threaded view
|

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

Yann Ylavic
On Fri, Oct 25, 2019 at 1:21 PM Eric Covener <[hidden email]> wrote:
>
> > I am pretty conservative on these usually but I think opt-out would be OK.
>
> I am not even sure opt-out makes sense vs. just moving the directives
> not expected to be used.

Yes, opt-out is possibly no better than adjusting the configuration.
A oneliner may help though for complex/splitted configurations.

> I guess some obscure config could reach the same VH over a non-SNI
> alternate address AND different protocols are desired? Seems pretty
> unlikely.

I'm not sure I understand what you mean.

Suppose a config like the below (untested, will do):

<VirtualHost *:443>
  ServerName name1
  SSLProtocol TLSv1.2
</VirtualHost>

<VirtualHost *:443>
  ServerName name2
  # no SSLProtocol
</VirtualHost>

I think that currently (2.4.x), name2 is de facto "TLSv1.2" (like its
base server), but with r1868645 it's now "all -SSLv3" (the default for
SSLProtocol).
If an upgrade moves name2 from an A+++ to a B- it may well be the end
of the world :p

I will test that and confirm (or not).
Reply | Threaded
Open this post in threaded view
|

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

Eric Covener
On Fri, Oct 25, 2019 at 7:59 AM Yann Ylavic <[hidden email]> wrote:

>
> On Fri, Oct 25, 2019 at 1:21 PM Eric Covener <[hidden email]> wrote:
> >
> > > I am pretty conservative on these usually but I think opt-out would be OK.
> >
> > I am not even sure opt-out makes sense vs. just moving the directives
> > not expected to be used.
>
> Yes, opt-out is possibly no better than adjusting the configuration.
> A oneliner may help though for complex/splitted configurations.
>
> > I guess some obscure config could reach the same VH over a non-SNI
> > alternate address AND different protocols are desired? Seems pretty
> > unlikely.
>
> I'm not sure I understand what you mean.

I only meant where some actual opt-out would be useful vs. config fix.

>
> Suppose a config like the below (untested, will do):
>
> <VirtualHost *:443>
>   ServerName name1
>   SSLProtocol TLSv1.2
> </VirtualHost>
>
> <VirtualHost *:443>
>   ServerName name2
>   # no SSLProtocol
> </VirtualHost>
>
> I think that currently (2.4.x), name2 is de facto "TLSv1.2" (like its
> base server), but with r1868645 it's now "all -SSLv3" (the default for
> SSLProtocol).
> If an upgrade moves name2 from an A+++ to a B- it may well be the end
> of the world :p
>
> I will test that and confirm (or not).

Could the callback behave differently in the omitted case (opt-in)?
That would allow the case where it's explicit to be handled better
OOTB (not even opt-out really)

--
Eric Covener
[hidden email]
Reply | Threaded
Open this post in threaded view
|

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

Yann Ylavic
On Fri, Oct 25, 2019 at 2:08 PM Eric Covener <[hidden email]> wrote:
>
> Could the callback behave differently in the omitted case (opt-in)?
> That would allow the case where it's explicit to be handled better
> OOTB (not even opt-out really)

Nice idea, I suppose I could make the callback check for
->protocol_set == 0 and not switch in this case.
The opt-in may not be that useful then, without it (or "off") the
default would be the base server's SSLProtocol, while "on" would be
whatever SSLProtocol default is?

If we don't care about the compatibility of an explicit SSLProtocol
(e.g any SSLProtocol specified in my server2 example) which was
ignored until now but which suddenly isn't, I can go with that change.
Reply | Threaded
Open this post in threaded view
|

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

Stefan Eissing


> Am 25.10.2019 um 14:48 schrieb Yann Ylavic <[hidden email]>:
>
> On Fri, Oct 25, 2019 at 2:08 PM Eric Covener <[hidden email]> wrote:
>>
>> Could the callback behave differently in the omitted case (opt-in)?
>> That would allow the case where it's explicit to be handled better
>> OOTB (not even opt-out really)
>
> Nice idea, I suppose I could make the callback check for
> ->protocol_set == 0 and not switch in this case.
> The opt-in may not be that useful then, without it (or "off") the
> default would be the base server's SSLProtocol, while "on" would be
> whatever SSLProtocol default is?
>
> If we don't care about the compatibility of an explicit SSLProtocol
> (e.g any SSLProtocol specified in my server2 example) which was
> ignored until now but which suddenly isn't, I can go with that change.

+1
Reply | Threaded
Open this post in threaded view
|

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

Yann Ylavic
On Fri, Oct 25, 2019 at 3:16 PM Stefan Eissing
<[hidden email]> wrote:

>
> > Am 25.10.2019 um 14:48 schrieb Yann Ylavic <[hidden email]>:
> >
> > On Fri, Oct 25, 2019 at 2:08 PM Eric Covener <[hidden email]> wrote:
> >>
> >> Could the callback behave differently in the omitted case (opt-in)?
> >> That would allow the case where it's explicit to be handled better
> >> OOTB (not even opt-out really)
> >
> > Nice idea, I suppose I could make the callback check for
> > ->protocol_set == 0 and not switch in this case.
> > The opt-in may not be that useful then, without it (or "off") the
> > default would be the base server's SSLProtocol, while "on" would be
> > whatever SSLProtocol default is?
> >
> > If we don't care about the compatibility of an explicit SSLProtocol
> > (e.g any SSLProtocol specified in my server2 example) which was
> > ignored until now but which suddenly isn't, I can go with that change.
>
> +1

r1868929
Reply | Threaded
Open this post in threaded view
|

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

Yann Ylavic
In reply to this post by Yann Ylavic
On Fri, Oct 25, 2019 at 2:48 PM Yann Ylavic <[hidden email]> wrote:
>
> Nice idea, I suppose I could make the callback check for
> ->protocol_set == 0 and not switch in this case.
> The opt-in may not be that useful then, without it (or "off") the
> default would be the base server's SSLProtocol, while "on" would be
> whatever SSLProtocol default is?

By doing that change I realized that mod_ssl did not merge
->protocol_set (r1868934), but now I realize what merging means wrt to
the above semantics...

In my previous server1/server2 example, where no SSLProtocol is
configured in server2, what if SSLProtocol is configured at the server
config (root) level? Should server2 take the value of its base server
or the root one?
The current status is that, without an opt-in/out, it takes the root
value if configured, or the base server's otherwise. Not very
intuitive...

Thoughts?
Reply | Threaded
Open this post in threaded view
|

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

Stefan Eissing
What one wants is that it inherits as before, in that no beginner understands it sort of way. drat.

> Am 25.10.2019 um 16:19 schrieb Yann Ylavic <[hidden email]>:
>
> On Fri, Oct 25, 2019 at 2:48 PM Yann Ylavic <[hidden email]> wrote:
>>
>> Nice idea, I suppose I could make the callback check for
>> ->protocol_set == 0 and not switch in this case.
>> The opt-in may not be that useful then, without it (or "off") the
>> default would be the base server's SSLProtocol, while "on" would be
>> whatever SSLProtocol default is?
>
> By doing that change I realized that mod_ssl did not merge
> ->protocol_set (r1868934), but now I realize what merging means wrt to
> the above semantics...
>
> In my previous server1/server2 example, where no SSLProtocol is
> configured in server2, what if SSLProtocol is configured at the server
> config (root) level? Should server2 take the value of its base server
> or the root one?
> The current status is that, without an opt-in/out, it takes the root
> value if configured, or the base server's otherwise. Not very
> intuitive...
>
> Thoughts?
Reply | Threaded
Open this post in threaded view
|

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

Yann Ylavic
On Fri, Oct 25, 2019 at 5:03 PM Stefan Eissing
<[hidden email]> wrote:
>
> What one wants is that it inherits as before, in that no beginner understands it sort of way. drat.

Exactly, we need an option for the beginners...
I hope you emptied your bottle enough to find a good name :)
Reply | Threaded
Open this post in threaded view
|

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

Alex Hautequest
In reply to this post by Yann Ylavic
IMHO, it *is* intuitive. If you want no default configuration, do not set one by default, otherwise inheritance applies - just as everything else in this daemon.

Or are you all planning to opt in/out every other settings as well, to make a standard "intuitive-driven” configuration approach?

> On Oct 25, 2019, at 10:18 AM, Yann Ylavic <[hidden email]> wrote:
>
> The current status is that, without an opt-in/out, it takes the root
> value if configured, or the base server's otherwise. Not very
> intuitive...

Reply | Threaded
Open this post in threaded view
|

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

Yann Ylavic
On Fri, Oct 25, 2019 at 7:42 PM Alex Hautequest <[hidden email]> wrote:
>
> IMHO, it *is* intuitive. If you want no default configuration, do not set one by default, otherwise inheritance applies - just as everything else in this daemon.

Possibly the inheritance we are talking about here is not the one you
are thinking of, not the usual one in httpd at least.

In current httpd 2.4, the SSLProtocol which applies for name-based
vhosts is the one of the base vhost (the first vhost declared on the
IP:port), because until OpenSSL-1.1.1 there was no way to change the
protocol of a TLS connection, and httpd needs a TLS connection first
to start the handshake, and OpenSSL wants a protocol to create the
connection, chicken and egg...
So the SSLProtocol used to create the TLS connection is the one based
on the IP:port the connection is accepted on, i.e. the base vhost's.

Now we can and want to be able to configure/honor SSLProtocol per
vhost, but the de facto default is the base vhost for SSLProtocol, not
the global/root server where directives usually inherit from.

Suppose a configuration like this:

# global
SSLProtocol TLSv1.3

# base vhost
<VirtualHost *:443>
  ServerName name1
  SSLProtocol TLSv1.2
</VirtualHost>

# non-base vhost
<VirtualHost *:443>
  ServerName name2
  # no SSLProtocol
</VirtualHost>

Which SSLProtocol name2 should apply?
For compatibility with 2.4, that's TLSv1.2, your/one's intuition?
If unintuitve, we need some option to address both 2.4 compatibility
(with some default there) and intuition/POLS (with another default for
next versions).


Regards,
Yann.
Reply | Threaded
Open this post in threaded view
|

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

Alex Hautequest
So the
# global
SSLProtocol TLSv1.3
is an OpenSSL-1.1.1 and onwards feature, where before it was whatever defined on the first <VirtualHost>. Oddly enough, I clearly missed...

Anyway, the fact a standard Apache httpd-ssl.conf configuration file comes with a <VirtualHost _default_:443> key entry should give one a hint this is where the default settings should be applied. If the _default_ VHost is removed/renamed, then there should be no default/inheritance, only if an older OpenSSL is in use; assuming the first <VirtualHost> dictates things for all VHosts is not the right approach to me. So yes, on this scenario, it is unintuitive. I would vote on a clear _default_ VHost for defaults versus reinventing the wheel, but that's only me - and a note on the config stating the SSLProtocol under #global only applies to OpenSSL-1.1.1 and onwards: this can cause confusion/false sense of security if you set things up there and the VHost ends up not making use of these settings.

-----Original Message-----
From: Yann Ylavic <[hidden email]>
Sent: Friday, October 25, 2019 3:32 PM
To: httpd-dev <[hidden email]>
Subject: Re: Opt in(/out?) for TLS protocol per vhost (was: svn commit: r1868645)

On Fri, Oct 25, 2019 at 7:42 PM Alex Hautequest <[hidden email]> wrote:
>
> IMHO, it *is* intuitive. If you want no default configuration, do not set one by default, otherwise inheritance applies - just as everything else in this daemon.

Possibly the inheritance we are talking about here is not the one you are thinking of, not the usual one in httpd at least.

In current httpd 2.4, the SSLProtocol which applies for name-based vhosts is the one of the base vhost (the first vhost declared on the IP:port), because until OpenSSL-1.1.1 there was no way to change the protocol of a TLS connection, and httpd needs a TLS connection first to start the handshake, and OpenSSL wants a protocol to create the connection, chicken and egg...
So the SSLProtocol used to create the TLS connection is the one based on the IP:port the connection is accepted on, i.e. the base vhost's.

Now we can and want to be able to configure/honor SSLProtocol per vhost, but the de facto default is the base vhost for SSLProtocol, not the global/root server where directives usually inherit from.

Suppose a configuration like this:

# global
SSLProtocol TLSv1.3

# base vhost
<VirtualHost *:443>
  ServerName name1
  SSLProtocol TLSv1.2
</VirtualHost>

# non-base vhost
<VirtualHost *:443>
  ServerName name2
  # no SSLProtocol
</VirtualHost>

Which SSLProtocol name2 should apply?
For compatibility with 2.4, that's TLSv1.2, your/one's intuition?
If unintuitve, we need some option to address both 2.4 compatibility (with some default there) and intuition/POLS (with another default for next versions).


Regards,
Yann.

Reply | Threaded
Open this post in threaded view
|

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

Alex Hautequest
As per what should be taken as "default" if no _default_ is given and an old OpenSSL code is in use: we are in 2019, almost 2020. What is the recommended best practice for HTTPS servers? I think SSLv3 and TLSv1.0 are out of the picture, so it is on the dev team to make the judgement call on how secure they want their product out of the box to initialize the SSL subsystem without an explicit _default_ VHost. If your predefined, "hardcoded" settings are not what the admin expects, you leave for them to adjust their standards on each and every of their VHost. But perhaps a few lines of comments on the configuration files can save a lot of lines of code and maintenance down the road.

Just my $.02.

-----Original Message-----
From: [hidden email] <[hidden email]>
Sent: Friday, October 25, 2019 4:32 PM
To: [hidden email]
Subject: RE: Opt in(/out?) for TLS protocol per vhost (was: svn commit: r1868645)

So the
# global
SSLProtocol TLSv1.3
is an OpenSSL-1.1.1 and onwards feature, where before it was whatever defined on the first <VirtualHost>. Oddly enough, I clearly missed...

Anyway, the fact a standard Apache httpd-ssl.conf configuration file comes with a <VirtualHost _default_:443> key entry should give one a hint this is where the default settings should be applied. If the _default_ VHost is removed/renamed, then there should be no default/inheritance, only if an older OpenSSL is in use; assuming the first <VirtualHost> dictates things for all VHosts is not the right approach to me. So yes, on this scenario, it is unintuitive. I would vote on a clear _default_ VHost for defaults versus reinventing the wheel, but that's only me - and a note on the config stating the SSLProtocol under #global only applies to OpenSSL-1.1.1 and onwards: this can cause confusion/false sense of security if you set things up there and the VHost ends up not making use of these settings.

-----Original Message-----
From: Yann Ylavic <[hidden email]>
Sent: Friday, October 25, 2019 3:32 PM
To: httpd-dev <[hidden email]>
Subject: Re: Opt in(/out?) for TLS protocol per vhost (was: svn commit: r1868645)

On Fri, Oct 25, 2019 at 7:42 PM Alex Hautequest <[hidden email]> wrote:
>
> IMHO, it *is* intuitive. If you want no default configuration, do not set one by default, otherwise inheritance applies - just as everything else in this daemon.

Possibly the inheritance we are talking about here is not the one you are thinking of, not the usual one in httpd at least.

In current httpd 2.4, the SSLProtocol which applies for name-based vhosts is the one of the base vhost (the first vhost declared on the IP:port), because until OpenSSL-1.1.1 there was no way to change the protocol of a TLS connection, and httpd needs a TLS connection first to start the handshake, and OpenSSL wants a protocol to create the connection, chicken and egg...
So the SSLProtocol used to create the TLS connection is the one based on the IP:port the connection is accepted on, i.e. the base vhost's.

Now we can and want to be able to configure/honor SSLProtocol per vhost, but the de facto default is the base vhost for SSLProtocol, not the global/root server where directives usually inherit from.

Suppose a configuration like this:

# global
SSLProtocol TLSv1.3

# base vhost
<VirtualHost *:443>
  ServerName name1
  SSLProtocol TLSv1.2
</VirtualHost>

# non-base vhost
<VirtualHost *:443>
  ServerName name2
  # no SSLProtocol
</VirtualHost>

Which SSLProtocol name2 should apply?
For compatibility with 2.4, that's TLSv1.2, your/one's intuition?
If unintuitve, we need some option to address both 2.4 compatibility (with some default there) and intuition/POLS (with another default for next versions).


Regards,
Yann.



12