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