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