> Am 03.05.2017 um 12:08 schrieb Stefan Eissing <stefan.eiss...@greenbytes.de>:
> Whatever categories we define where etc. I think we can agree that
> a. Security policy needs to be an opt-in. No existing config will change 
> unless the user choses a policy.
> b. One value of policy names is that they can be easier to understand (if 
> there are not too many), if given a comprehensible name.
> Less clear:
> c. Another value of security policies is that their definition can be updated 
> by the project. "modern" is not "modern" from 2005.
>    There is discussion needed about this aspect. Basically, do we want 
> policies like
>    i. "modern" which we update, or
>    ii. "strong-2017" which we freeze
> The upside of i. is we can improve life for people who are not full time 
> employed as apache admins. The downside of it is that we can break sites with 
> a policy update.    

I propose to offer a directive, such as

  SSLSecurityPolicy modern | intermediate | old | none

with the following rationale:

1. "none" as default. This is exactly the 2.4 behaviour as of now.

   Rationale:  This means that when we ship it, all existing sites will work as 

2. "modern", "intermediate" and "old" as defined and updated by Mozilla in 
https://wiki.mozilla.org/Security/Server_Side_TLS. On release or otherwise 
notified by Mozilla, we would update httpd's definitions. httpd would apply the 
definition with only documented exceptions, for example if the linked SSL 
library lacks support for a cipher. A directive needs to fail configuration 
test if vital parts of the policies are not supported, e.g. "modern" and no 
TLSv1.2 available.

   Rationale: the categories are to a certain extend self-describing. The name 
implies that the definition is a moving target. The categories are known to an 
increasing number of people. SSLLabs uses them. People love SSLLabs scores. 
   The definitions include interop expectations with browser clients. "modern" 
describes modern browsers and modern browsers implement "modern".

3. "old" included.

  Rationale: A server might specify "modern" as part of the base server config. 
But a VirtualHost might need backward compatibility for some reason and, 
instead of specifying all the usual ciphers etc. explicitly, an admin might 
prefer "old" as policy.

Do we need more categories? I do not know! These three seem to work well for 
others. But power users might like to define their own set, not the least 
because their performance/hardware make it most appropriate. We can ether say 
"do not use policy then" or provide a mechanism to define a new policy. The 
ease of doing that depends a lot on how we implement policy definitions 
(code/config/macros etc.) which I open another thread on.

BUT: I think it is very important that only the project defines what "modern" 
is in Apache httpd. If distros or local config files dropped into the server 
re-define what it means, it quickly becomes meaningless for everyone. Then we 
are back to square one. 

The project should say: Apache httpd "modern" is Mozilla's "modern", aka. what 
modern browsers implement (at the time of a release). If you configure your 
site that way, the project keeps it up-to-date. 

4. policy variations: I can get people that say: "yes, I want modern, but a 
little bit speedier than the default, as I have this special 
setup/need/hardware etc.". We can say: take modern and override the ciphers. Or 
we could offer something special, such as "modern-faster". I personally do not 
like this, at least not at the start. Too many options do not help.

In case we can not agree on these categories and their definitions, we would 
need to create, document, advocate and update our own definitions. And define 
what they mean in relation to browsers and Mozilla's classes. Is this worth our 



Reply via email to