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 >
