httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <stefan.eiss...@greenbytes.de>
Subject Re: SSL and Usability and Safety
Date Wed, 03 May 2017 10:08:19 GMT
I try to summarise the many replies (and thanks for the interest!), to sketch out a possible
path forward.

1. Overall
----------
Replies in general have been very positive.
     wrowe@rowe-clan.net: "I like the proposal."
     rainer.jung@kippdata.de: "I like the idea."
     champion.p@gmail.com: "+1 to this idea"

Some concerns were raised:

> Am 02.05.2017 um 22:42 schrieb Daniel <dferradal@gmail.com>:
> I am a bit concerned about the implications something like this may bring to you guys,
let me explain.
> [...after updating...]
>  it will fail, maybe the Mr. and Ms. Normal won't be able to figure out since they changed
nothing and the thing just started failing for them?

> Am 02.05.2017 um 23:10 schrieb Eric Covener <covener@gmail.com>:
> They upgraded. The few broken users will have a better chance of
> understanding what changed from CHANGES or the manual then most users
> have of understanding what "HIGH:!PSK:!aNULL:!EXP:!SRP" really
> "means".

Others have similar things. OpenSSL itself defines classes (not specifically targeted at HTTP.
I once talked with Rich Salz about this and he said the OpenSSL is not aware of the application
protocol. Layering.) and AWS has standard and user-defined policies. Something very similar.
it seems.

Besides security policy, this could be used for other things:

> Am 02.05.2017 um 23:01 schrieb Helmut K. C. Tessarek <tessarek@evermeet.cx>:
> It would be great to explain the performance impact per setting.
> 

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.    


2. Categories
-------------
 a. There is discussion if we should use the Mozilla Policy definions "modern", "intermediate"
and "old". There is discussion if especially "old" is useful.

 b. There is discussion about the impact on config merging:

> Am 02.05.2017 um 19:28 schrieb Rainer Jung <rainer.jung@kippdata.de>:
> a) in order of occurrence in the config files (order of reading)
> b) the most secure settings win
> c) first apply the "intent" directive, then merge the existing detail settings on top

> I guess c) would be the most logical, but probably needs some additional feature in config
parsing.

> Am 02.05.2017 um 19:32 schrieb Ruediger Pluem <rpluem@apache.org>:
> c) would be the best, but a) IMHO would be acceptable since overwriting is for the more
advanced users anyway and they
> can be told to do stuff in the correct order.

I think this merits its own thread.

3. Place of Definition
----------------------
Code vs. Config Files vs. Macros vs. "Owned Macros"

> Am 03.05.2017 um 00:48 schrieb Jacob Champion <champion.p@gmail.com>:
> If all of the settings that are part of this new directive can be described in terms
of other already-existing directives, could we implement it as a server-owned Macro?

> Am 03.05.2017 um 03:11 schrieb Daniel Ruggeri <druggeri@primary.net>:
> I actually was going to respond in a similar way by proposing the use of files that could
be Included. I really like this idea for all the reasons mentioned - the biggest being that
it's trivial for a SecAdmin or WebAdmin to see what is in the Included file and its macros
and what gets applied. I am also in support of regularly evolving the values because an admin
making use of them is aware that they are delegating responsibility to us or their package
vendor. The downside (which may no longer be valid - haven't looked in ages) is that I think
Includes and Macros confuse line numbers in error messages.

> Am 03.05.2017 um 09:37 schrieb Luca Toscano <toscano.luca@gmail.com>:
> One thing that I'd would really like to see as admin would be a quick way to dump/inspect/visualize
what SSLSecurityLevel 2017-05 corresponds to (SSLDirectiveX set to foo, SSLDirectiveY set
to bar, etc..). Even better would be to have also a little bit of description attached to
the dump, or just a reference to the docs.

I think this also merits its own thread.

4. Update Process
-----------------
Some people talk about the need for new processes here.
> Am 03.05.2017 um 10:03 schrieb Issac Goldstand <margol@beamartyr.net>:
> 
> What would work, in my eyes, if people are open to it, is treating the
> contents of these definitions/macros (and I'm all for the macros, just
> so that interested sysadmins can see *exactly* what the settings are on
> their setup) as apart from the httpd sources, and thus not subject to
> the normal release cycle.  To clarify,  I mean the httpd tarball release
> cycles specifically, not our policies for how we perform and vote on the
> releases (although we'd need to come to agreement on how to allow for
> quick releases in the face of security issues, so a 3 day vote followed
> by release may not work).  Instead, we could do something similar to the
> spamassassin project does with their base rules, where we have external
> tooling (or internal tooling, if it's preferred) fetch the up-to-date
> definitions from an ASF mirror server on a regular basis and override
> the local definitions.

And a simpler version:
> Am 03.05.2017 um 11:46 schrieb Dirk-Willem van Gulik <dirkx@webweaving.org>:
> 
> We, here, simply define ‘one’ setting as the industry best standard - which roughly
corresponds to what ssllabs their test would get you an A+ and that pretty much meets or exceeds
the various NIST et.al. recommendations for key lengths for the next 5 years. 
> 
> We’d wrap this into a simple policy document. Promise ourselfves that we’d check
this every release and at least once a year review it. And have a small list of the versions
currently meeting or exceeding our policy.
> 
> And this is the setting you get when you do ‘SSLEngine On’.
> 
> Everything else stays as is.

Personally, I think we will end with some new things we do. But I'd prefer them to emerge
from what we decide to offer our users. Example: if we offer something like "modern", I do
not see a need for a quick, separate update cycle of that definition. That will evolve with
more glacial speed.

Cheers,

-Stefan
Mime
View raw message