<div dir="ltr"><div>On Mon, Aug 3, 2015 at 6:31 PM, Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span> wrote:<br></div><div class="gmail_extra"><div class="gmail_quote"><br></div><div class="gmail_quote"><snip><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Overral answer:<br>
<br>
No, thanks.  And even if some of the over concens were valid, the<br>
answer would be the same.  The default is kept good enough to be<br>
generally usable, and it doesn't try to account for any recent<br>
cryptographic findings, nor it tries to enforce any chipher<br>
preferences on server.  This approach is believed to be better in<br>
a quickly changing world assuming the administrator is not<br>
tracking recent attacks and changes the configuration accordingly.<br></blockquote><div><br></div><div><span style="font-size:12.8000001907349px">Thanks for the quick response Maxim. To clarify, t</span><span style="font-size:12.8000001907349px">here's currently 3 issues regarding cipher lists in nginx :</span></div><div><br></div><div><span style="font-size:12.8000001907349px"> - </span><span style="font-size:12.8000001907349px">NGX_DEFAULT_CIPHERS has insecure defaults. Y</span><span style="font-size:12.8000001907349px">ou mention '</span><span style="font-size:12.8000001907349px">there is no preference enforced by </span><span style="font-size:12.8000001907349px">nginx</span><span style="font-size:12.8000001907349px"> by default' - are you saying </span><span style="font-size:12.8000001907349px">NGX_DEFAULT_CIPHERS</span><span style="font-size:12.8000001907349px"> is unused?</span></div><div><div><span style="font-size:12.8000001907349px"> - the example configuration in the config file is insecure</span></div><div><span style="font-size:12.8000001907349px"> - documentation which incorrectly states that the example does not need to be modified</span></div><div><br></div><div>> <span style="font-size:12.8000001907349px">This approach is believed to be better in </span><span style="font-size:12.8000001907349px">a quickly changing world assuming the administrator is not </span><span style="font-size:12.8000001907349px">tracking recent attacks and changes the configuration accordingly.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Should this mean 'assuming the administrator is tracking recent attacks'? Because:</span></div><div><span style="font-size:12.8000001907349px"> - If you assume the administrator is *not* tracking recent attacks then the example config should be secure. </span></div><div><span style="font-size:12.8000001907349px"> - </span><span style="font-size:12.8000001907349px">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 - </span><span style="font-size:12.8000001907349px">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.</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">What specifically does nginx lose from fixing the insecure default config, shipping a more current example, and fixing the incorrect docs?</span></div></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Mike</span></div></div><br></div></div>