How will SSL Policies be applied?

> Am 03.05.2017 um 12:08 schrieb Stefan Eissing <stefan.eiss...@greenbytes.de>:
> 
> b. There is discussion about the impact on config merging:
> 
>> Am 02.05.2017 um 19:28 schrieb Rainer Jung <rainer.j...@kippdata.de>:
>> 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 <rpl...@apache.org>:
>> 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:

  SSLSecurityPolicy    something
  SSLPolicyOverride    allow | 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

  SSLSecurityPolicy    something
  <VirtualHost *:443>
    SSLHonorCipherOrder     off
  </VirtualHost>

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


Reply via email to