Re: SSLPolicy code questions/backport review

2018-06-06 Thread Stefan Eissing
Since parts of the changes in mod_ssl for SSLPolicy have now been affected by changes for TLSv1.3 and there has not been real interest in backporting SSLPolicy this year anyway, I withdraw the proposal. The TLSv1.3 changes are not fit for backport since I was unable to verify that my fixes

Re: SSLPolicy code questions/backport review

2018-06-04 Thread Stefan Eissing
Thanks for the review! I will take this and clean up the code, mod_ssl certainly deserves it. > Am 23.05.2018 um 09:51 schrieb Joe Orton : > > Easier to do here than dump in STATUS; looking at reviewing the 2.4.x > backport: > >

SSLPolicy code questions/backport review

2018-05-30 Thread Joe Orton
Easier to do here than dump in STATUS; looking at reviewing the 2.4.x backport: https://svn.apache.org/repos/asf/httpd/httpd/patches/2.4.x/ssl-policy.patch 0. Overall looks good, I like the way this has been done! 1. Is there a reason why we need SSLPolicyRec with (name, sc) members rather

Re: mod_ssl and SSLPolicy

2017-12-04 Thread Mads Toftum
On Mon, Dec 04, 2017 at 01:39:08PM +0100, Stefan Eissing wrote: > Thanks for all the input. What I see is consensus about the SSLPolicy change: > > 'SSLPolicy' -> stay as is > '<SSLPolicy' -> '<SSLPolicyDefine' > > (I prefer the verb above the noun here sin

Re: mod_ssl and SSLPolicy

2017-12-04 Thread Rich Bowen
On 12/04/2017 07:56 AM, Daniel wrote: Sounds like a good change if anyone asks me. :) 2017-12-04 13:39 GMT+01:00 Stefan Eissing <stefan.eiss...@greenbytes.de>: Thanks for all the input. What I see is consensus about the SSLPolicy change: 'SSLPolicy' -> stay as is '&

Re: mod_ssl and SSLPolicy

2017-12-04 Thread Rich Bowen
it. Cheers, Stefan Am 28.11.2017 um 16:51 schrieb Rich Bowen <rbo...@rcbowen.com>: As one of the folks that answers questions on IRC, I would like to object to the existence of SSLPolicy and . I think it's unwise to have two directives with the same name, for reasons of end-user s

Re: mod_ssl and SSLPolicy

2017-12-04 Thread Daniel
Sounds like a good change if anyone asks me. :) 2017-12-04 13:39 GMT+01:00 Stefan Eissing <stefan.eiss...@greenbytes.de>: > Thanks for all the input. What I see is consensus about the SSLPolicy change: > > 'SSLPolicy' -> stay as is > '<SSLPolicy' -> '<SSLPolicy

Re: mod_ssl and SSLPolicy

2017-12-04 Thread Stefan Eissing
Thanks for all the input. What I see is consensus about the SSLPolicy change: 'SSLPolicy' -> stay as is '<SSLPolicy' -> '<SSLPolicyDefine' (I prefer the verb above the noun here since mod_ssl uses verbs in other config name.) If no one objects, I will go for this change in t

Re: mod_ssl and SSLPolicy

2017-12-03 Thread Rainer Jung
Am 28.11.2017 um 16:51 schrieb Rich Bowen: As one of the folks that answers questions on IRC, I would like to object to the existence of SSLPolicy and . I think it's unwise to have two directives with the same name, for reasons of end-user support. As long as it's still only in trunk, we

Re: mod_ssl and SSLPolicy

2017-11-29 Thread Yann Ylavic
On Wed, Nov 29, 2017 at 12:17 PM, Gillis J. de Nijs <gil...@jink.net> wrote: > Could it be as simple as changing to and > leaving SSLPolicy as it is? This would work for me, I'll be quite consensual anyway (e.g. I'm fine with SSLPolicy for both too). / ManagedDomain could also wo

Re: mod_ssl and SSLPolicy

2017-11-29 Thread Gillis J. de Nijs
Could it be as simple as changing to and leaving SSLPolicy as it is? Cheers, Gillis On Wed, Nov 29, 2017 at 10:23 AM, Stefan Eissing < stefan.eiss...@greenbytes.de> wrote: > Having slept a night over this and the mod_md config change request, I say > this leaves me somewhat sou

Re: mod_ssl and SSLPolicy

2017-11-29 Thread Stefan Eissing
> the existence of SSLPolicy and . I think it's unwise to have two > directives with the same name, for reasons of end-user support. > > As long as it's still only in trunk, we still have an opportunity to avert > user confusion. > > I request that one of these be renamed. (No, I'm

mod_ssl and SSLPolicy

2017-11-28 Thread Rich Bowen
As one of the folks that answers questions on IRC, I would like to object to the existence of SSLPolicy and . I think it's unwise to have two directives with the same name, for reasons of end-user support. As long as it's still only in trunk, we still have an opportunity to avert user

Re: SSLPolicy

2017-08-15 Thread Stefan Eissing
added DUMP code that lists all dfined SSLPolicy records (it could dump basically all srv and dir configs, if one so desires). Invoke with > httpd -t -D DUMP_SSL_POLICIES On an empty, patched server, this gives: SSLPolicies: { "intermediate": { "SSLCompression": &

Re: SSLPolicy

2017-08-15 Thread Stefan Eissing
Woah! I just read ssl_init_ctx_protocol()...that's... quite something. So, basically, what our SSLProtocol does is - select the proper _new() variant for the SSL_CTX_new() - disable known protocol versions not set in our bitmask - set the max protocol version based on our bitmask What does that

Re: SSLPolicy

2017-08-14 Thread Stefan Eissing
Am 14.08.2017 um 17:14 schrieb Eric Covener : >> I hope this looks attractive to you. All bugs are mine. Let me know what you >> think. > > It looks neat. I think accessible doc will be key. yes. I was thinking of generating, but had no bright idea so far. > But for the

Re: SSLPolicy

2017-08-14 Thread Eric Covener
> I hope this looks attractive to you. All bugs are mine. Let me know what you > think. It looks neat. I think accessible doc will be key. But for the sake of discussion, what will we do / what will distributors do when say TLS1.3 or some esoteric part of it is only available in some SSL

SSLPolicy

2017-08-14 Thread Stefan Eissing
Here is my proposal for more semantic sugar. It defines 3 new SSL* config directives: - to define a set of SSL* directives under a name - SSLPolicy merge the non-proxy parts of the policy into the current server config. local directives will override - SSLProxyPolicy

Re: SSLPolicy

2017-08-05 Thread Stefan Eissing
this set of macros in the ssl section.' > -- > Daniel Ruggeri > > From: Luca Toscano <toscano.l...@gmail.com> > Sent: August 4, 2017 6:38:16 AM CDT > To: Apache HTTP Server Development List <dev@httpd.apache.org>, > nickgea...@gmail.com > Subject: Re: SSL

Re: SSLPolicy

2017-08-05 Thread Stefan Eissing
of discouraged policy. > > If a cipher is changed upstream in OpenSSL from HIGH to MEDIUM > strength (or dropped entirely), due to the discovery of a weakness in > the cipher, I believe it is important for httpd to pick up on that signal > without upgrade or recompilation. That is not

Re: SSLPolicy

2017-08-05 Thread Gillis J. de Nijs
.com> > *Sent:* August 4, 2017 6:38:16 AM CDT > *To:* Apache HTTP Server Development List <dev@httpd.apache.org>, > nickgea...@gmail.com > *Subject:* Re: SSLPolicy > > Hi Nick, > > 2017-08-04 13:06 GMT+02:00 Nick Gearls <nickgea...@gmail.com>: > >> This can b

Re: SSLPolicy

2017-08-04 Thread Daniel Ruggeri
com> Sent: August 4, 2017 6:38:16 AM CDT To: Apache HTTP Server Development List <dev@httpd.apache.org>, nickgea...@gmail.com Subject: Re: SSLPolicy Hi Nick, 2017-08-04 13:06 GMT+02:00 Nick Gearls <nickgea...@gmail.com>: > This can be done using mod_macro without any additional c

Re: SSLPolicy

2017-08-04 Thread William A Rowe Jr
On Fri, Aug 4, 2017 at 4:26 AM, Stefan Eissing wrote: > I talked about some kind of SSL Policy definition in httpd's configuration > in the past and am now about to get serious about it. Here is what I wan to > do: > > Recap: the general idea is > 2. Provide a set of

Re: SSLPolicy

2017-08-04 Thread Jacob Champion
On 08/04/2017 04:38 AM, Luca Toscano wrote: I agree that mod_macro is flexible enough to improve the reusability of httpd's configuration, but I don't think that the goals that Stefan has in mind are satisfiable with your proposed solution. If we find ourselves doing more of this syntactic

Re: SSLPolicy

2017-08-04 Thread Luca Toscano
8-2017 11:26, Stefan Eissing wrote: >> >> >> The Benefits I'd like to achieve with this: >> A. A name makes it easier to talk about used/recommended configurations. >> It >> also makes it easy for admins to apply a known set of policies. It is >> less e

Re: SSLPolicy

2017-08-04 Thread Nick Gearls
distributions/users to define their own policy sets, of course. The Benefits I'd like to achieve with this: A. A name makes it easier to talk about used/recommended configurations. It also makes it easy for admins to apply a known set of policies. It is less error prone. B. SSLPolicy definitions

SSLPolicy

2017-08-04 Thread Stefan Eissing
with this: A. A name makes it easier to talk about used/recommended configurations. It also makes it easy for admins to apply a known set of policies. It is less error prone. B. SSLPolicy definitions can be updated by us or by distributions, since the config defining the policies need not be edited