<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
This discussion has been done before, elsewhere, and the consensus
was to stick with the defaults (for Debian and Ubuntu nginx).<br>
<br>
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.<br>
<br>
<br>
<div class="moz-cite-prefix">On 08/04/2015 09:52 AM, Mike MacCana
wrote:<br>
</div>
<blockquote
cite="mid:CAAfQ1EPs-Nh23z85egiKwex8oUKyXMGDWGHSeZ_xo0sxf6C2VA@mail.gmail.com"
type="cite">
<div dir="ltr">My understanding is OpenSSLs inbuilt ciphersuite
groups (per <a moz-do-not-send="true"
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
moz-do-not-send="true"
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.
<br>
</div>
</blockquote>
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.<br>
<blockquote
cite="mid:CAAfQ1EPs-Nh23z85egiKwex8oUKyXMGDWGHSeZ_xo0sxf6C2VA@mail.gmail.com"
type="cite">
<div dir="ltr">
<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
moz-do-not-send="true"
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>
</blockquote>
</div>
</div>
</div>
</blockquote>
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.<br>
<blockquote
cite="mid:CAAfQ1EPs-Nh23z85egiKwex8oUKyXMGDWGHSeZ_xo0sxf6C2VA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<snip><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>
</blockquote>
</div>
</div>
</div>
</blockquote>
This is also the same logic, and is VALID advice.<br>
<span></span><br>
<blockquote
cite="mid:CAAfQ1EPs-Nh23z85egiKwex8oUKyXMGDWGHSeZ_xo0sxf6C2VA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>
<snip><br>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
<blockquote
cite="mid:CAAfQ1EPs-Nh23z85egiKwex8oUKyXMGDWGHSeZ_xo0sxf6C2VA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>
> 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>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
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:
<a class="moz-txt-link-freetext" href="http://testing.hellnet.io/ssldata/SSL-Server-Test_testing.hellnet.io_TotallyBadSSL.pdf">http://testing.hellnet.io/ssldata/SSL-Server-Test_testing.hellnet.io_TotallyBadSSL.pdf</a><br>
<br>
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.
<a class="moz-txt-link-freetext" href="http://testing.hellnet.io/ssldata/SSL-Server-Test_testing.hellnet.io_NGINXDefaults.pdf">http://testing.hellnet.io/ssldata/SSL-Server-Test_testing.hellnet.io_NGINXDefaults.pdf</a><br>
<br>
Third, the nginx defaults plus a 2048-bit DH params file. Grade
becomes A-. Even better, and Chrome still doesn't complain!
<a class="moz-txt-link-freetext" href="http://testing.hellnet.io/ssldata/SSL-Server-Test_testing.hellnet.io_NGINXDefaultsPlusDHPARAM.pdf">http://testing.hellnet.io/ssldata/SSL-Server-Test_testing.hellnet.io_NGINXDefaultsPlusDHPARAM.pdf</a><br>
<br>
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.
<a class="moz-txt-link-freetext" href="http://testing.hellnet.io/ssldata/SSL-Server_Test_testing.hellnet.io_Proposed.pdf">http://testing.hellnet.io/ssldata/SSL-Server_Test_testing.hellnet.io_Proposed.pdf</a><br>
<br>
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:
<a class="moz-txt-link-freetext" href="http://testing.hellnet.io/ssldata/SSL-Server-Test_testing.hellnet.io_ProposedPlusDHPARAM.pdf">http://testing.hellnet.io/ssldata/SSL-Server-Test_testing.hellnet.io_ProposedPlusDHPARAM.pdf</a><br>
<br>
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.
<a class="moz-txt-link-freetext" href="http://testing.hellnet.io/ssldata/SSL-Server-Test_testing.hellnet.io_CipherLi.st.pdf">http://testing.hellnet.io/ssldata/SSL-Server-Test_testing.hellnet.io_CipherLi.st.pdf</a><br>
<br>
<blockquote
cite="mid:CAAfQ1EPs-Nh23z85egiKwex8oUKyXMGDWGHSeZ_xo0sxf6C2VA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>
> 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>
></div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
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).<br>
<br>
--<br>
<br>
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:<br>
* One, you are ignoring the advice from multiple other individuals -
advice which is actually valid.<br>
* Two, you assume Mozilla's guidelines are the rule, rather than
just a guideline. That's not actually the case.<br>
* 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.<br>
<br>
And, for sysadmin simplicity sake for the newer sysadmins not fluent
in OpenSSL and cipher naming, "HIGH" indicates high strength
ciphers. What does "
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
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.<br>
<br>
<br>
Just my two cents on this.<br>
<br>
<br>
------<br>
Thomas<br>
<br>
</body>
</html>