httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dirk-Willem van Gulik <>
Subject Re: SSL and Usability and Safety
Date Wed, 03 May 2017 12:59:15 GMT

> 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 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 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.

>> We’d wrap this into a simple policy document. Promise ourselfves that we’d check
this every release and at least once a year review it. And have a small list of the versions
currently meeting or exceeding our policy.
>> And this is the setting you get when you do ‘SSLEngine On’.
> To me this doesn't address the time lags between shipping it in source,
> and it getting implemented on the machine.  I don't see it as superior
> in any way to, say, putting the recommended settings in the online docs
> and updating that from time to time - moreso when that update is in
> response to a new vulnerability.

I think we should make sure that 1) any release that goes out meets or exceeds industry practice
(e.g. the BSI 2017 recommendation up to 2022); and 2) that we keep a list of versions that
are still `current’ enough; and that accomodates what we since their release learned. Typically
meaning - update to version X.Y.

View raw message