[PATCH] update default ssl_ciphers value

[Thomas Ward]

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

Effectively though, I think the point was missed by you, Mike.  So let
me put in my two cents.  If you merely want the summary of all the text
below, go to the bottom of this message and read.


On 08/04/2015 09:52 AM, Mike MacCana wrote:
> 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.
This implies that the administrators of a given server are going to
routinely check and update their config as the security battlefront
changes.  We aren't necessarily catering to that niche of
highly-diligent server administrators, but to those that're going to
stage servers and then not bother to necessarily check the ciphers that
are "strong".  You also assume Mozilla's rationale is the correct one. 
Different security engineers will give you different answers of "What is
the most secure?" in practice.  Mozilla's guidelines are just their
guidelines, not the rule.
>
> On Tue, Aug 4, 2015 at 1:54 PM, W-Mark Kubacki
> <wmark+nginx at hurrikane.de <mailto: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.
>
>     <snip>
>
>     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).
>
This is also the same logic, and is VALID advice.

>     <snip>
>

>     > 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.
>

Well, let's do a comparison, then, and I'll make my point observed, as
well as the others above!  Note that these PDFs here in these links are
generated by Google Chrome, in case you're wondering, and stored on the
same testing environment, but with the strongest set of these for
ciphers/settings.  These links will remain up until I destroy the EC2
box, so it'll be about six months before I get rid of them.  The test
system was an Ubuntu 14.04 LTS x64 OS running on an Amazon EC2 micro
instance, using the nginx.org Ubuntu repository for the Mainline
packages.  So we're on the latest Mainline release, with a commonly used
OS and OpenSSL set.  The web browser used for testing is Chrome 64bit
44.0.2403.125.

First, the "absolutely completely insanely you-should-be-beaten-for-this
bad" configuration.  This is what I have on my honeypot box, but this
was not actually my honeypot.  Since it's so bad, it's got Grade F.  I
didn't bother testing Chrome with this because I know it will complain:
http://testing.hellnet.io/ssldata/SSL-Server-Test_testing.hellnet.io_TotallyBadSSL.pdf

Second, the nginx defaults.  The defaults won't include the dhparam of a
decent size, so it gets capped to Grade B.  We also have a forward
secrecy error.  Not bad, though.  Also, Chrome isn't complaining.
http://testing.hellnet.io/ssldata/SSL-Server-Test_testing.hellnet.io_NGINXDefaults.pdf

Third, the nginx defaults plus a 2048-bit DH params file.  Grade becomes
A-.  Even better, and Chrome still doesn't complain! 
http://testing.hellnet.io/ssldata/SSL-Server-Test_testing.hellnet.io_NGINXDefaultsPlusDHPARAM.pdf

Fourth, your proposed ciphers to be set.  It still gets Grade capped to
B because there's no DHPARAM of a suitable size, and there's still a
forward secrecy error, and Chrome's not complaining.  So this didn't fix
anything.
http://testing.hellnet.io/ssldata/SSL-Server_Test_testing.hellnet.io_Proposed.pdf

Fifth, Your same proposed cipher set, plus the 2048-bit DH params file
included gets an A-, which is where the nginx defaults plus a dhparam
file.  Still got a forward secrecy error, and Chrome's still not
complaining: 
http://testing.hellnet.io/ssldata/SSL-Server-Test_testing.hellnet.io_ProposedPlusDHPARAM.pdf

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. 
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.  The security-conscious group are going to be on
top of this anyways.  The average user will not.  Using a long string of
specific ciphers is bad, for all the reasons that have been mentioned
before (so I will not repeat those reasons here).

--

So, what's the point of this mini tirade and multiple links?  From my
perspective, the moral of the story, and my analysis, is as follows:
* One, you are ignoring the advice from multiple other individuals -
advice which is actually valid.
* Two, you assume Mozilla's guidelines are the rule, rather than just a
guideline.  That's not actually the case.
* Three, your proposed cipher sets don't really add any real value to
the already existing defaults.  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.  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.

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?  This is also one key part of the argument downstream against
putting the longer cipher strings into the downstream-packaged
configurations.  That same argument applies here if someone's trying to
understand the default cipherstring set from the documentation.


Just my two cents on this.


------
Thomas

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