On Tue, Aug 4, 2015 at 4:21 PM, Thomas Ward <tew...@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+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. > 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
_______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel
