On 5/3/2017 12:46 PM, Dirk-Willem van Gulik wrote: > On 3 May 2017, at 10:03, Issac Goldstand <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 > 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. > > Everything else stays as is. > > Dw >
