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
do:
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 ...
...
</SSLPolicy>
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).
Implementation:
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
SSLSrvConfigRec*
for the section.
The config command for "SSLPolicy" will look up the SSLSrvConfigRec* of "name"
in
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
policy.
Compatibility:
Existing installations are unaffected by this addition.
-Stefan
