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?

> -Stefan

Reply via email to