Hello! On Mon, Aug 03, 2015 at 08:51:07PM +0100, Mike MacCana wrote:
> On Mon, Aug 3, 2015 at 6:31 PM, Maxim Dounin <mdou...@mdounin.ru> wrote: > > <snip> > > > > > Overral answer: > > > > No, thanks. And even if some of the over concens were valid, the > > answer would be the same. The default is kept good enough to be > > generally usable, and it doesn't try to account for any recent > > cryptographic findings, nor it tries to enforce any chipher > > preferences on server. This approach is believed to be better in > > a quickly changing world assuming the administrator is not > > tracking recent attacks and changes the configuration accordingly. > > > > Thanks for the quick response Maxim. To clarify, there's currently 3 issues > regarding cipher lists in nginx : > > - NGX_DEFAULT_CIPHERS has insecure defaults. This is not true. See my previous message for detailed explanation on why your concerns are invalid. > You mention 'there is no > preference enforced by nginx by default' - are you saying > NGX_DEFAULT_CIPHERS is unused? Read: default for ssl_prefer_server_ciphers is off, see http://nginx.org/r/ssl_prefer_server_ciphers. > - the example configuration in the config file is insecure This is not true, see above. > - documentation which incorrectly states that the example does not need to > be modified The documentation says what's we think is a good enough strategy in general, see below for a more detailed explanation. > > This approach is believed to be better in a quickly changing world > assuming the administrator is not tracking recent attacks and changes the > configuration accordingly. > > Should this mean 'assuming the administrator is tracking recent attacks'? > Because: > - If you assume the administrator is *not* tracking recent attacks then > the example config should be secure. It is. > - If you assume the administrator *is* tracking recent attacks - which is > a bad assumption, as many nginx users are not system administrators but > rather web developers with little to no interest in ssl - then it's still > beneficial to provide a more recent cipher list, as it stops nginx users > having to fix the software out of the box. The default configuration provided is as secure as it can be, assuming the rate at which nginx is generally updated and the rate at which various new attacks tend to appear. So, unless you are closely tracking recent attacks, it's believed to be better strategy to stick with the default as provided, which usually results in better security in long term. > What specifically does nginx lose from fixing the insecure default config, > shipping a more current example, and fixing the incorrect docs? As previously said, the default is not insecure, and the documentation isn't incorrect. Moreover, the default is believed to be better than "a more current example" in a long run, as "a more current example" tends to be new very several months, and sometimes exactly opposite to a previous "more current" one. -- Maxim Dounin http://nginx.org/ _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
