Re: SSLPolicy code questions/backport review

[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 to client certificate handling were working (I have no working
test setup for that). So, I cleaned up after Joe's review and that's it.

If someone has the energy/interest in backporting any of this, feel free.

-Stefan

In more detail inline:

> 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:
> 
> 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!

Thanks.

> 1. Is there a reason why we need SSLPolicyRec with (name, sc) members 
> rather than having a hash directly of SSLSrvConfigRec *?  The only time 
> ->name is used seems to be when creating the hash in add_policy().  
> [Reading back through commits, I guess this was a legacy of having ->dc 
> in there too]
> 
> 2. Storing the policies hash off pconf userdata seems surprising, is 
> there a reason that's done rather than putting it directly in 
> SSLModConfigRec?

They are also looked up during configuration where SSLModConfigRec
may is not available. See ssl_engine_config.c, line 608

> 3. get_policy_names() seems be only now called with create=1, and hence 
> the same is true for get_policies(), so there are some redundant paths + 
> redundant arguments here which could be removed?

I'll eliminiate the parameter.

> 
> 4. There is a bunch of legacy from the now-removed SSLPolicyDefine 
> AFAICT still included on trunk (not in the 2.4 patch); there is a 
> reference added in the docs in the 2.4 patch though. e.g.
> 
> BOOL ssl_config_global_isfixed(SSLModConfigRec *mc)
> {
> -return mc->bFixed;
> +return mc && mc->bFixed;
> 
> is I think related and in trunk all the ssl_cmd_* handling of mc==NULL 
> case (again not in the backport).

I'll revert that change. It caused crashes when indirectly called during
configuration, as was the case in policy definition, I think.

> 5. Very minor, please don't reformat the code now, but httpd code style 
> has case X: statements lined up with switch rather than indented.

Uhm...ok?

> Regards, Joe

Re: SSLPolicy code questions/backport review

[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:
> 
> 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 than having a hash directly of SSLSrvConfigRec *?  The only time 
> ->name is used seems to be when creating the hash in add_policy().  
> [Reading back through commits, I guess this was a legacy of having ->dc 
> in there too]
> 
> 2. Storing the policies hash off pconf userdata seems surprising, is 
> there a reason that's done rather than putting it directly in 
> SSLModConfigRec?
> 
> 3. get_policy_names() seems be only now called with create=1, and hence 
> the same is true for get_policies(), so there are some redundant paths + 
> redundant arguments here which could be removed?
> 
> 4. There is a bunch of legacy from the now-removed SSLPolicyDefine 
> AFAICT still included on trunk (not in the 2.4 patch); there is a 
> reference added in the docs in the 2.4 patch though. e.g.
> 
> BOOL ssl_config_global_isfixed(SSLModConfigRec *mc)
> {
> -return mc->bFixed;
> +return mc && mc->bFixed;
> 
> is I think related and in trunk all the ssl_cmd_* handling of mc==NULL 
> case (again not in the backport).
> 
> 5. Very minor, please don't reformat the code now, but httpd code style 
> has case X: statements lined up with switch rather than indented.
> 
> Regards, Joe

SSLPolicy code questions/backport review

[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 than having a hash directly of SSLSrvConfigRec *?  The only time 
->name is used seems to be when creating the hash in add_policy().  
[Reading back through commits, I guess this was a legacy of having ->dc 
in there too]

2. Storing the policies hash off pconf userdata seems surprising, is 
there a reason that's done rather than putting it directly in 
SSLModConfigRec?

3. get_policy_names() seems be only now called with create=1, and hence 
the same is true for get_policies(), so there are some redundant paths + 
redundant arguments here which could be removed?

4. There is a bunch of legacy from the now-removed SSLPolicyDefine 
AFAICT still included on trunk (not in the 2.4 patch); there is a 
reference added in the docs in the 2.4 patch though. e.g.

 BOOL ssl_config_global_isfixed(SSLModConfigRec *mc)
 {
-return mc->bFixed;
+return mc && mc->bFixed;

is I think related and in trunk all the ssl_cmd_* handling of mc==NULL 
case (again not in the backport).

5. Very minor, please don't reformat the code now, but httpd code style 
has case X: statements lined up with switch rather than indented.

Regards, Joe

Re: mod_ssl and SSLPolicy

[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 since mod_ssl uses verbs in other 
> config name.)
> 
Looks better that way to me too.

vh

Mads Toftum
-- 
http://flickr.com/photos/q42/

Re: mod_ssl and SSLPolicy

[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
'<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 the next days.


Sounds fine to me. I will also respect your decision if you choose not 
to make this change, as I said elsewhere in the thread.



Cheers,

Stefan


Am 03.12.2017 um 11:16 schrieb Rainer Jung <rainer.j...@kippdata.de>:

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 still have an opportunity to avert user 
confusion.
I request that one of these be renamed. (No, I'm not suggesting specific names. 
I suck at naming things.)

What about keeping the simple SSLPolicy directive (the name of the policy to apply) and 
renaming the container directive from  to .

One other solution would by keeping  and rewnaming the simple 
directive to SSLPolicyApply.

Regards,

Rainer

Re: mod_ssl and SSLPolicy

[Rich Bowen]

On 11/29/2017 04:23 AM, Stefan Eissing wrote:

Having slept a night over this and the mod_md config change request, I say
this leaves me somewhat sour. A request for an unspecified change by
someone important in this project is basically blocking any progress for me.

I am sure that was not your intention, but I feel the current choice of
naming good, because that is why they are there, and I am not convinced
that any alternative I come up with falls on fertile ground. That could
lead to a groundhog day experience with me doing the work and others
saying 'nah!' afterwards.


I'm very sorry, that was not at all my intention. I am merely trying to 
avoid user confusion. If you disagree, just say so, and I'll drop it.




This change is obviously important to you, so please lead a consensus on
how it should be changed. The code change I will then do afterwards if
no one else feels like 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 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 not suggesting specific names. 
I suck at naming things.)

Thanks.

--Rich

Re: mod_ssl and SSLPolicy

[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' -> '<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 the next days.
>
> Cheers,
>
> Stefan
>
>> Am 03.12.2017 um 11:16 schrieb Rainer Jung <rainer.j...@kippdata.de>:
>>
>> 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 still have an opportunity to avert 
>>> user confusion.
>>> I request that one of these be renamed. (No, I'm not suggesting specific 
>>> names. I suck at naming things.)
>>
>> What about keeping the simple SSLPolicy directive (the name of the policy to 
>> apply) and renaming the container directive from  to 
>> .
>>
>> One other solution would by keeping  and rewnaming the simple 
>> directive to SSLPolicyApply.
>>
>> Regards,
>>
>> Rainer
>



-- 
Daniel Ferradal
IT Specialist

email dferradal at gmail.com
linkedin es.linkedin.com/in/danielferradal

Re: mod_ssl and SSLPolicy

[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 the next days.

Cheers,

Stefan

> Am 03.12.2017 um 11:16 schrieb Rainer Jung <rainer.j...@kippdata.de>:
> 
> 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 still have an opportunity to avert 
>> user confusion.
>> I request that one of these be renamed. (No, I'm not suggesting specific 
>> names. I suck at naming things.)
> 
> What about keeping the simple SSLPolicy directive (the name of the policy to 
> apply) and renaming the container directive from  to 
> .
> 
> One other solution would by keeping  and rewnaming the simple 
> directive to SSLPolicyApply.
> 
> Regards,
> 
> Rainer

Re: mod_ssl and SSLPolicy

[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 still have an opportunity to 
avert user confusion.


I request that one of these be renamed. (No, I'm not suggesting specific 
names. I suck at naming things.)


What about keeping the simple SSLPolicy directive (the name of the 
policy to apply) and renaming the container directive from  
to .


One other solution would by keeping  and rewnaming the simple 
directive to SSLPolicyApply.


Regards,

Rainer

Re: mod_ssl and SSLPolicy

[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 work (re other thread).


Regards,
Yann.

Re: mod_ssl and SSLPolicy

[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 sour. A request for an unspecified change by
> someone important in this project is basically blocking any progress for
> me.
>
> I am sure that was not your intention, but I feel the current choice of
> naming good, because that is why they are there, and I am not convinced
> that any alternative I come up with falls on fertile ground. That could
> lead to a groundhog day experience with me doing the work and others
> saying 'nah!' afterwards.
>
> This change is obviously important to you, so please lead a consensus on
> how it should be changed. The code change I will then do afterwards if
> no one else feels like 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 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 not suggesting specific
> names. I suck at naming things.)
> >
> > Thanks.
> >
> > --Rich
>
>

Re: mod_ssl and SSLPolicy

[Stefan Eissing]

Having slept a night over this and the mod_md config change request, I say
this leaves me somewhat sour. A request for an unspecified change by 
someone important in this project is basically blocking any progress for me.

I am sure that was not your intention, but I feel the current choice of
naming good, because that is why they are there, and I am not convinced 
that any alternative I come up with falls on fertile ground. That could
lead to a groundhog day experience with me doing the work and others
saying 'nah!' afterwards.

This change is obviously important to you, so please lead a consensus on
how it should be changed. The code change I will then do afterwards if
no one else feels like 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 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 not suggesting specific 
> names. I suck at naming things.)
> 
> Thanks.
> 
> --Rich

mod_ssl and SSLPolicy

[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 confusion.


I request that one of these be renamed. (No, I'm not suggesting specific 
names. I suck at naming things.)


Thanks.

--Rich

Re: SSLPolicy

[Stefan Eissing]

> Am 14.08.2017 um 17:14 schrieb Eric Covener <cove...@gmail.com>:
> 
>> 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.

This is now addressed in v3 (attached below): I 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": "off", 
"SSLProtocol": "+TLSv1.2 +TLSv1.1 +TLSv1.0", 
"SSLCipherSuite": 
"ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS",
 
"SSLSessionTickets": "off", 
"SSLProxyProtocol": "+TLSv1.2 +TLSv1.1 +TLSv1.0", 
"SSLProxyCipherSuite": 
"ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS",
 
"SSLProxyVerify": "require"
  }, 
  "modern": {
"SSLCompression": "off", 
"SSLProtocol": "+TLSv1.2", 
"SSLCipherSuite": 
"ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
 
"SSLSessionTickets": "off", 
"SSLProxyProtocol": "+TLSv1.2", 
"SSLProxyCipherSuite": 
"ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256",
 
"SSLProxyVerify": "require"
  }, 
  "old": {
"SSLCompression": "off", 
"SSLProtocol": "all", 
"SSLCipherSuite": 
"ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:HIGH:SEED:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!RSAPSK:!aDH:!aECDH:!EDH-DSS-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA:!SRP",
 
"SSLSessionTickets": "off", 
"SSLProxyProtocol": "all", 
"SSLProxyCipherSuite": 
"ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DE

Re: SSLPolicy

[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 mean if someone wants to configure TLSv1.3 for their server?

Do I read this correctly that we need to make a new release first before
someone can enable it?


-Stefan

> Am 14.08.2017 um 18:56 schrieb 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 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 toolkit releases?
> 
> Well, the protocol defs do not exclude anything new. So TLS1.3 will just be 
> "on" where available. 
> 
>> It seems like over time there are a lot of confusion with compile-time
>> vs. runtime openssl, forks, etc that either push towards "modern"
>> being ambiguous for a user or to have lots of different permutations
>> defined.
> 
> That is rather the description of the state SSL configs is in now, is it not? 
> Apart from the few who really know everyone copies sth from somewhere. 
> 
> And they can continue to do so. We take nothing away. We just offer them, 
> hopefully, an easier way to define what they like. 
> 
> Plus some predefined policies for people that just want to use sth we offer. 
> The rate of change should be very low, I think.
> 
> If a Mom server goes https: it is just a bit easier to make it work with 
> modern browsers. 
>> 
>> -- 
>> Eric Covener
>> cove...@gmail.com
> 

Re: SSLPolicy

[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 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 toolkit releases?

Well, the protocol defs do not exclude anything new. So TLS1.3 will just be 
"on" where available. 

> It seems like over time there are a lot of confusion with compile-time
> vs. runtime openssl, forks, etc that either push towards "modern"
> being ambiguous for a user or to have lots of different permutations
> defined.

That is rather the description of the state SSL configs is in now, is it not? 
Apart from the few who really know everyone copies sth from somewhere. 

And they can continue to do so. We take nothing away. We just offer them, 
hopefully, an easier way to define what they like. 

Plus some predefined policies for people that just want to use sth we offer. 
The rate of change should be very low, I think.

If a Mom server goes https: it is just a bit easier to make it work with 
modern browsers. 
> 
> -- 
> Eric Covener
> cove...@gmail.com

Re: SSLPolicy

[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 toolkit releases?
It seems like over time there are a lot of confusion with compile-time
vs. runtime openssl, forks, etc that either push towards "modern"
being ambiguous for a user or to have lots of different permutations
defined.

-- 
Eric Covener
cove...@gmail.com

SSLPolicy

[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
- SSLProxyPolicymerge the proxy parts of the policy into the current 
server config. local directives will override

There are atm 3 predefined policies: modern, intermediate, old (from 
https://wiki.mozilla.org/Security/Server_Side_TLS)

In order to apply them on TLS connections to the client, you configure

  SSLPolicy modern

in your server config or in a specific vhost. To affect the backend proxy 
connections, you may add:

  SSLProxyPolicy intermediate

All settings beside a policy apply as usual. They do override policy values. 
The order does not matter:

  SSLPolicy modern
  SSLProtocol SSLv3

is the same as

  SSLProtocol SSLv3
  SSLPolicy modern

When you define multiple policy uses in the same server, they are merged in the 
reverse order 
(or override each other in document order, e.g. last one wins):

  SSLPolicy modern
  SSLPolicy intermediate

will give you "intermediate" security settings, while

  SSLPolicy intermediate
  SSLPolicy modern

will give you "modern" ones.

You can override policies, so if someone wants to "hotfix" a policy, she can 
write:


  SSLPolicy modern
  SSLCipherSuite "VERYHOTNEWONE"


or you expand a policy:


  SSLPolicy modern
  SSLEngine on


I hope this looks attractive to you. All bugs are mine. Let me know what you 
think.

Cheers,

-Stefan



ssl_policy_v2.diff
Description: Binary data

Re: SSLPolicy

[Stefan Eissing]

> Am 05.08.2017 um 13:28 schrieb Gillis J. de Nijs <gil...@jink.net>:
> 
> When you use Let's Encrypt, the default is to include 
> /etc/letsencrypt/options-ssl-apache.conf in your config.  That's (presumably) 
> updated whenever you update the certbot package.  Similarly, I suppose you 
> can just put your own SSL settings in a file that you include.  I was trying 
> some settings, so I have /etc/apache2/ssl/cipherlist-strong.conf and 
> /etc/apache2/ssl/mozilla-modern.conf for example.  But I don't think this 
> allows for merging of policies.

As you might know, I am working on getting Let's Encrypt certificates into 
Apache natively. So, I am looking for ways to provide easy SSL configurations 
for people that ship with Apache (the configs, not the people). Without 
affecting any existing configs and without taking anything away from operators, 
of course.
 
-Stefan

> On Sat, Aug 5, 2017 at 2:17 AM, Daniel Ruggeri <drugg...@primary.net> wrote:
> If I extrapolate on the idea of what Nick is saying, it sounds like it could 
> be a proposal to simply define these SSL policies in a macro. Personally, I 
> prefer that approach over adding another set of directives (but it's a 
> preference, not an opposition). The downside is that mod_macro would need to 
> be loaded to take advantage of the macros we define. Surely some autoconf 
> magics could be used that say 'if mod_macro and mod_ssl are compiled, render 
> 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: 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 code
> 
> my 2c: Stefan's point is to simplify the management of things that have been 
> done up to now using workarounds and elegant hacks:
>  
> On 04-08-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 error prone.
> B. SSLPolicy definitions can be updated by us or by distributions, since the
> config defining the policies need not be edited by the user, e.g. can be
> replaced in an update. This way, a broken cipher/protocol can be updated
> away in policies we/distributions define. This should help increase 
> security
> of https on the internet.
> 
> 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.
> 
> Luca 
> 

Re: SSLPolicy

[Stefan Eissing]

> Am 04.08.2017 um 23:28 schrieb William A Rowe Jr <wr...@rowe-clan.net>:
> 
> On Fri, Aug 4, 2017 at 4:26 AM, Stefan Eissing
> <stefan.eiss...@greenbytes.de> 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 already defined policies that either follow a public
>>   definition (like the Mozilla security classes) or express our idea of
>>   how configuration should look like.
> 
> I read this aspect at this as more of a weakness than a benefit.
> 
> OpenSSL is more likely to be promptly updated by our users than httpd
> itself. Where ever httpd is overriding OpenSSL preferences, we will
> simply be prolonging the use 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 a matter of SSLPolicy or not, but how one uses SSLCipherSuite,
inside or outside SSLPolicy. 

If someone configures nowadays an explicit cipher list (and not something 
like HIGH, MEDIUM), she does also not benefit from any OpenSSL updates in 
this regards.

I talked with the OpenSSL team during the HTTP/2 development, why they
do not take the Browser cipher requirements into their keyword definitions.
At that time, the answer basically was that they see HTTP as just one
layer up (among others) with which they are not directly concerned about 
and, if one wanted, one could add such definitions into the ssl config 
files.

So, not their problem. 

Yikes! Let's check what people search for secure httpd ssl configs
actually might find (this got a bit long, but bear with me):


A duckduckgo search for "httpd secure ssl config" has as first hit for me
https://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-httpd-secure-server.html
which talks about how to get a certificate and install that into httpd but
says *nothing* about protocols or ciphers. The "additional resources" links
to our website (good) and to http://www.modssl.org which says:
"Current Version: mod_ssl 2.8.31 for Apache 1.3.41"

This might mean
* duckduckgo thinks I am old fashioned
* there are no better descriptions on the web (not true, I know)
* many sites refer to this centos doc and many people use it

DoubleYikes!

Back to our site: 
http://httpd.apache.org/docs/current/en/ssl/ssl_howto.html#onlystrong
Our "only strong" recommendation for good performance is:

SSLCipherSuite RC4-SHA:AES128-SHA:HIGH:!aNULL:!MD5

Now, I am not the ultimate expert on this, but as I read Ivan Ristić this
is not really recommended nowadays any more. (Here is SSLLabs doc on
SSL config advice 
https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices
which is generic for all servers).

Then, more interesting, people might stumble on the "Mozilla SSL Configuration 
Generator"
at https://mozilla.github.io/server-side-tls/ssl-config-generator/ 
which gives a complete Apache configuration where you select version and
your security policy (ahem) and people will get:

SSLCipherSuite  
ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS

I would guess that this is what people *copy* into their server configs
and which then will get never, or only sporadically updated. 

TripleYikes!

So, the question is: what do we want this generator actually to say?
My idea is that when people select Apache httpd 2.4.28, they will see

SSLPolicy modern

instead. And I do not see how that can work with mod_macro as well as
with a mod_ssl config directive. But I am listening.

Thanks for the patience,

-Stefan

Re: SSLPolicy

[Gillis J. de Nijs]

When you use Let's Encrypt, the default is to
include /etc/letsencrypt/options-ssl-apache.conf in your config.  That's
(presumably) updated whenever you update the certbot package.  Similarly, I
suppose you can just put your own SSL settings in a file that you include.
I was trying some settings, so I have
/etc/apache2/ssl/cipherlist-strong.conf and
/etc/apache2/ssl/mozilla-modern.conf for example.  But I don't think this
allows for merging of policies.

On Sat, Aug 5, 2017 at 2:17 AM, Daniel Ruggeri <drugg...@primary.net> wrote:

> If I extrapolate on the idea of what Nick is saying, it sounds like it
> could be a proposal to simply define these SSL policies in a macro.
> Personally, I prefer that approach over adding another set of directives
> (but it's a preference, not an opposition). The downside is that mod_macro
> would need to be loaded to take advantage of the macros we define. Surely
> some autoconf magics could be used that say 'if mod_macro and mod_ssl are
> compiled, render 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: 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 code
>
>
> my 2c: Stefan's point is to simplify the management of things that have
> been done up to now using workarounds and elegant hacks:
>
>
>> On 04-08-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 error prone.
>>> B. SSLPolicy definitions can be updated by us or by distributions, since
>>> the
>>> config defining the policies need not be edited by the user, e.g.
>>> can be
>>> replaced in an update. This way, a broken cipher/protocol can be
>>> updated
>>> away in policies we/distributions define. This should help increase
>>> security
>>> of https on the internet.
>>>
>>
> 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.
>
> Luca
>

Re: SSLPolicy

[Daniel Ruggeri]

If I extrapolate on the idea of what Nick is saying, it sounds like it could be 
a proposal to simply define these SSL policies in a macro. Personally, I prefer 
that approach over adding another set of directives (but it's a preference, not 
an opposition). The downside is that mod_macro would need to be loaded to take 
advantage of the macros we define. Surely some autoconf magics could be used 
that say 'if mod_macro and mod_ssl are compiled, render this set of macros in 
the ssl section.'
-- 
Daniel Ruggeri


 Original Message 
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: 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 code


my 2c: Stefan's point is to simplify the management of things that have
been done up to now using workarounds and elegant hacks:


> On 04-08-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 error prone.
>> B. SSLPolicy definitions can be updated by us or by distributions, since
>> the
>> config defining the policies need not be edited by the user, e.g. can
>> be
>> replaced in an update. This way, a broken cipher/protocol can be
>> updated
>> away in policies we/distributions define. This should help increase
>> security
>> of https on the internet.
>>
>
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.

Luca

Re: SSLPolicy

[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 already defined policies that either follow a public
>definition (like the Mozilla security classes) or express our idea of
>how configuration should look like.

I read this aspect at this as more of a weakness than a benefit.

OpenSSL is more likely to be promptly updated by our users than httpd
itself. Where ever httpd is overriding OpenSSL preferences, we will
simply be prolonging the use 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.

Re: SSLPolicy

[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 sugar stuff -- 
grouping related directives into meta-directives -- I think it'd be nice 
to extend mod_macro to the point that we can build those meta-directives 
using its functionality directly, and then fold that into core.


For now, though, I'm ++1 to Stefan's concept. We can see how much 
extra/duplicate code there is and try to refactor it up as we go.


--Jacob

Re: SSLPolicy

[Luca Toscano]

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 code


my 2c: Stefan's point is to simplify the management of things that have
been done up to now using workarounds and elegant hacks:


> On 04-08-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 error prone.
>> B. SSLPolicy definitions can be updated by us or by distributions, since
>> the
>> config defining the policies need not be edited by the user, e.g. can
>> be
>> replaced in an update. This way, a broken cipher/protocol can be
>> updated
>> away in policies we/distributions define. This should help increase
>> security
>> of https on the internet.
>>
>
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.

Luca

Re: SSLPolicy

[Nick Gearls]

This can be done using mod_macro without any additional code

On 04-08-2017 11:26, 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
1. Give a set of SSL directives a name and allow the user to apply that name
in several virtual hosts.
2. Provide a set of already defined policies that either follow a public
definition (like the Mozilla security classes) or express our idea of
how configuration should look like.
3. Allow 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 can be updated by us or by distributions, since the
config defining the policies need not be edited by the user, e.g. can be
replaced in an update. This way, a broken cipher/protocol can be updated
away in policies we/distributions define. This should help increase security
of https on the internet.

The proposal:

Introduce two new directives "SSLPolicy" and "<SSLPolicy":

   
 SSLProtocol  ...
 SSLCipherSuite   ...
 ...
   

defines a set of SSL configuration directives (basically all non-proxy that are
applicable in vhosts). This can only be done in the global context. Names
may not be overwritten.

   SSLPolicy name

applies the policy in the given context (server/vhost).


Implementation:
Changes should basically only affect ssl_kernel_config.c. Config commands will
add a check if they are inside a "<SSLPolicy" selection and use a 
SSLSrvConfigRec*
for the section.
The config command for "SSLPolicy" will look up the SSLSrvConfigRec* of "name" 
in
a global hash and do a merge of that record with the current server one. This
should use the policy as base for the merge, so local directives can override a 
policy.

Compatibility:
Existing installations are unaffected by this addition.

-Stefan

SSLPolicy

[Stefan Eissing]

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
1. Give a set of SSL directives a name and allow the user to apply that name
   in several virtual hosts.
2. Provide a set of already defined policies that either follow a public
   definition (like the Mozilla security classes) or express our idea of
   how configuration should look like.
3. Allow 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 can be updated by us or by distributions, since the
   config defining the policies need not be edited by the user, e.g. can be
   replaced in an update. This way, a broken cipher/protocol can be updated
   away in policies we/distributions define. This should help increase security
   of https on the internet.

The proposal:

Introduce two new directives "SSLPolicy" and "<SSLPolicy":

  
SSLProtocol  ...
SSLCipherSuite   ...
...
  

defines a set of SSL configuration directives (basically all non-proxy that are
applicable in vhosts). This can only be done in the global context. Names
may not be overwritten.

  SSLPolicy name

applies the policy in the given context (server/vhost). 


Implementation:
Changes should basically only affect ssl_kernel_config.c. Config commands will
add a check if they are inside a "<SSLPolicy" selection and use a 
SSLSrvConfigRec*
for the section.
The config command for "SSLPolicy" will look up the SSLSrvConfigRec* of "name" 
in
a global hash and do a merge of that record with the current server one. This 
should use the policy as base for the merge, so local directives can override a 
policy.

Compatibility:
Existing installations are unaffected by this addition.

-Stefan