<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 4, 2015 at 4:21 PM, Thomas Ward <span dir="ltr"><<a href="mailto:teward@dark-net.net" target="_blank">teward@dark-net.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div 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></div></blockquote><div><br></div><div>Understood. And I appreciate that the same issue coming up repeatedly is annoying. The fastest way to fix it is to use better defaults ;^).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
This implies that the administrators of a given server are going to
routinely check and update their config as the security battlefront
changes. </div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">You also assume Mozilla's rationale is the
correct one. </div></blockquote><div><br></div><div>No, I attached a report which complained of specific vulnerabilities in the default set up. See<span style="font-size:12.8000001907349px"> </span><a href="https://archive.is/PfOGL" style="font-size:12.8000001907349px" target="_blank">https://archive.is/PfOGL</a> from my original message.</div><div><br></div><div>I mentioned Mozilla's cipher lists fixes the vulnerabilities, because it does (see <a href="https://archive.is/JccUh" style="font-size:12.8000001907349px" target="_blank">https://archive.is/JccUh</a> from my original message).</div><div><br></div><div>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:</div><div><br></div><div><div><div style="font-size:12.8000001907349px">> 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:</div><div style="font-size:12.8000001907349px"> - <a href="https://wiki.mozilla.org/Security/Server_Side_TLS#Prioritization_logic" target="_blank">https://wiki.mozilla.org/Security/Server_Side_TLS#Prioritization_logic</a> (used for this patch)<br></div><div style="font-size:12.8000001907349px"> - <a href="https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html" target="_blank">https://raymii.org/s/tutorials/Strong_SSL_Security_On_nginx.html</a> (used for <a href="http://cipherli.st/" target="_blank">cipherli.st</a>)<br></div><div style="font-size:12.8000001907349px"> - <a href="https://github.com/nodejs/node/commit/5755fc099f883293530406c423bda47414834057" target="_blank">https://github.com/nodejs/node/commit/5755fc099f883293530406c423bda47414834057</a> (node doing the same thing recently)<br></div></div></div><div><br></div><div>I am very open to discussing other cipher suites that may provide a fix.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 4, 2015 at 1:54 PM,
W-Mark Kubacki <span dir="ltr"><<a 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></span>
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></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
Well, let's do a comparison, then</div></blockquote><div><br></div><div>***Exactly***! I did this in my original message! </div><div><br></div><div>I suspect the confusion is that people simply didn't see the 'before' and 'after' scan results attached to the patch. </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
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 <a href="http://cipherli.st" target="_blank">cipherli.st</a>. 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 href="http://testing.hellnet.io/ssldata/SSL-Server-Test_testing.hellnet.io_CipherLi.st.pdf" target="_blank">http://testing.hellnet.io/ssldata/SSL-Server-Test_testing.hellnet.io_CipherLi.st.pdf</a><span><br>
<br>
<blockquote 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></span>
You fail to consider the previously stated issue of this removing
the ability for OpenSSL 'supported' cipher groups to be used in this
case. </div></blockquote><div><br></div><div>Totally happy to use the <a href="http://cipherli.st" target="_blank">cipherli.st</a> or whatever else fixes the reported issues instead, which is why I linked to <a href="http://cipherli.st" target="_blank">cipherli.st</a> in the first place. </div><div><br></div><div>However <a href="http://cipherli.st" target="_blank">cipherli.st</a>, like Mozilla, uses individual ciphers for it's legacy config - click 'Yes, give me a ciphersuite that works with legacy / old software.' on <a href="https://cipherli.st" target="_blank">https://cipherli.st</a>. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">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. </div></blockquote><div><br></div><div>Agreed. Using the <a href="http://cipherli.st" target="_blank">cipherli.st</a> 'legacy' config, rather than the high security one, would allow it to work out of the box. </div><div><br></div><div>The <a href="http://cipherli.st" target="_blank">cipherli.st</a> legacy config doesn't use groups, but shipping a secure config should take precedence over the ability to use groups. </div><div><br></div><div>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 <a href="http://cipherli.st" target="_blank">cipherli.st</a> and node.js because I *don't* believe that Mozilla guidelines are the rule.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">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. </div></blockquote><div><br></div><div>The value is in passing the same scan that you and I both ran (weirdly we got slightly different results, which I'm investigating). </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">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></div></blockquote><div><br></div><div>Totally agreed, I'm happy to do this work if needed. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
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?
</div></blockquote><div><br></div><div>Agreed, very little. Hence:</div><div><br></div><div> - Having better defaults for the people who don't care</div><div> - Linking somewhere downstream (whether Moz or <a href="http://cipherli.st" target="_blank">cipherli.st</a> or elsewhere) where people who do care can get an updated ciphersuite list in the example config. </div><div><br></div><div>Mike</div></div></div></div>