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

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

   <SSLPolicy name>
     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).

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 
for the section.
The config command for "SSLPolicy" will look up the SSLSrvConfigRec* of "name" 
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 

Existing installations are unaffected by this addition.


Reply via email to