[PATCH] update default ssl_ciphers value
W-Mark Kubacki
wmark+nginx at hurrikane.de
Tue Aug 4 12:54:54 UTC 2015
Do not specifiy cipher suites, one by one, by name. That's dangerous.
OpenSSL knows groups!
Examples for groups:
- HIGH
- TLSv1.2
… and matching:
- HIGH+kEECDH
- HIGH+kEECDH:HIGH+kEDH:-3DES
Examining their implementation, and ordering them is the task of
security engineers and/or best delegated to the authors of TLS
libraries.
Imagine a cipher suite "falls out of fashion", or an implementation
turns out to be weaker than expected, or new ones get implemented
(hello CHACHA20! see you TLSv1.3!). You don't want to go through those
lists (you shouldn't have used) again nor should you expect that a
regular user will do this (most didn't even care enough to change the
default DHparam).
--
Mark
2015-08-04 0:53 GMT+02:00 Mike MacCana <mike.maccana at gmail.com>:
> Thanks for the quick response again Maxim. You make some excellent points:
>
> 1. Best practices for cipher lists change over time.
> 2. ssl_prefer_server_ciphers is off by default
>
> For now: how about:
> - We use up to date values for NGX_DEFAULT_CIPHERS
> - We turn on ssl_prefer_server_ciphers by default - having the server
> control the negotiation is recommended in every configuration guide
> - We add an up to date ssl_ciphers example to the default config file
> - Above the example, we add a comment with the point you've made above:
>
> # Security note: best practices for ssl_ciphers frequently change over time.
> # Check https://mozilla.github.io/server-side-tls/ssl-config-generator for
> more recent settings
> # ssl_ciphers
> 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
>
> This would resolve the SSL Labs and Chrome warnings that currently show up
> with nginx, but make sure people configuring nginx are aware that they need
> to keep up to date, and shows them where they can get a more recent config.
>
> If the user is lazy and doesn't follow ssl happenings, they're still better
> out of the box. And actually giving them a URL to check might make them be a
> little more security conscious.
>
> How does that sound?
>
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
More information about the nginx-devel
mailing list