How will SSL Policies be applied?
> Am 03.05.2017 um 12:08 schrieb Stefan Eissing <[email protected]>:
>
> b. There is discussion about the impact on config merging:
>
>> Am 02.05.2017 um 19:28 schrieb Rainer Jung <[email protected]>:
>> 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 <[email protected]>:
>> 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
