<div dir="ltr"><div><span style="font-size:12.8000001907349px">> </span><span style="font-size:12.8000001907349px">Examining their implementation, and ordering them is the task of </span><span style="font-size:12.8000001907349px">security engineers</span></div><div><span style="font-size:12.8000001907349px"><br></span></div><div><span style="font-size:12.8000001907349px">Indeed. The ciphersuite ordering is directly from the Mozilla Server Side TLS project. <a href="https://mozilla.github.io/server-side-tls/ssl-config-generator/" target="_blank">https://mozilla.github.io/server-side-tls/ssl-config-generator/</a></span><br></div><div><br></div><div>My understanding is OpenSSLs inbuilt ciphersuite groups (per <a href="https://www.openssl.org/docs/apps/ciphers.html">https://www.openssl.org/docs/apps/ciphers.html</a>) aren't sufficient to implement Mozilla's rationale, see <a href="https://wiki.mozilla.org/Security/Server_Side_TLS#Prioritization_logic" target="_blank">https://wiki.mozilla.org/Security/Server_Side_TLS#Prioritization_logic</a>, hence why Mozilla specify the ciphersuites ordering explicitly. </div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 4, 2015 at 1:54 PM, W-Mark Kubacki <span dir="ltr"><<a href="mailto:wmark+nginx@hurrikane.de" target="_blank">wmark+nginx@hurrikane.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Do not specifiy cipher suites, one by one, by name. That's dangerous.<br>
OpenSSL knows groups!<br>
<br>
Examples for groups:<br>
- HIGH<br>
- TLSv1.2<br>
… and matching:<br>
- HIGH+kEECDH<br>
- HIGH+kEECDH:HIGH+kEDH:-3DES<br>
<br>
Examining their implementation, and ordering them is the task of<br>
security engineers and/or best delegated to the authors of TLS<br>
libraries.<br>
<br>
Imagine a cipher suite "falls out of fashion", or an implementation<br>
turns out to be weaker than expected, or new ones get implemented<br>
(hello CHACHA20! see you TLSv1.3!). You don't want to go through those<br>
lists (you shouldn't have used) again nor should you expect that a<br>
regular user will do this (most didn't even care enough to change the<br>
default DHparam).<br>
<span><font color="#888888"><br>
--<br>
Mark<br>
</font></span><div><div><br>
2015-08-04 0:53 GMT+02:00 Mike MacCana <<a href="mailto:mike.maccana@gmail.com" target="_blank">mike.maccana@gmail.com</a>>:<br>
> Thanks for the quick response again Maxim. You make some excellent points:<br>
><br>
> 1. Best practices for cipher lists change over time.<br>
> 2. ssl_prefer_server_ciphers is off by default<br>
><br>
> For now: how about:<br>
>  - We use up to date values for NGX_DEFAULT_CIPHERS<br>
>  - We turn on ssl_prefer_server_ciphers by default - having the server<br>
> control the negotiation is recommended in every configuration guide<br>
>  - We add an up to date ssl_ciphers example to the default config file<br>
>  - Above the example, we add a comment with the point you've made above:<br>
><br>
> # Security note: best practices for ssl_ciphers frequently change over time.<br>
> # Check <a href="https://mozilla.github.io/server-side-tls/ssl-config-generator" rel="noreferrer" target="_blank">https://mozilla.github.io/server-side-tls/ssl-config-generator</a> for<br>
> more recent settings<br>
> # ssl_ciphers<br>
> ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA256:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!SRP:!CAMELLIA<br>
><br>
> This would resolve the SSL Labs and Chrome warnings that currently show up<br>
> with nginx, but make sure people configuring nginx are aware that they need<br>
> to keep up to date, and shows them where they can get a more recent config.<br>
><br>
> If the user is lazy and doesn't follow ssl happenings, they're still better<br>
> out of the box. And actually giving them a URL to check might make them be a<br>
> little more security conscious.<br>
><br>
> How does that sound?<br>
><br>
><br>
</div></div><div><div>> _______________________________________________<br>
> nginx-devel mailing list<br>
> <a href="mailto:nginx-devel@nginx.org" target="_blank">nginx-devel@nginx.org</a><br>
> <a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
<br>
_______________________________________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org" target="_blank">nginx-devel@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a></div></div></blockquote></div><br></div></div>