httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Issac Goldstand <>
Subject Re: SSL and Usability and Safety
Date Wed, 03 May 2017 13:37:06 GMT
On 5/3/2017 4:22 PM, Dirk-Willem van Gulik wrote:
>> 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?
> Dw.

Agreed, it is a whole new land. However, if we truly want a simple
"turnkey" method for MR and Mrs Normal, I don't see any other way that
will have fast-enough turnaround when vulnerabilities are discovered.

There's precedent for this sort of update mechanism inside the ASF with
SpamAssassin.  However, IMHO it doesn't make sense to reach out to them
to hear their thoughts of how sa-upadate deals with that land or
otherwise overthink this until we have some internal consensus that this
is an avenue that we would hypothetically be ok supporting.

If it's not turn-key, I don't see Mr and Mrs normal using it, and then
we could solve this for the rest of our users with a docs update.

The macros ideas are nifty, but I can't think of any use case where, for
example, a sysadmin (most definately NOT mr or mrs normal) would want to
configure multiple sets of macros on a single instance.

View raw message