On Mon, Aug 3, 2015 at 6:31 PM, Maxim Dounin <[email protected]> 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. You mention 'there is no preference enforced by nginx by default' - are you saying NGX_DEFAULT_CIPHERS is unused? - the example configuration in the config file is insecure - documentation which incorrectly states that the example does not need to be modified > 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. - 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. What specifically does nginx lose from fixing the insecure default config, shipping a more current example, and fixing the incorrect docs? Mike
_______________________________________________ nginx-devel mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx-devel
