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
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:
>
>
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
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
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
'&
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
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
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
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
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
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
> 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
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
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": &
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
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
> 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
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
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
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
.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
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
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
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
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
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
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
27 matches
Mail list logo