[PATCH] update default ssl_ciphers value

[Mike MacCana]

On Tue, Aug 4, 2015 at 4:21 PM, Thomas Ward <teward at dark-net.net> wrote:

> This discussion has been done before, elsewhere, and the consensus was to
> stick with the defaults (for Debian and Ubuntu nginx).
>

Understood. And I appreciate that the same issue coming up repeatedly is
annoying. The fastest way to fix it is to use better defaults ;^).

This implies that the administrators of a given server are going to
> routinely check and update their config as the security battlefront
> changes.
>

Not at all: I mentioned earlier that I doubt most nginx users do this, and
also mentioned that using a more secure defaults will help these people.


> You also assume Mozilla's rationale is the correct one.
>

No, I attached a report which complained of specific vulnerabilities in the
default set up. See https://archive.is/PfOGL from my original message.

I mentioned Mozilla's cipher lists fixes the vulnerabilities, because it
does (see https://archive.is/JccUh from my original message).

However I do agree there are other sources which may also be appropriate
fixes, which is why I also attached three different cipher rationales in my
original report. Quoting the original message:

> The changes in the patch above are already widely used by Mozilla Server
Side TLS users, but if further discussion is needed on prioritisation logic
then the following may be  helpful:
 - https://wiki.mozilla.org/Security/Server_Side_TLS#Prioritization_logic (used
for this patch)
 - https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html (used
for cipherli.st)
 -
https://github.com/nodejs/node/commit/5755fc099f883293530406c423bda47414834057
(node
doing the same thing recently)

I am very open to discussing other cipher suites that may provide a fix.


> 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!
>>
> This is good advice!  OpenSSL's defaults in those groups will dynamically
> change as ciphers emerge or change.  As such, "HIGH", "HIGH+kEECDH", etc.
> will always update as ciphers are deprecated, added, etc.
>

Alas there's no inbuilt OpenSSL group with 'intermediate' compatibility
that passes SSL Labs with an A or higher. See below. Happy to use one if
you find it.

Well, let's do a comparison, then
>

***Exactly***! I did this in my original message!

I suspect the confusion is that people simply didn't see the 'before' and
'after' scan results attached to the patch.

Now let's break the aforementioned recommendations, ignore legacy support,
> put a 2048-bit DHPARAM into place, and only use the two cipher groups from
> cipherli.st.  This gets an A rating, and there's no forward secrecy
> problems, AND Chrome doesn't complain.  But, I totally remove all the
> aforementioned recommendations and now have to manage this effectively by
> myself.
> http://testing.hellnet.io/ssldata/SSL-Server-Test_testing.hellnet.io_CipherLi.st.pdf
>
> > 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.
>> >
>>
> You fail to consider the previously stated issue of this removing the
> ability for OpenSSL 'supported' cipher groups to be used in this case.
>

Totally happy to use the cipherli.st or whatever else fixes the reported
issues instead, which is why I linked to cipherli.st in the first place.

However cipherli.st, like Mozilla, uses individual ciphers for it's legacy
config - click  'Yes, give me a ciphersuite that works with legacy / old
software.' on https://cipherli.st.


> And since the typical user *is* lazy and would probably rather have it
> work out of the box, they aren't going to be checking what's 'strong' for
> ciphers and such.
>

Agreed. Using the cipherli.st 'legacy' config, rather than the high
security one, would allow it to work out of the box.

The cipherli.st legacy config doesn't use groups, but shipping a secure
config should take precedence over the ability to use groups.

Thomas you're on the right track. You're doing the same testing I did in
the original patch,and linking to the same tools. I linked cipherli.st and
node.js because I *don't* believe that Mozilla guidelines are the rule.

There's no value in going away from the group-based definitions to the
> individual ciphers, since you now have to constantly check each individual
> cipher to determine if it's still 'good' or not.
>

The value is in passing the same scan that you and I both ran (weirdly we
got slightly different results, which I'm investigating).


> That adds additional work to both NGINX developers to have to constantly
> check the 'good ciphers lists' and constantly make revisions as the SSL/TLS
> landscape changes.
>

Totally agreed, I'm happy to do this work if needed.


> And, for sysadmin simplicity sake for the newer sysadmins not fluent in
> OpenSSL and cipher naming, "HIGH" indicates high strength ciphers.  What
> does " ECDHE-RSA-AES128-GCM-SHA256" really mean to a non-fluent sysadmin?
>

Agreed, very little. Hence:

 - Having better defaults for the people who don't care
 - Linking somewhere downstream (whether Moz or cipherli.st or elsewhere)
where people who do care can get an updated ciphersuite list in the example
config.

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20150804/4f5c6a99/attachment.html>