httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Eissing <>
Subject Re: SSL and Usability and Safety
Date Wed, 03 May 2017 13:28:12 GMT

> Am 03.05.2017 um 15:22 schrieb Dirk-Willem van Gulik <>:
>> On 3 May 2017, at 15:14, Issac Goldstand <> wrote:
>> On 5/3/2017 3:59 PM, Dirk-Willem van Gulik wrote:
>>>> On 3 May 2017, at 14:53, Issac Goldstand <
>>>> <>> wrote:
>>>> On 5/3/2017 12:46 PM, Dirk-Willem van Gulik wrote:
>>>>> On 3 May 2017, at 10:03, Issac Goldstand <
>>>>> <>> 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
>>>>>> 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,
>>>>> ….
>>>>> 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
>>>>> 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 - summarized nicely at:
>>> 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


View raw message