RE: Opt in(/out?) for TLS protocol per vhost (was: svn commit: r1868645)
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: hqu...@hquest.pro.br Sent: Friday, October 25, 2019 4:32 PM To: dev@httpd.apache.org 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 . Oddly enough, I clearly missed... Anyway, the fact a standard Apache httpd-ssl.conf configuration file comes with a 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 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 Sent: Friday, October 25, 2019 3:32 PM To: httpd-dev 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 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 ServerName name1 SSLProtocol TLSv1.2 # non-base vhost ServerName name2 # no SSLProtocol 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.
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 . Oddly enough, I clearly missed... Anyway, the fact a standard Apache httpd-ssl.conf configuration file comes with a 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 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 Sent: Friday, October 25, 2019 3:32 PM To: httpd-dev 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 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 ServerName name1 SSLProtocol TLSv1.2 # non-base vhost ServerName name2 # no SSLProtocol 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.
Re: Opt in(/out?) for TLS protocol per vhost (was: svn commit: r1868645)
On Fri, Oct 25, 2019 at 7:42 PM Alex Hautequest 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 ServerName name1 SSLProtocol TLSv1.2 # non-base vhost ServerName name2 # no SSLProtocol 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.
Re: Opt in(/out?) for TLS protocol per vhost (was: svn commit: r1868645)
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 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...
Re: Opt in(/out?) for TLS protocol per vhost (was: svn commit: r1868645)
On Fri, Oct 25, 2019 at 5:03 PM Stefan Eissing 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 :)
Re: Opt in(/out?) for TLS protocol per vhost (was: svn commit: r1868645)
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 : > > On Fri, Oct 25, 2019 at 2:48 PM Yann Ylavic 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?
Re: Opt in(/out?) for TLS protocol per vhost (was: svn commit: r1868645)
On Fri, Oct 25, 2019 at 2:48 PM Yann Ylavic 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?
mod_md v2.2.1 backport
I just backported the current mod_md (v.2.2.1) to 2.4.x, including the updated xml documentation. There are some beautification issues raised by Steffen outstanding which I'll look at in the coming weeks, but otherwise this seems to be a stable thing. It has stewed in github for some time now, with Steffen being very busy in using it. Thanks for that. I am also running it on our greenbytes server with some domains and the ocsp handling is without hiccups. Of course, these all go against the Lets Encrypt / Akamai responders, so coverage is limited (and Akamai needed to fix their servers). Who knows what else we'll find, but seems we just need to move forward to find this out, won't we? Cheers, Stefan
Re: Opt in(/out?) for TLS protocol per vhost (was: svn commit: r1868645)
On Fri, Oct 25, 2019 at 3:16 PM Stefan Eissing wrote: > > > Am 25.10.2019 um 14:48 schrieb Yann Ylavic : > > > > On Fri, Oct 25, 2019 at 2:08 PM Eric Covener 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
Re: Opt in(/out?) for TLS protocol per vhost (was: svn commit: r1868645)
> Am 25.10.2019 um 14:48 schrieb Yann Ylavic : > > On Fri, Oct 25, 2019 at 2:08 PM Eric Covener 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
Re: Opt in(/out?) for TLS protocol per vhost (was: svn commit: r1868645)
On Fri, Oct 25, 2019 at 2:08 PM Eric Covener 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.
Re: Opt in(/out?) for TLS protocol per vhost (was: svn commit: r1868645)
On Fri, Oct 25, 2019 at 7:59 AM Yann Ylavic wrote: > > On Fri, Oct 25, 2019 at 1:21 PM Eric Covener 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): > > > ServerName name1 > SSLProtocol TLSv1.2 > > > > ServerName name2 > # no SSLProtocol > > > 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 cove...@gmail.com
Re: Time for httpd 2.6.x?
On Fri, Oct 25, 2019 at 1:58 PM Jim Jagielski wrote: > > I'm fine w/ whatever we all decide. +1
Re: Opt in(/out?) for TLS protocol per vhost (was: svn commit: r1868645)
On Fri, Oct 25, 2019 at 1:21 PM Eric Covener 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): ServerName name1 SSLProtocol TLSv1.2 ServerName name2 # no SSLProtocol 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).
Re: Time for httpd 2.6.x?
> On Oct 25, 2019, at 6:59 AM, Graham Leggett wrote: > > On 24 Oct 2019, at 14:14, Jim Jagielski wrote: > >> Going from 2.4.x to 2.6.x implies an ABI break... Up to now, all backports >> from trunk have maintained the 2.4.x ABI backwards compatibility. >> >> So I would propose that if we do the below, which I am fine w/ BTW, that the >> 1st issues we tackle after branching 2.6.x from httpd-24 are all the ABI >> changes. >> >> Yes, there is a lot of cool stuff in trunk. There is also a lot of, IMO, >> untested and wonky stuff that I would be somewhat worried about releasing... >> So that's why I like basing 2.6.x off of 2.4.x rather than trunk. > > I would rather we stick to our existing practise of branching off trunk, then > evaluating what we want in 2.6 and explicitly removing what we don't want. > > This is what we did when 2.4 came out, and it worked well. > I'm fine w/ whatever we all decide.
Re: Opt in(/out?) for TLS protocol per vhost (was: svn commit: r1868645)
> 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.
Re: Opt in(/out?) for TLS protocol per vhost (was: svn commit: r1868645)
On Fri, Oct 25, 2019 at 4:09 AM Yann Ylavic wrote: > > On Fri, Oct 25, 2019 at 9:56 AM Stefan Eissing > 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 cove...@gmail.com
Re: Time for httpd 2.6.x?
On 24 Oct 2019, at 14:14, Jim Jagielski wrote: > Going from 2.4.x to 2.6.x implies an ABI break... Up to now, all backports > from trunk have maintained the 2.4.x ABI backwards compatibility. > > So I would propose that if we do the below, which I am fine w/ BTW, that the > 1st issues we tackle after branching 2.6.x from httpd-24 are all the ABI > changes. > > Yes, there is a lot of cool stuff in trunk. There is also a lot of, IMO, > untested and wonky stuff that I would be somewhat worried about releasing... > So that's why I like basing 2.6.x off of 2.4.x rather than trunk. I would rather we stick to our existing practise of branching off trunk, then evaluating what we want in 2.6 and explicitly removing what we don't want. This is what we did when 2.4 came out, and it worked well. > FTR: Both APR and httpd have similar versioning guidelines (semver)... I > don't see the attraction or need to revisit it. I don’t want us reinventing any wheels. The goal here is to get v2.6 out the door, not reinvent our long established processes from scratch, particularly when the work on the processes sucks time out of work on httpd’s codebase itself. Regards, Graham — smime.p7s Description: S/MIME cryptographic signature
Re: Opt in(/out?) for TLS protocol per vhost (was: svn commit: r1868645)
Sure thing! Wine usually disinhibits discussions :) On Fri, Oct 25, 2019 at 11:45 AM Stefan Eissing 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 : > > > > On Fri, Oct 25, 2019 at 9:56 AM Stefan Eissing > > 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 : > >>> > >>> On Sun, Oct 20, 2019 at 12:50 PM wrote: > > Author: ylavic > Date: Sun Oct 20 10:50:33 2019 > New Revision: 1868645 > > URL: http://svn.apache.org/viewvc?rev=1868645=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. > >> >
Re: Time for httpd 2.6.x?
On Wed, Oct 23, 2019 at 11:06 AM Stefan Eissing wrote: > > As I said in the past, my idea would be to: > - trunk -> trunk-old, > - copy 2.4.x -> trunk > - any feature to bring from trunk-old to the new trunk needs a champion, e.g. > someone who does the work (porting and test cases) I'm not sure, possibly it would be easier to remove/restore from/to trunk than backport to 2.6.x. I think most things are in pretty good shape in trunk, core things at least. If we were to merge the missing/interesting bits in a 2.6.x-copy-of-2.4.x, it could be a mess to find all the commits in trunk for each feature. (Say something /me did, as you very well know it's very likely to be spread over multiple commits and back and forth in time :) ) > > To some, that looks like we do not honour past work from people (that was one > of the arguments brought forward last time). If, due to the above difficulty for finding all the relevant bits to backport, it ends up being large replacement of code (nay whole files) with no real merge, I think that's a point though. Basing 2.6.x off trunk would preserve history on the things we want to keep and maintain, and possibly would be easier to start with (let's discuss that!), so best of both worlds? > But it is not only about honour of devs, but also about the sweat and tears > of the maintainers during 2.6.x releases. If a feature does not find someone > to merge from one branch to another, how could we support this feature in a > release? Agreed. > What do the 5-6 people who handle 99% of all PRs think about this? My feeling is that it's easier to start from trunk, no strong feeling (an intuitive one). So how about: 0. github workflow? meanwhile... 1. compare trunk/2.4.x (inventory) 2. discuss unused/deprecated in trunk to cleanup 3. address STALLED entries in trunk if it's not for compatibily reasons 4. do API/ABI breaking changes in trunk 5. improve trunk w/ things we want in 2.6.x (the real part!) 6. trunk => 2.6.x 7. remove from 2.6.x things not deprecated in 2. but w/ no champion either 8. 2.6.alpha/beta/gamma/rc/whatever 9. fix in trunk and backport to 2.6.x 10. if not good enough goto 8. 11. 2.6.0 12+ usual release cycle ? If in 1. we find that 2.4.x => 2.6.x is easier/better, well just replace 2. with that and drop 6. and 7.
Re: Opt in(/out?) for TLS protocol per vhost (was: svn commit: r1868645)
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 : > > On Fri, Oct 25, 2019 at 9:56 AM Stefan Eissing > 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 : >>> >>> On Sun, Oct 20, 2019 at 12:50 PM wrote: Author: ylavic Date: Sun Oct 20 10:50:33 2019 New Revision: 1868645 URL: http://svn.apache.org/viewvc?rev=1868645=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. >>
Re: Opt in(/out?) for TLS protocol per vhost (was: svn commit: r1868645)
On Fri, Oct 25, 2019 at 9:56 AM Stefan Eissing 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 : > > > > On Sun, Oct 20, 2019 at 12:50 PM wrote: > >> > >> Author: ylavic > >> Date: Sun Oct 20 10:50:33 2019 > >> New Revision: 1868645 > >> > >> URL: http://svn.apache.org/viewvc?rev=1868645=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. >
Re: Opt in(/out?) for TLS protocol per vhost (was: svn commit: r1868645)
On Fri, Oct 25, 2019 at 9:56 AM Stefan Eissing 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.
Re: Opt in(/out?) for TLS protocol per vhost (was: svn commit: r1868645)
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 : > > On Sun, Oct 20, 2019 at 12:50 PM wrote: >> >> Author: ylavic >> Date: Sun Oct 20 10:50:33 2019 >> New Revision: 1868645 >> >> URL: http://svn.apache.org/viewvc?rev=1868645=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.
Opt in(/out?) for TLS protocol per vhost (was: svn commit: r1868645)
On Sun, Oct 20, 2019 at 12:50 PM wrote: > > Author: ylavic > Date: Sun Oct 20 10:50:33 2019 > New Revision: 1868645 > > URL: http://svn.apache.org/viewvc?rev=1868645=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.
