[PATCH] update default ssl_ciphers value

[Thomas Ward]

You've failed to get my points, apparently.  Reminds me of me three
years ago before getting hacked into sobered me up.


On 08/04/2015 02:53 PM, Mike MacCana wrote:
> On Tue, Aug 4, 2015 at 4:21 PM, Thomas Ward <teward at dark-net.net
> <mailto:teward at 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 ;^).

No, wrong.  The current defaults are sane.  "HIGH" has this definition
by OpenSSL's standards: "high" encryption cipher suites. This currently
means those with key lengths larger than 128 bits, and some cipher
suites with 128-bit keys.

What makes yours any better than that definition?

>
>     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 just shift the work to the developers in your proposal.  That
doesn't reduce overall work load, NOR does it take into account that
ciphersuites change over time.

Hypothetical:  I come out with a brand new cipher that is tested,
stabbed at, etc. and is considered "secure".  It's included in OpenSSL
(and others, but lets use OpenSSL for now) 1.5.0.  Your cipher strings
remain used in 'nginx'.  'nginx' no longer can support the new cipher
(added to "HIGH" by the OpenSSL people), and now it's up to the NGINX
developers to bother checking to see if the cipherstrings that are
recommended change.

You've done nothing to reduce workload overall - you are just making
nginx developers, and frankly downstream packagers, do the work.  That
isn't an improvement, it's a detriment.  Especially if "HIGH" adapts to
include new ciphers.

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

Again, *wrong*.  Unless the dh_param defaults are also being modified,
which it suggests that may eventually possibly happen based on Maxim's
earlier statements, the DH strength issue remains.  Your patch doesn't
resolve that, so you still get capped at B.

> <snip>
> I am very open to discussing other cipher suites that may provide a fix.

What specifically do your changes fix?  They don't address the DH
problem, which is the only blatantly obvious 'vulnerability' that your
"Before" image shows.  DH parameter strength changes are the only way to
fix that, and that has to be provided separately by admins, not
necessarily by nginx.

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

If I remember correctly, "Intermediate" exposes some "medium" ciphers. 

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

"Before" vs. "After" with no details on the specific changes made. 
Assumptions can therefore be made you made other changes in the process,
since the cipher string you proposed still uses DHE ciphers, and the
default dhparam hasn't changed.

>
> Totally happy to use the cipherli.st <http://cipherli.st> or whatever
> else fixes the reported issues instead, which is why I linked to
> cipherli.st <http://cipherli.st> in the first place.

You once again missed my point about "Why should we be forced to test
individual ciphers rather than just rely on the groups?"

>
> However cipherli.st <http://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. 
>
>
> 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).
Consider OpenSSL versions here, you don't define your testing
environment, I did.  To get actually matching baselines we need to
compare apples-to-apples to account for minor changes.

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

You haven't answered my initial question, nor others' questions, about
how this is actually beneficial or fixes things.  Why should work be
included when there's no specific details?

>  
>
>     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? 
>
>
>
>  - Having better defaults for the people who don't care

Still needs the NGINX developers to act as security engineers to
determine a "sane" cipherset, when the "HIGH" cipherset, while rejecting
all else, is sane for today's SSL environment at this time.

>  - Linking somewhere downstream (whether Moz or cipherli.st
> <http://cipherli.st> or elsewhere) where people who do care can get an
> updated ciphersuite list in the example config.

Discussed downstream, ultimately rejected as a "Why should we make the
users do work", especially when security-centric admins are aware of
these types of sites.


So once again, you haven't proved how your proposed cipherset is
actually superior to the nginx defaults.  I only see detriments:
* Forcing nginx developers to keep this list up to date and maintained
* Forcing nginx developers to have to keep tabs and constantly revise
the defaults for all security vulnerabilies
* Making understanding the defaults harder for non-experienced
adminisitrators.

Don't get me wrong, I have suggestions for changing the defaults too,
mostly involving adding several negations to this, but actually defining
every single cipher to use is bad practice for 'defaults'.




Thomas

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