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
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
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
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 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 :)
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
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
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,
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
> 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
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
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
On Fri, Oct 25, 2019 at 1:58 PM Jim Jagielski wrote:
>
> I'm fine w/ whatever we all decide.
+1
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
> 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
> 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?
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
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
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
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
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,
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
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
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
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
25 matches
Mail list logo
