[PATCH] update default ssl_ciphers value

[Mike MacCana]

> Examining their implementation, and ordering them is the task of security
engineers

Indeed. The ciphersuite ordering is directly from the Mozilla Server Side
TLS project. https://mozilla.github.io/server-side-tls/ssl-config-generator/

My understanding is OpenSSLs inbuilt ciphersuite groups (per
https://www.openssl.org/docs/apps/ciphers.html) aren't sufficient to
implement Mozilla's rationale, see
https://wiki.mozilla.org/Security/Server_Side_TLS#Prioritization_logic,
hence why Mozilla specify the ciphersuites ordering explicitly.

On Tue, Aug 4, 2015 at 1:54 PM, W-Mark Kubacki <wmark+nginx at hurrikane.de>
wrote:

> 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
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20150804/4b539286/attachment.html>