You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Stefan Eissing <st...@greenbytes.de> on 2017/05/03 12:01:33 UTC
SSL Policy Definitions
Coming back how we would want to define SSL Security Policies:
> Am 03.05.2017 um 12:08 schrieb Stefan Eissing <st...@greenbytes.de>:
> 3. Place of Definition
> ----------------------
> Code vs. Config Files vs. Macros vs. "Owned Macros"
>
>> Am 03.05.2017 um 00:48 schrieb Jacob Champion <ch...@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 <dr...@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 <to...@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.
We seem to all agree that a definition in code alone will not be good enough. People need to be able to see what is actually in effect.
But shipping just some default *.conf files does not cut it for me either. Will they be included? Will they be re-installed on an update?
Hmm, I am not very versed in all the config/macro possibilities, but I notice that apachectl has some interesting command line options, where we could add sth. like:
> apachectl -t -D DUMP_SSL_POLICIES
to output the exact SSL* settings that are in effect for each (pre-)defined policy class.
If we let users define their own classes, it could look like this:
<SSLSecurityPolicy super-modern>
SSLSecurityPolicy modern
SSLCipherSuite XYZ:MUMBO:JUMBO
</SSLSecurityPolicy>
<SSLSecurityPolicy local-secure>
SSLProtocol TLSv1.3
SSLCipherSuite ABC:WHATEVER
SSLHonorCipherOrder on
SSLUseStapling on
</SSLSecurityPolicy>
and
<SSLSecurityPolicy modern>
...
</SSLSecurityPolicy>
would generate an error since it cannot be redefined.
Cheers,
-Stefan
Re: SSL Policy Definitions
Posted by Dirk-Willem van Gulik <di...@webweaving.org>.
> On 3 May 2017, at 14:09, Graham Leggett <mi...@sharp.fm> wrote:
>
> On 03 May 2017, at 2:01 PM, Stefan Eissing <st...@greenbytes.de> wrote:
>
>> We seem to all agree that a definition in code alone will not be good enough. People need to be able to see what is actually in effect.
>
> I think we’re overthinking this.
>
> We only need to document the settings that SSLSecurityLevel has clearly in our docs, and make sure that "httpd -L” prints out the exact details so no user need ever get confused.
>
>> If we let users define their own classes, it could look like this:
>
> Immediately we’ve jumped into functionality that is beyond Mr/Mrs Normal.
Agreed. If our default is simply ‘industry best practice’ (i.e. what we say it is*) — then Normal will be the new black.
And everyone else is still in the same boat - i.e. having to specify it just like they do today.
All that requires it to make the defaults sane.
Dw.
*: exceed NIST and https://www.keylength.com/ <https://www.keylength.com/> for 5+ years, PFS, A or better at SSLLabs. https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices <https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices>
Re: SSL Policy Definitions
Posted by Stefan Eissing <st...@greenbytes.de>.
> Am 03.05.2017 um 14:20 schrieb Luca Toscano <to...@gmail.com>:
>
> Hi Graham,
>
> 2017-05-03 14:09 GMT+02:00 Graham Leggett <mi...@sharp.fm>:
> On 03 May 2017, at 2:01 PM, Stefan Eissing <st...@greenbytes.de> wrote:
>
> > We seem to all agree that a definition in code alone will not be good enough. People need to be able to see what is actually in effect.
>
> I think we’re overthinking this.
>
> We only need to document the settings that SSLSecurityLevel has clearly in our docs, and make sure that "httpd -L” prints out the exact details so no user need ever get confused.
+1
Having the definitions listed via command line is good enough for me.
>
> I think that in this case documentation is not enough since it tends to quickly fall behind dev commits, plus it would be great for a user to know in a programatic way what are the runtime settings used for SSL (or just to allow admin to manually check/review them).
>
>
> > If we let users define their own classes, it could look like this:
>
> Immediately we’ve jumped into functionality that is beyond Mr/Mrs Normal
>
> True, even if the idea looks great I'd focus only on Mr/Mrs Normal for the moment :)
Agreed.
Re: SSL Policy Definitions
Posted by Luca Toscano <to...@gmail.com>.
Hi Graham,
2017-05-03 14:09 GMT+02:00 Graham Leggett <mi...@sharp.fm>:
> On 03 May 2017, at 2:01 PM, Stefan Eissing <st...@greenbytes.de>
> wrote:
>
> > We seem to all agree that a definition in code alone will not be good
> enough. People need to be able to see what is actually in effect.
>
> I think we’re overthinking this.
>
> We only need to document the settings that SSLSecurityLevel has clearly in
> our docs, and make sure that "httpd -L” prints out the exact details so no
> user need ever get confused.
>
I think that in this case documentation is not enough since it tends to
quickly fall behind dev commits, plus it would be great for a user to know
in a programatic way what are the runtime settings used for SSL (or just to
allow admin to manually check/review them).
>
> > If we let users define their own classes, it could look like this:
>
> Immediately we’ve jumped into functionality that is beyond Mr/Mrs Normal
>
True, even if the idea looks great I'd focus only on Mr/Mrs Normal for the
moment :)
Luca
Re: SSL Policy Definitions
Posted by Graham Leggett <mi...@sharp.fm>.
On 03 May 2017, at 2:01 PM, Stefan Eissing <st...@greenbytes.de> wrote:
> We seem to all agree that a definition in code alone will not be good enough. People need to be able to see what is actually in effect.
I think we’re overthinking this.
We only need to document the settings that SSLSecurityLevel has clearly in our docs, and make sure that "httpd -L” prints out the exact details so no user need ever get confused.
> If we let users define their own classes, it could look like this:
Immediately we’ve jumped into functionality that is beyond Mr/Mrs Normal.
Regards,
Graham
—