> Am 03.05.2017 um 15:46 schrieb Issac Goldstand <mar...@beamartyr.net>:
> 
> On 5/3/2017 4:28 PM, Stefan Eissing wrote:
>> 
>>> Am 03.05.2017 um 15:22 schrieb Dirk-Willem van Gulik <di...@webweaving.org>:
>>> 
>>>> 
>>>> On 3 May 2017, at 15:14, Issac Goldstand <mar...@beamartyr.net> wrote:
>>>> 
>>>> On 5/3/2017 3:59 PM, Dirk-Willem van Gulik wrote:
>>>>> 
>>>>>> On 3 May 2017, at 14:53, Issac Goldstand <mar...@beamartyr.net
>>>>>> <mailto:mar...@beamartyr.net>> wrote:
>>>>>> 
>>>>>> On 5/3/2017 12:46 PM, Dirk-Willem van Gulik wrote:
>>>>>>> On 3 May 2017, at 10:03, Issac Goldstand <mar...@beamartyr.net
>>>>>>> <mailto:mar...@beamartyr.net>> wrote:
>>>>>>>> 
>>>>>>>> +1 on the idea
>>>>>>>> 
>>>>>>>> So far I'm -0 about all of the proposed implementations for 2 reasons:
>>>>>>>> 
>>>>>>>> 1) Mr and Mrs normal (whom are our primary customers in the original
>>>>>>>> proposal) usually download Apache from their distro or some other
>>>>>>>> binary.  Their Apache sources are usually not up-to-date, and in the
>>>>>>>> scenario that a new vulnerability is found it would take ages to
>>>>>>>> propagate to them, anyway
>>>>>>>> 
>>>>>>>> 2) For those users who are comfortable building their own source, they
>>>>>>> ….
>>>>>>> 
>>>>>>> So how about ‘us’ taking the lead here. 
>>>>>> 
>>>>>> That's the part I was always +1 on :)
>>>>>> 
>>>>>>> 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. 
>>>>>> 
>>>>>> The problem is, that we don't know what's going to be good going forward
>>>>>> five years, and IMHO the best standards are shaped at least equally by
>>>>>> removing "negatives" often because of high-risk vulnerabilities, as by
>>>>>> adding new "positives" due to new available ciphers/tools
>>>>> 
>>>>> Right - so I think there are two things
>>>>> 
>>>>> 1)the general advice of NIST et.al. - summarized nicely at:
>>>>> 
>>>>> https://www.keylength.com
>>>>> 
>>>>> which tells us what our `best acceptable’ choises are in any release
>>>>> going out and their likely vailidy for the next 5 years.
>>>>> 
>>>>> And then there is our response to things that become known; such as
>>>>> vulnerability - for which we have a proven update proces that is
>>>>> dovetailed by us sending mail to announce, the security mailing lists
>>>>> and similar outreach.
>>>> 
>>>> Which, IMHO, we can safely expect Mr and Mrs Normal to never see.  Mr
>>>> and Mrs normal aren't on the mailing list of most pieces of software,
>>>> even if they use them.
>>>> 
>>>> If we truly want to cater to them (and by doing so, do our part in
>>>> advocating a safer and more secure internet) then I maintain that we'd
>>>> need to do better.
>>> 
>>> Right - but then we are in the land of automatic updates; binary package 
>>> fetching and what not ? Or at the very least - pulling down a file over the 
>>> internet from ‘us’ that is sufficiently protected yet robust, etc ?
>>> 
>>> That is a whole new land?
>> 
>> I think there is a step in between. If we make our releases security 
>> settings better and users opt-in, we can with every release improve that. 
>> Nothing to change in the processes here.
>> 
>> In case our settings prove to have a fault, there is always the possibility 
>> for 
>> a) ship a new release
>> b) specify an immediate workaround by using the existing SSL* directives 
>> appropriately
> 
> But we already (potentially) do that with the maintained
> conf/extra/httpd-ssl.conf don't we?  How are all of the ideas we've been
> floating more than just sugar coating for the recommendations we already
> maintain there?

Maybe I have not explained well enough what I propose to add to the server.

a) add 2 new SSL directives: SSLSecurityPolicy and SSLPolicyOverride
b) make no change in behaviour/defaults when no SSLSecurityPolicy is configured
c) On a SSLSecurityPolicy, change the defaults for certain SSL* directives in 
alignment with the chosen policy. (On config merging, this will reset these 
directives effectively.)
d) On "SSLPolicyOverride deny", fail configurations where SSL* directives try 
to change what a policy defines (this applies also on config merging).

This brings the following benefits to the users:
1. It's easier to communicate your site has security policy "modern" than 
mentioning 9 directives (see 
https://mozilla.github.io/server-side-tls/ssl-config-generator/) where one 
directive is a line of 274 chars of gibberish (important one, but still)
2. It's easier to get right, and thus will provide a safer internet
3. We can adapt it in releases to reflect the current state of the art in TLS 
and browser (and our server) techology. Making the internet more secure.
4. In a setup with many config files, you can make certain that the policy 
applies and is not overwritten (if you so desire. No matter what gets included 
from somewhere else later).

If we can get a rough consensus here that this additional feature, not 
impacting existing sites, is of value to users (not all, but a sizeable chunk. 
hell, i want to use it myself), then I will make a patch. And we continue from 
there.

-Stefan

Reply via email to