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 super-modern>
    SSLSecurityPolicy   modern
    SSLCipherSuite      XYZ:MUMBO:JUMBO

 <SSLSecurityPolicy local-secure>
    SSLProtocol         TLSv1.3
    SSLCipherSuite      ABC:WHATEVER
    SSLHonorCipherOrder on
    SSLUseStapling      on


 <SSLSecurityPolicy modern>

would generate an error since it cannot be redefined.



Reply via email to