Re: The drive for 2.4.26

[Jan Ehrhardt]

Rainer Jung in gmane.comp.apache.devel (Fri, 21 Apr 2017 00:29:38
+0200):
>Thanks for the analysis. So the following patch on trunk works for me 
>when using OpenSSL 1.0.1e (on Solaris 10):
>
>Index: support/ab.c
>===
>--- support/ab.c(revision 1792155)
>+++ support/ab.c(working copy)
>@@ -2576,8 +2576,6 @@
>  #else
>  #if OPENSSL_VERSION_NUMBER < 0x1010L
>  CRYPTO_malloc_init();
>-#else
>-OPENSSL_malloc_init();
>  #endif
>  #endif
>  SSL_load_error_strings();
>
>
>The same fix should apply for 2.4.x.
>
>In addition I noticed the following glitch:
>
>Index: support/ab.c
>===
>--- support/ab.c(revision 1792155)
>+++ support/ab.c(working copy)
>@@ -2465,14 +2465,14 @@
>  case 'B':
>  myhost = apr_pstrdup(cntxt, opt_arg);
>  break;
>+case 'm':
>+method = CUSTOM_METHOD;
>+method_str[CUSTOM_METHOD] = strdup(opt_arg);
>+break;
>  #ifdef USE_SSL
>  case 'Z':
>  ssl_cipher = strdup(opt_arg);
>  break;
>-case 'm':
>-method = CUSTOM_METHOD;
>-method_str[CUSTOM_METHOD] = strdup(opt_arg);
>-break;
>  case 'f':
>  #if OPENSSL_VERSION_NUMBER < 0x1010L
>  if (strncasecmp(opt_arg, "ALL", 3) == 0) {
>
>
>The "-m" option is independent of SSL use and should be handled outside 
>of "#ifdef USE_SSL".
>
>Will apply some time over the weekend if noone does it before.

Thia fixes abs.exe with OpenSSL 1.1.0e on Windows (VC14 x64). ould you
backport it to the 2.4.x branch?

See https://www.apachelounge.com/viewtopic.php?p=35304#35304 as well.
-- 
Jan

Re: SSL and Usability and Safety

[Issac Goldstand]

On 5/3/2017 4:28 PM, Stefan Eissing wrote:
> 
>> Am 03.05.2017 um 15:22 schrieb Dirk-Willem van Gulik :
>>
>>>
>>> On 3 May 2017, at 15:14, Issac Goldstand  wrote:
>>>
>>> On 5/3/2017 3:59 PM, Dirk-Willem van Gulik wrote:

> On 3 May 2017, at 14:53, Issac Goldstand  > wrote:
>
> On 5/3/2017 12:46 PM, Dirk-Willem van Gulik wrote:
>> On 3 May 2017, at 10:03, Issac Goldstand > > wrote:
>>>
>>> +1 on the idea
>>>
>>> So far I'm -0 about all of the proposed implementations for 2 reasons:
>>>
>>> 1) Mr and Mrs normal (whom are our primary customers in the original
>>> proposal) usually download Apache from their distro or some other
>>> binary.  Their Apache sources are usually not up-to-date, and in the
>>> scenario that a new vulnerability is found it would take ages to
>>> propagate to them, anyway
>>>
>>> 2) For those users who are comfortable building their own source, they
>> ….
>>
>> So how about ‘us’ taking the lead here. 
>
> That's the part I was always +1 on :)
>
>> We, here, simply define ‘one’ setting as the industry best standard -
>> which roughly corresponds to what ssllabs their test would get you an
>> A+ and that pretty much meets or exceeds the various NIST et.al.
>> recommendations for key lengths for the next 5 years. 
>
> The problem is, that we don't know what's going to be good going forward
> five years, and IMHO the best standards are shaped at least equally by
> removing "negatives" often because of high-risk vulnerabilities, as by
> adding new "positives" due to new available ciphers/tools

 Right - so I think there are two things

 1)the general advice of NIST et.al. - summarized nicely at:

 https://www.keylength.com

 which tells us what our `best acceptable’ choises are in any release
 going out and their likely vailidy for the next 5 years.

 And then there is our response to things that become known; such as
 vulnerability - for which we have a proven update proces that is
 dovetailed by us sending mail to announce, the security mailing lists
 and similar outreach.
>>>
>>> Which, IMHO, we can safely expect Mr and Mrs Normal to never see.  Mr
>>> and Mrs normal aren't on the mailing list of most pieces of software,
>>> even if they use them.
>>>
>>> If we truly want to cater to them (and by doing so, do our part in
>>> advocating a safer and more secure internet) then I maintain that we'd
>>> need to do better.
>>
>> Right - but then we are in the land of automatic updates; binary package 
>> fetching and what not ? Or at the very least - pulling down a file over the 
>> internet from ‘us’ that is sufficiently protected yet robust, etc ?
>>
>> That is a whole new land?
> 
> I think there is a step in between. If we make our releases security settings 
> better and users opt-in, we can with every release improve that. Nothing to 
> change in the processes here.
> 
> In case our settings prove to have a fault, there is always the possibility 
> for 
> a) ship a new release
> b) specify an immediate workaround by using the existing SSL* directives 
> appropriately

But we already (potentially) do that with the maintained
conf/extra/httpd-ssl.conf don't we?  How are all of the ideas we've been
floating more than just sugar coating for the recommendations we already
maintain there?

> 
> -Stefan
> 

Re: SSL and Usability and Safety

[Issac Goldstand]

On 5/3/2017 4:22 PM, Dirk-Willem van Gulik wrote:
> 
>> On 3 May 2017, at 15:14, Issac Goldstand  wrote:
>>
>> On 5/3/2017 3:59 PM, Dirk-Willem van Gulik wrote:
>>>
 On 3 May 2017, at 14:53, Issac Goldstand > wrote:

 On 5/3/2017 12:46 PM, Dirk-Willem van Gulik wrote:
> On 3 May 2017, at 10:03, Issac Goldstand  > wrote:
>>
>> +1 on the idea
>>
>> So far I'm -0 about all of the proposed implementations for 2 reasons:
>>
>> 1) Mr and Mrs normal (whom are our primary customers in the original
>> proposal) usually download Apache from their distro or some other
>> binary.  Their Apache sources are usually not up-to-date, and in the
>> scenario that a new vulnerability is found it would take ages to
>> propagate to them, anyway
>>
>> 2) For those users who are comfortable building their own source, they
> ….
>
> So how about ‘us’ taking the lead here. 

 That's the part I was always +1 on :)

> We, here, simply define ‘one’ setting as the industry best standard -
> which roughly corresponds to what ssllabs their test would get you an
> A+ and that pretty much meets or exceeds the various NIST et.al.
> recommendations for key lengths for the next 5 years. 

 The problem is, that we don't know what's going to be good going forward
 five years, and IMHO the best standards are shaped at least equally by
 removing "negatives" often because of high-risk vulnerabilities, as by
 adding new "positives" due to new available ciphers/tools
>>>
>>> Right - so I think there are two things
>>>
>>> 1)the general advice of NIST et.al. - summarized nicely at:
>>>
>>> https://www.keylength.com
>>>
>>> which tells us what our `best acceptable’ choises are in any release
>>> going out and their likely vailidy for the next 5 years.
>>>
>>> And then there is our response to things that become known; such as
>>> vulnerability - for which we have a proven update proces that is
>>> dovetailed by us sending mail to announce, the security mailing lists
>>> and similar outreach.
>>
>> Which, IMHO, we can safely expect Mr and Mrs Normal to never see.  Mr
>> and Mrs normal aren't on the mailing list of most pieces of software,
>> even if they use them.
>>
>> If we truly want to cater to them (and by doing so, do our part in
>> advocating a safer and more secure internet) then I maintain that we'd
>> need to do better.
> 
> Right - but then we are in the land of automatic updates; binary package 
> fetching and what not ? Or at the very least - pulling down a file over the 
> internet from ‘us’ that is sufficiently protected yet robust, etc ?
> 
> That is a whole new land?
> 
> Dw.
> 

Agreed, it is a whole new land. However, if we truly want a simple
"turnkey" method for MR and Mrs Normal, I don't see any other way that
will have fast-enough turnaround when vulnerabilities are discovered.

There's precedent for this sort of update mechanism inside the ASF with
SpamAssassin.  However, IMHO it doesn't make sense to reach out to them
to hear their thoughts of how sa-upadate deals with that land or
otherwise overthink this until we have some internal consensus that this
is an avenue that we would hypothetically be ok supporting.

If it's not turn-key, I don't see Mr and Mrs normal using it, and then
we could solve this for the rest of our users with a docs update.

The macros ideas are nifty, but I can't think of any use case where, for
example, a sysadmin (most definately NOT mr or mrs normal) would want to
configure multiple sets of macros on a single instance.

Re: SSL and Usability and Safety

[Stefan Eissing]

> Am 03.05.2017 um 15:22 schrieb Dirk-Willem van Gulik :
> 
>> 
>> On 3 May 2017, at 15:14, Issac Goldstand  wrote:
>> 
>> On 5/3/2017 3:59 PM, Dirk-Willem van Gulik wrote:
>>> 
 On 3 May 2017, at 14:53, Issac Goldstand > wrote:
 
 On 5/3/2017 12:46 PM, Dirk-Willem van Gulik wrote:
> On 3 May 2017, at 10:03, Issac Goldstand  > wrote:
>> 
>> +1 on the idea
>> 
>> So far I'm -0 about all of the proposed implementations for 2 reasons:
>> 
>> 1) Mr and Mrs normal (whom are our primary customers in the original
>> proposal) usually download Apache from their distro or some other
>> binary.  Their Apache sources are usually not up-to-date, and in the
>> scenario that a new vulnerability is found it would take ages to
>> propagate to them, anyway
>> 
>> 2) For those users who are comfortable building their own source, they
> ….
> 
> So how about ‘us’ taking the lead here. 
 
 That's the part I was always +1 on :)
 
> We, here, simply define ‘one’ setting as the industry best standard -
> which roughly corresponds to what ssllabs their test would get you an
> A+ and that pretty much meets or exceeds the various NIST et.al.
> recommendations for key lengths for the next 5 years. 
 
 The problem is, that we don't know what's going to be good going forward
 five years, and IMHO the best standards are shaped at least equally by
 removing "negatives" often because of high-risk vulnerabilities, as by
 adding new "positives" due to new available ciphers/tools
>>> 
>>> Right - so I think there are two things
>>> 
>>> 1)the general advice of NIST et.al. - summarized nicely at:
>>> 
>>> https://www.keylength.com
>>> 
>>> which tells us what our `best acceptable’ choises are in any release
>>> going out and their likely vailidy for the next 5 years.
>>> 
>>> And then there is our response to things that become known; such as
>>> vulnerability - for which we have a proven update proces that is
>>> dovetailed by us sending mail to announce, the security mailing lists
>>> and similar outreach.
>> 
>> Which, IMHO, we can safely expect Mr and Mrs Normal to never see.  Mr
>> and Mrs normal aren't on the mailing list of most pieces of software,
>> even if they use them.
>> 
>> If we truly want to cater to them (and by doing so, do our part in
>> advocating a safer and more secure internet) then I maintain that we'd
>> need to do better.
> 
> Right - but then we are in the land of automatic updates; binary package 
> fetching and what not ? Or at the very least - pulling down a file over the 
> internet from ‘us’ that is sufficiently protected yet robust, etc ?
> 
> That is a whole new land?

I think there is a step in between. If we make our releases security settings 
better and users opt-in, we can with every release improve that. Nothing to 
change in the processes here.

In case our settings prove to have a fault, there is always the possibility for 
a) ship a new release
b) specify an immediate workaround by using the existing SSL* directives 
appropriately

-Stefan

Re: SSL and Usability and Safety

[Dirk-Willem van Gulik]

> On 3 May 2017, at 15:14, Issac Goldstand  wrote:
> 
> On 5/3/2017 3:59 PM, Dirk-Willem van Gulik wrote:
>> 
>>> On 3 May 2017, at 14:53, Issac Goldstand >> > wrote:
>>> 
>>> On 5/3/2017 12:46 PM, Dirk-Willem van Gulik wrote:
 On 3 May 2017, at 10:03, Issac Goldstand > wrote:
> 
> +1 on the idea
> 
> So far I'm -0 about all of the proposed implementations for 2 reasons:
> 
> 1) Mr and Mrs normal (whom are our primary customers in the original
> proposal) usually download Apache from their distro or some other
> binary.  Their Apache sources are usually not up-to-date, and in the
> scenario that a new vulnerability is found it would take ages to
> propagate to them, anyway
> 
> 2) For those users who are comfortable building their own source, they
 ….
 
 So how about ‘us’ taking the lead here. 
>>> 
>>> That's the part I was always +1 on :)
>>> 
 We, here, simply define ‘one’ setting as the industry best standard -
 which roughly corresponds to what ssllabs their test would get you an
 A+ and that pretty much meets or exceeds the various NIST et.al.
 recommendations for key lengths for the next 5 years. 
>>> 
>>> The problem is, that we don't know what's going to be good going forward
>>> five years, and IMHO the best standards are shaped at least equally by
>>> removing "negatives" often because of high-risk vulnerabilities, as by
>>> adding new "positives" due to new available ciphers/tools
>> 
>> Right - so I think there are two things
>> 
>> 1)the general advice of NIST et.al. - summarized nicely at:
>> 
>> https://www.keylength.com
>> 
>> which tells us what our `best acceptable’ choises are in any release
>> going out and their likely vailidy for the next 5 years.
>> 
>> And then there is our response to things that become known; such as
>> vulnerability - for which we have a proven update proces that is
>> dovetailed by us sending mail to announce, the security mailing lists
>> and similar outreach.
> 
> Which, IMHO, we can safely expect Mr and Mrs Normal to never see.  Mr
> and Mrs normal aren't on the mailing list of most pieces of software,
> even if they use them.
> 
> If we truly want to cater to them (and by doing so, do our part in
> advocating a safer and more secure internet) then I maintain that we'd
> need to do better.

Right - but then we are in the land of automatic updates; binary package 
fetching and what not ? Or at the very least - pulling down a file over the 
internet from ‘us’ that is sufficiently protected yet robust, etc ?

That is a whole new land?

Dw.

Re: SSL and Usability and Safety

[Issac Goldstand]

On 5/3/2017 3:59 PM, Dirk-Willem van Gulik wrote:
> 
>> On 3 May 2017, at 14:53, Issac Goldstand > > wrote:
>>
>> On 5/3/2017 12:46 PM, Dirk-Willem van Gulik wrote:
>>> On 3 May 2017, at 10:03, Issac Goldstand >> > wrote:

 +1 on the idea

 So far I'm -0 about all of the proposed implementations for 2 reasons:

 1) Mr and Mrs normal (whom are our primary customers in the original
 proposal) usually download Apache from their distro or some other
 binary.  Their Apache sources are usually not up-to-date, and in the
 scenario that a new vulnerability is found it would take ages to
 propagate to them, anyway

 2) For those users who are comfortable building their own source, they
>>> ….
>>>
>>> So how about ‘us’ taking the lead here. 
>>
>> That's the part I was always +1 on :)
>>
>>> We, here, simply define ‘one’ setting as the industry best standard -
>>> which roughly corresponds to what ssllabs their test would get you an
>>> A+ and that pretty much meets or exceeds the various NIST et.al.
>>> recommendations for key lengths for the next 5 years. 
>>
>> The problem is, that we don't know what's going to be good going forward
>> five years, and IMHO the best standards are shaped at least equally by
>> removing "negatives" often because of high-risk vulnerabilities, as by
>> adding new "positives" due to new available ciphers/tools
> 
> Right - so I think there are two things
> 
> 1)the general advice of NIST et.al. - summarized nicely at:
> 
> https://www.keylength.com
> 
> which tells us what our `best acceptable’ choises are in any release
> going out and their likely vailidy for the next 5 years.
> 
> And then there is our response to things that become known; such as
> vulnerability - for which we have a proven update proces that is
> dovetailed by us sending mail to announce, the security mailing lists
> and similar outreach.

Which, IMHO, we can safely expect Mr and Mrs Normal to never see.  Mr
and Mrs normal aren't on the mailing list of most pieces of software,
even if they use them.

If we truly want to cater to them (and by doing so, do our part in
advocating a safer and more secure internet) then I maintain that we'd
need to do better.

> 
>>> We’d wrap this into a simple policy document. Promise ourselfves that
>>> we’d check this every release and at least once a year review it. And
>>> have a small list of the versions currently meeting or exceeding our
>>> policy.
>>>
>>> And this is the setting you get when you do ‘SSLEngine On’.
>>
>> To me this doesn't address the time lags between shipping it in source,
>> and it getting implemented on the machine.  I don't see it as superior
>> in any way to, say, putting the recommended settings in the online docs
>> and updating that from time to time - moreso when that update is in
>> response to a new vulnerability.
> 
> I think we should make sure that 1) any release that goes out meets or
> exceeds industry practice (e.g. the BSI 2017 recommendation up to 2022);
> and 2) that we keep a list of versions that are still `current’ enough;
> and that accomodates what we since their release learned. Typically
> meaning - update to version X.Y.
> 
> Dw

Re: SSL and Usability and Safety

[Dirk-Willem van Gulik]

> On 3 May 2017, at 14:53, Issac Goldstand  wrote:
> 
> On 5/3/2017 12:46 PM, Dirk-Willem van Gulik wrote:
>> On 3 May 2017, at 10:03, Issac Goldstand  wrote:
>>> 
>>> +1 on the idea
>>> 
>>> So far I'm -0 about all of the proposed implementations for 2 reasons:
>>> 
>>> 1) Mr and Mrs normal (whom are our primary customers in the original
>>> proposal) usually download Apache from their distro or some other
>>> binary.  Their Apache sources are usually not up-to-date, and in the
>>> scenario that a new vulnerability is found it would take ages to
>>> propagate to them, anyway
>>> 
>>> 2) For those users who are comfortable building their own source, they
>> ….
>> 
>> So how about ‘us’ taking the lead here. 
> 
> That's the part I was always +1 on :)
> 
>> We, here, simply define ‘one’ setting as the industry best standard - which 
>> roughly corresponds to what ssllabs their test would get you an A+ and that 
>> pretty much meets or exceeds the various NIST et.al. recommendations for key 
>> lengths for the next 5 years. 
> 
> The problem is, that we don't know what's going to be good going forward
> five years, and IMHO the best standards are shaped at least equally by
> removing "negatives" often because of high-risk vulnerabilities, as by
> adding new "positives" due to new available ciphers/tools

Right - so I think there are two things

1)  the general advice of NIST et.al. - summarized nicely at:

https://www.keylength.com

which tells us what our `best acceptable’ choises are in any release going out 
and their likely vailidy for the next 5 years.

And then there is our response to things that become known; such as 
vulnerability - for which we have a proven update proces that is dovetailed by 
us sending mail to announce, the security mailing lists and similar outreach.

>> We’d wrap this into a simple policy document. Promise ourselfves that we’d 
>> check this every release and at least once a year review it. And have a 
>> small list of the versions currently meeting or exceeding our policy.
>> 
>> And this is the setting you get when you do ‘SSLEngine On’.
> 
> To me this doesn't address the time lags between shipping it in source,
> and it getting implemented on the machine.  I don't see it as superior
> in any way to, say, putting the recommended settings in the online docs
> and updating that from time to time - moreso when that update is in
> response to a new vulnerability.

I think we should make sure that 1) any release that goes out meets or exceeds 
industry practice (e.g. the BSI 2017 recommendation up to 2022); and 2) that we 
keep a list of versions that are still `current’ enough; and that accomodates 
what we since their release learned. Typically meaning - update to version X.Y.

Dw

Re: SSL and Usability and Safety

[Issac Goldstand]

On 5/3/2017 12:46 PM, Dirk-Willem van Gulik wrote:
> On 3 May 2017, at 10:03, Issac Goldstand  wrote:
>>
>> +1 on the idea
>>
>> So far I'm -0 about all of the proposed implementations for 2 reasons:
>>
>> 1) Mr and Mrs normal (whom are our primary customers in the original
>> proposal) usually download Apache from their distro or some other
>> binary.  Their Apache sources are usually not up-to-date, and in the
>> scenario that a new vulnerability is found it would take ages to
>> propagate to them, anyway
>>
>> 2) For those users who are comfortable building their own source, they
>  ….
> 
> So how about ‘us’ taking the lead here. 

That's the part I was always +1 on :)

> 
> We, here, simply define ‘one’ setting as the industry best standard - which 
> roughly corresponds to what ssllabs their test would get you an A+ and that 
> pretty much meets or exceeds the various NIST et.al. recommendations for key 
> lengths for the next 5 years. 
> 

The problem is, that we don't know what's going to be good going forward
five years, and IMHO the best standards are shaped at least equally by
removing "negatives" often because of high-risk vulnerabilities, as by
adding new "positives" due to new available ciphers/tools

> We’d wrap this into a simple policy document. Promise ourselfves that we’d 
> check this every release and at least once a year review it. And have a small 
> list of the versions currently meeting or exceeding our policy.
> 
> And this is the setting you get when you do ‘SSLEngine On’.

To me this doesn't address the time lags between shipping it in source,
and it getting implemented on the machine.  I don't see it as superior
in any way to, say, putting the recommended settings in the online docs
and updating that from time to time - moreso when that update is in
response to a new vulnerability.

> 
> Everything else stays as is.
> 
> Dw
> 

Re: SSL Policy Definitions

[Dirk-Willem van Gulik]

> On 3 May 2017, at 14:09, Graham Leggett  wrote:
> 
> On 03 May 2017, at 2:01 PM, Stefan Eissing  
> wrote:
> 
>> We seem to all agree that a definition in code alone will not be good 
>> enough. People need to be able to see what is actually in effect.
> 
> I think we’re overthinking this.
> 
> We only need to document the settings that SSLSecurityLevel has clearly in 
> our docs, and make sure that "httpd -L” prints out the exact details so no 
> user need ever get confused.
> 
>> If we let users define their own classes, it could look like this:
> 
> Immediately we’ve jumped into functionality that is beyond Mr/Mrs Normal.

Agreed. If our default is simply ‘industry best practice’ (i.e. what we say it 
is*) — then Normal will be the new black.

And everyone else is still in the same boat - i.e. having to specify it just 
like they do today.

All that requires it to make the defaults sane.

Dw.

*: exceed NIST and https://www.keylength.com/  for 
5+ years, PFS, A or better at SSLLabs. 
https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices 




signature.asc
Description: Message signed with OpenPGP

Re: SSL Policy Definitions

[Stefan Eissing]

> Am 03.05.2017 um 14:20 schrieb Luca Toscano :
> 
> Hi Graham,
> 
> 2017-05-03 14:09 GMT+02:00 Graham Leggett :
> On 03 May 2017, at 2:01 PM, Stefan Eissing  
> wrote:
> 
> > We seem to all agree that a definition in code alone will not be good 
> > enough. People need to be able to see what is actually in effect.
> 
> I think we’re overthinking this.
> 
> We only need to document the settings that SSLSecurityLevel has clearly in 
> our docs, and make sure that "httpd -L” prints out the exact details so no 
> user need ever get confused.

+1 
Having the definitions listed via command line is good enough for me.

> 
> I think that in this case documentation is not enough since it tends to 
> quickly fall behind dev commits, plus it would be great for a user to know in 
> a programatic way what are the runtime settings used for SSL (or just to 
> allow admin to manually check/review them).
>  
> 
> > If we let users define their own classes, it could look like this:
> 
> Immediately we’ve jumped into functionality that is beyond Mr/Mrs Normal
> 
> True, even if the idea looks great I'd focus only on Mr/Mrs Normal for the 
> moment :)

Agreed.

SSL Policy Merging

[Stefan Eissing]

How will SSL Policies be applied?

> Am 03.05.2017 um 12:08 schrieb Stefan Eissing :
> 
> b. There is discussion about the impact on config merging:
> 
>> Am 02.05.2017 um 19:28 schrieb Rainer Jung :
>> a) in order of occurrence in the config files (order of reading)
>> b) the most secure settings win
>> c) first apply the "intent" directive, then merge the existing detail 
>> settings on top
> 
>> I guess c) would be the most logical, but probably needs some additional 
>> feature in config parsing.
> 
>> Am 02.05.2017 um 19:32 schrieb Ruediger Pluem :
>> c) would be the best, but a) IMHO would be acceptable since overwriting is 
>> for the more advanced users anyway and they
>> can be told to do stuff in the correct order.

I think there are two different use cases:

1. The admin knows SSL* directives well. She would like to set a base policy 
for the defaults and override when needed.
2. The admin in uncomfortable with SSL* directives. Example: he heard 
"SSLUseStapling on" is good, but does not really know what it is. And he just 
wants A+ on SSLLabs, because that is also what his boss checks.

This, in config speak, would then be:

  SSLSecurityPolicysomething
  SSLPolicyOverrideallow | deny | ignore

with "allow" being case 1. and "ignore" recommended for 2.


The case of "ignore" vs. "deny": "deny" would mean the configuration fails if 
an SSL* directive is specified that would try to change a setting defined by 
the security policy. Such as

  SSLSecurityPolicysomething
  
SSLHonorCipherOrder off
  

Under "allow" this would have effect, "deny" would fail and "ignore" would keep 
the cipher order as defined in "something" (we should log a WARNING in such a 
case). "deny" is for people who prefer their sites to fail after an upgrade, 
than pre-empt directives because the definition of "something" changed.

Example: imagine SSLCompression was not part of any policy. Someone configures 
policy A, but has also vhosts where it is configured "on". Now we find out the 
compression is insecure and add "off" to policy A and ship a new release...

-Stefan

Re: SSL Policy Definitions

[Luca Toscano]

Hi Graham,

2017-05-03 14:09 GMT+02:00 Graham Leggett :

> On 03 May 2017, at 2:01 PM, Stefan Eissing 
> wrote:
>
> > We seem to all agree that a definition in code alone will not be good
> enough. People need to be able to see what is actually in effect.
>
> I think we’re overthinking this.
>
> We only need to document the settings that SSLSecurityLevel has clearly in
> our docs, and make sure that "httpd -L” prints out the exact details so no
> user need ever get confused.
>

I think that in this case documentation is not enough since it tends to
quickly fall behind dev commits, plus it would be great for a user to know
in a programatic way what are the runtime settings used for SSL (or just to
allow admin to manually check/review them).


>
> > If we let users define their own classes, it could look like this:
>
> Immediately we’ve jumped into functionality that is beyond Mr/Mrs Normal
>

True, even if the idea looks great I'd focus only on Mr/Mrs Normal for the
moment :)

Luca

Re: SSL Policy Definitions

[Graham Leggett]

On 03 May 2017, at 2:01 PM, Stefan Eissing  wrote:

> We seem to all agree that a definition in code alone will not be good enough. 
> People need to be able to see what is actually in effect.

I think we’re overthinking this.

We only need to document the settings that SSLSecurityLevel has clearly in our 
docs, and make sure that "httpd -L” prints out the exact details so no user 
need ever get confused.

> If we let users define their own classes, it could look like this:

Immediately we’ve jumped into functionality that is beyond Mr/Mrs Normal.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature

SSL Policy Definitions

[Stefan Eissing]

Coming back how we would want to define SSL Security Policies:

> Am 03.05.2017 um 12:08 schrieb Stefan Eissing :
> 3. Place of Definition
> --
> Code vs. Config Files vs. Macros vs. "Owned Macros"
> 
>> Am 03.05.2017 um 00:48 schrieb Jacob Champion :
>> If all of the settings that are part of this new directive can be described 
>> in terms of other already-existing directives, could we implement it as a 
>> server-owned Macro?
> 
>> Am 03.05.2017 um 03:11 schrieb Daniel Ruggeri :
>> I actually was going to respond in a similar way by proposing the use of 
>> files that could be Included. I really like this idea for all the reasons 
>> mentioned - the biggest being that it's trivial for a SecAdmin or WebAdmin 
>> to see what is in the Included file and its macros and what gets applied. I 
>> am also in support of regularly evolving the values because an admin making 
>> use of them is aware that they are delegating responsibility to us or their 
>> package vendor. The downside (which may no longer be valid - haven't looked 
>> in ages) is that I think Includes and Macros confuse line numbers in error 
>> messages.
> 
>> Am 03.05.2017 um 09:37 schrieb Luca Toscano :
>> One thing that I'd would really like to see as admin would be a quick way to 
>> dump/inspect/visualize what SSLSecurityLevel 2017-05 corresponds to 
>> (SSLDirectiveX set to foo, SSLDirectiveY set to bar, etc..). Even better 
>> would be to have also a little bit of description attached to the dump, or 
>> just a reference to the docs.

We seem to all agree that a definition in code alone will not be good enough. 
People need to be able to see what is actually in effect.

But shipping just some default *.conf files does not cut it for me either. Will 
they be included? Will they be re-installed on an update?

Hmm, I am not very versed in all the config/macro possibilities, but I notice 
that apachectl has some interesting command line options, where we could add 
sth. like:

 > apachectl -t -D DUMP_SSL_POLICIES

to output the exact SSL* settings that are in effect for each (pre-)defined 
policy class.

If we let users define their own classes, it could look like this:

 
SSLSecurityPolicy   modern
SSLCipherSuite  XYZ:MUMBO:JUMBO
 

 
SSLProtocol TLSv1.3
SSLCipherSuite  ABC:WHATEVER
SSLHonorCipherOrder on
SSLUseStapling  on
 

and 

 
   ...
 

would generate an error since it cannot be redefined.

Cheers,

-Stefan

Re: SSL Policies

[Stefan Eissing]

> Am 03.05.2017 um 12:08 schrieb Stefan Eissing :
> Whatever categories we define where etc. I think we can agree that
> a. Security policy needs to be an opt-in. No existing config will change 
> unless the user choses a policy.
> b. One value of policy names is that they can be easier to understand (if 
> there are not too many), if given a comprehensible name.
> 
> Less clear:
> c. Another value of security policies is that their definition can be updated 
> by the project. "modern" is not "modern" from 2005.
>There is discussion needed about this aspect. Basically, do we want 
> policies like
>i. "modern" which we update, or
>ii. "strong-2017" which we freeze
> 
> The upside of i. is we can improve life for people who are not full time 
> employed as apache admins. The downside of it is that we can break sites with 
> a policy update.

I propose to offer a directive, such as

  SSLSecurityPolicy modern | intermediate | old | none

with the following rationale:

1. "none" as default. This is exactly the 2.4 behaviour as of now.

   Rationale:  This means that when we ship it, all existing sites will work as 
before.

2. "modern", "intermediate" and "old" as defined and updated by Mozilla in 
https://wiki.mozilla.org/Security/Server_Side_TLS. On release or otherwise 
notified by Mozilla, we would update httpd's definitions. httpd would apply the 
definition with only documented exceptions, for example if the linked SSL 
library lacks support for a cipher. A directive needs to fail configuration 
test if vital parts of the policies are not supported, e.g. "modern" and no 
TLSv1.2 available.

   Rationale: the categories are to a certain extend self-describing. The name 
implies that the definition is a moving target. The categories are known to an 
increasing number of people. SSLLabs uses them. People love SSLLabs scores. 
   The definitions include interop expectations with browser clients. "modern" 
describes modern browsers and modern browsers implement "modern".

3. "old" included.

  Rationale: A server might specify "modern" as part of the base server config. 
But a VirtualHost might need backward compatibility for some reason and, 
instead of specifying all the usual ciphers etc. explicitly, an admin might 
prefer "old" as policy.

Do we need more categories? I do not know! These three seem to work well for 
others. But power users might like to define their own set, not the least 
because their performance/hardware make it most appropriate. We can ether say 
"do not use policy then" or provide a mechanism to define a new policy. The 
ease of doing that depends a lot on how we implement policy definitions 
(code/config/macros etc.) which I open another thread on.

BUT: I think it is very important that only the project defines what "modern" 
is in Apache httpd. If distros or local config files dropped into the server 
re-define what it means, it quickly becomes meaningless for everyone. Then we 
are back to square one. 

The project should say: Apache httpd "modern" is Mozilla's "modern", aka. what 
modern browsers implement (at the time of a release). If you configure your 
site that way, the project keeps it up-to-date. 

4. policy variations: I can get people that say: "yes, I want modern, but a 
little bit speedier than the default, as I have this special 
setup/need/hardware etc.". We can say: take modern and override the ciphers. Or 
we could offer something special, such as "modern-faster". I personally do not 
like this, at least not at the start. Too many options do not help.


In case we can not agree on these categories and their definitions, we would 
need to create, document, advocate and update our own definitions. And define 
what they mean in relation to browsers and Mozilla's classes. Is this worth our 
time?

Cheers,

Stefan

Re: SSL and Usability and Safety

[Stefan Eissing]

I try to summarise the many replies (and thanks for the interest!), to sketch 
out a possible path forward.

1. Overall
--
Replies in general have been very positive.
 wr...@rowe-clan.net: "I like the proposal."
 rainer.j...@kippdata.de: "I like the idea."
 champio...@gmail.com: "+1 to this idea"

Some concerns were raised:

> Am 02.05.2017 um 22:42 schrieb Daniel :
> I am a bit concerned about the implications something like this may bring to 
> you guys, let me explain.
> [...after updating...]
>  it will fail, maybe the Mr. and Ms. Normal won't be able to figure out since 
> they changed nothing and the thing just started failing for them?

> Am 02.05.2017 um 23:10 schrieb Eric Covener :
> They upgraded. The few broken users will have a better chance of
> understanding what changed from CHANGES or the manual then most users
> have of understanding what "HIGH:!PSK:!aNULL:!EXP:!SRP" really
> "means".

Others have similar things. OpenSSL itself defines classes (not specifically 
targeted at HTTP. I once talked with Rich Salz about this and he said the 
OpenSSL is not aware of the application protocol. Layering.) and AWS has 
standard and user-defined policies. Something very similar. it seems.

Besides security policy, this could be used for other things:

> Am 02.05.2017 um 23:01 schrieb Helmut K. C. Tessarek :
> It would be great to explain the performance impact per setting.
> 

Whatever categories we define where etc. I think we can agree that
 a. Security policy needs to be an opt-in. No existing config will change 
unless the user choses a policy.
 b. One value of policy names is that they can be easier to understand (if 
there are not too many), if given a comprehensible name.
 
 Less clear:
 c. Another value of security policies is that their definition can be updated 
by the project. "modern" is not "modern" from 2005.
There is discussion needed about this aspect. Basically, do we want 
policies like
i. "modern" which we update, or
ii. "strong-2017" which we freeze

 The upside of i. is we can improve life for people who are not full time 
employed as apache admins. The downside of it is that we can break sites with a 
policy update.


2. Categories
-
 a. There is discussion if we should use the Mozilla Policy definions "modern", 
"intermediate" and "old". There is discussion if especially "old" is useful.

 b. There is discussion about the impact on config merging:

> Am 02.05.2017 um 19:28 schrieb Rainer Jung :
> a) in order of occurrence in the config files (order of reading)
> b) the most secure settings win
> c) first apply the "intent" directive, then merge the existing detail 
> settings on top

> I guess c) would be the most logical, but probably needs some additional 
> feature in config parsing.

> Am 02.05.2017 um 19:32 schrieb Ruediger Pluem :
> c) would be the best, but a) IMHO would be acceptable since overwriting is 
> for the more advanced users anyway and they
> can be told to do stuff in the correct order.

I think this merits its own thread.

3. Place of Definition
--
Code vs. Config Files vs. Macros vs. "Owned Macros"

> Am 03.05.2017 um 00:48 schrieb Jacob Champion :
> If all of the settings that are part of this new directive can be described 
> in terms of other already-existing directives, could we implement it as a 
> server-owned Macro?

> Am 03.05.2017 um 03:11 schrieb Daniel Ruggeri :
> I actually was going to respond in a similar way by proposing the use of 
> files that could be Included. I really like this idea for all the reasons 
> mentioned - the biggest being that it's trivial for a SecAdmin or WebAdmin to 
> see what is in the Included file and its macros and what gets applied. I am 
> also in support of regularly evolving the values because an admin making use 
> of them is aware that they are delegating responsibility to us or their 
> package vendor. The downside (which may no longer be valid - haven't looked 
> in ages) is that I think Includes and Macros confuse line numbers in error 
> messages.

> Am 03.05.2017 um 09:37 schrieb Luca Toscano :
> One thing that I'd would really like to see as admin would be a quick way to 
> dump/inspect/visualize what SSLSecurityLevel 2017-05 corresponds to 
> (SSLDirectiveX set to foo, SSLDirectiveY set to bar, etc..). Even better 
> would be to have also a little bit of description attached to the dump, or 
> just a reference to the docs.

I think this also merits its own thread.

4. Update Process
-
Some people talk about the need for new processes here.
> Am 03.05.2017 um 10:03 schrieb Issac Goldstand :
> 
> What would work, in my eyes, if people are open to it, is treating the
> contents of these definitions/macros (and I'm all for the 

Re: SSL and Usability and Safety

[Dirk-Willem van Gulik]

On 3 May 2017, at 10:03, Issac Goldstand  wrote:
> 
> +1 on the idea
> 
> So far I'm -0 about all of the proposed implementations for 2 reasons:
> 
> 1) Mr and Mrs normal (whom are our primary customers in the original
> proposal) usually download Apache from their distro or some other
> binary.  Their Apache sources are usually not up-to-date, and in the
> scenario that a new vulnerability is found it would take ages to
> propagate to them, anyway
> 
> 2) For those users who are comfortable building their own source, they
 ….

So how about ‘us’ taking the lead here. 

We, here, simply define ‘one’ setting as the industry best standard - which 
roughly corresponds to what ssllabs their test would get you an A+ and that 
pretty much meets or exceeds the various NIST et.al. recommendations for key 
lengths for the next 5 years. 

We’d wrap this into a simple policy document. Promise ourselfves that we’d 
check this every release and at least once a year review it. And have a small 
list of the versions currently meeting or exceeding our policy.

And this is the setting you get when you do ‘SSLEngine On’.

Everything else stays as is.

Dw

Re: SSL and Usability and Safety

[Ben Laurie]

On 3 May 2017 at 09:03, Issac Goldstand  wrote:
> What would work, in my eyes, if people are open to it, is treating the
> contents of these definitions/macros (and I'm all for the macros, just
> so that interested sysadmins can see *exactly* what the settings are on
> their setup) as apart from the httpd sources, and thus not subject to
> the normal release cycle.  To clarify,  I mean the httpd tarball release
> cycles specifically, not our policies for how we perform and vote on the
> releases (although we'd need to come to agreement on how to allow for
> quick releases in the face of security issues, so a 3 day vote followed
> by release may not work).  Instead, we could do something similar to the
> spamassassin project does with their base rules, where we have external
> tooling (or internal tooling, if it's preferred) fetch the up-to-date
> definitions from an ASF mirror server on a regular basis and override
> the local definitions.

FWIW, this seems like the right approach to me.

Re: SSL and Usability and Safety

[Issac Goldstand]

+1 on the idea

So far I'm -0 about all of the proposed implementations for 2 reasons:

1) Mr and Mrs normal (whom are our primary customers in the original
proposal) usually download Apache from their distro or some other
binary.  Their Apache sources are usually not up-to-date, and in the
scenario that a new vulnerability is found it would take ages to
propagate to them, anyway

2) For those users who are comfortable building their own source, they
run into our PMCs release timing.  What happens if a vulnerability is
released, we quickly backport from trunk[1] to whatever branches are
needed based on what's up-to-date and we want to release said old
branches?  Suddenly, we realize that one (or more) of these old branches
have changes unrelated to the vulnerability and we erupt into days or
weeks of constructive arguments on the merit of these other changes to
be released?

What would work, in my eyes, if people are open to it, is treating the
contents of these definitions/macros (and I'm all for the macros, just
so that interested sysadmins can see *exactly* what the settings are on
their setup) as apart from the httpd sources, and thus not subject to
the normal release cycle.  To clarify,  I mean the httpd tarball release
cycles specifically, not our policies for how we perform and vote on the
releases (although we'd need to come to agreement on how to allow for
quick releases in the face of security issues, so a 3 day vote followed
by release may not work).  Instead, we could do something similar to the
spamassassin project does with their base rules, where we have external
tooling (or internal tooling, if it's preferred) fetch the up-to-date
definitions from an ASF mirror server on a regular basis and override
the local definitions.

Best,
  Issac

[1] and this assumes we'd be keeping these configs in trunk, which is
kinda backwards IMHO,  given that trunk by definition is stuff with
potential to release at some point in the future, whereas these configs
are our published best-practice for *now*

On 5/3/2017 4:11 AM, Daniel Ruggeri wrote:
> I actually was going to respond in a similar way by proposing the use of
> files that could be Included. I really like this idea for all the
> reasons mentioned - the biggest being that it's trivial for a SecAdmin
> or WebAdmin to see what is in the Included file and its macros and what
> gets applied. I am also in support of regularly evolving the values
> because an admin making use of them is aware that they are delegating
> responsibility to us or their package vendor. The downside (which may no
> longer be valid - haven't looked in ages) is that I think Includes and
> Macros confuse line numbers in error messages.
> -- 
> Daniel Ruggeri
> 
> 
> *From:* Jacob Champion 
> *Sent:* May 2, 2017 5:48:34 PM CDT
> *To:* dev@httpd.apache.org
> *Subject:* Re: SSL and Usability and Safety
> 
> On 05/02/2017 02:10 PM, Eric Covener wrote:
> 
> I think to be useful, reasonable SSL defaults have to be subject to
> change in maintenance (and over-rideable)
> 
> 
> So... this got me thinking. If we put this new "stuff" (whatever it 
> turns out to be) into a new directive,
> 
> - part of its operation gets tied to source code that's hidden from the 
> end user
> - we'll probably have to duplicate some SSL directive logic in the module
> - we have to figure out the merge/conflict scenarios, which -- while 
> definitely worthwhile in the long term -- feels likely to add complexity 
> to the short-term discussion
> 
> If all of the settings that are part of this new directive can be 
> described in terms of other already-existing directives, could we 
> implement it as a server-owned Macro?
> 
> - their implementation is public and auditable by anyone who understands 
> the config syntax
> - they can be easily patched for vulnerabilities without recompiling 
> anything
> - merge/conflict resolution will follow the individual directives' 
> current merge logic (whatever that happens to be)
> 
> We could reserve a macro prefix (or symbol) for the server and its 
> modules so that we don't step on anyone with future expansion. Then it's 
> just a matter of
> 
>  Include macros/ssl.conf
> 
>  Use !SslIntermediateSecuritySettings
> 
> We'd have to be very explicit that the macro definitions belong to the 
> server distribution, and installing a newer (or older) version of the 
> server would overwrite whatever changes you'd made to those macro files.
> 
> Thoughts?
> 
> --Jacob
> 

Re: SSL and Usability and Safety

[Luca Toscano]

2017-05-03 2:29 GMT+02:00 Graham Leggett :

> On 02 May 2017, at 3:19 PM, Stefan Eissing 
> wrote:
>
> How can we help Mr and Ms Normal to stay up to date on these things?
>
> - We cannot rewrite their config unasked. We need to be backward
> compatible.
> - Our defaults nowadays are dangerously unsafe, so users MUST do their own
> settings.
>
> I advocate that we need (yet another!) SSL directive where administrators
> can declare their *intent*.
>
> A. "I want my site safe and usable with modern browsers!"
> B. "I want a safe setting, but people with slightly out-dated clients
> should be served as well."
> C. "I sadly need compatibility to some very old clients.”
>
>
> This makes a lot of sense, and there is a lot of precedent for this.
>
> AWS load balancers take an “intent” policy string based on a date, with
> the option of a “default” value:
>
> http://docs.aws.amazon.com/elasticloadbalancing/latest/
> classic/ssl-config-update.html
>
> --
> |  DescribeLoadBalancerPolicies  |
> ++
> |   PolicyName   |
> ++
> |  ELBSecurityPolicy-2016-08 |
> |  ELBSecurityPolicy-2015-05 |
> |  ELBSecurityPolicy-2015-03 |
> |  ELBSecurityPolicy-2015-02 |
> |  ELBSecurityPolicy-2014-10 |
> |  ELBSecurityPolicy-2014-01 |
> |  ELBSecurityPolicy-2011-08 |
> |  ELBSample-ELBDefaultCipherPolicy  |
> |  ELBSample-OpenSSLDefaultCipherPolicy  |
> ++
>
> Implementation wise, we could have a directive that is used to select the
> default values of various parameters, for example:
>
> SSLSecurityLevel latest
>
> or
>
> SSLSecurityLevel 2017-05
>

Really like this idea, it seems a good compromise to me. While reading the
email thread I was worried about keeping separate configuration and
implementation, but this approach makes me feel better.

One thing that I'd would really like to see as admin would be a quick way
to dump/inspect/visualize what SSLSecurityLevel 2017-05 corresponds to
(SSLDirectiveX set to foo, SSLDirectiveY set to bar, etc..). Even better
would be to have also a little bit of description attached to the dump, or
just a reference to the docs.

Luca