> 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 before. 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 time? Cheers, Stefan
