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+ng...@hurrikane.de <mailto:wmark+ng...@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
_______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
