<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
You've failed to get my points, apparently. Reminds me of me three
years ago before getting hacked into sobered me up.<br>
<br>
<br>
<div class="moz-cite-prefix">On 08/04/2015 02:53 PM, Mike MacCana
wrote:<br>
</div>
<blockquote
cite="mid:CAAfQ1EMXqApSh0yFtM3XEeTG2CLFKOmzoGJ7ddoEq0rVm3mgxA@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
What makes yours any better than that definition?<br>
<br>
<blockquote
cite="mid:CAAfQ1EMXqApSh0yFtM3XEeTG2CLFKOmzoGJ7ddoEq0rVm3mgxA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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>
</div>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAAfQ1EMXqApSh0yFtM3XEeTG2CLFKOmzoGJ7ddoEq0rVm3mgxA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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
moz-do-not-send="true" 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
moz-do-not-send="true" href="https://archive.is/JccUh"
style="font-size:12.8000001907349px" target="_blank">https://archive.is/JccUh</a> from
my original message).</div>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAAfQ1EMXqApSh0yFtM3XEeTG2CLFKOmzoGJ7ddoEq0rVm3mgxA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><snip>
<div>I am very open to discussing other cipher suites that
may provide a fix. <br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAAfQ1EMXqApSh0yFtM3XEeTG2CLFKOmzoGJ7ddoEq0rVm3mgxA@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 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
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>
</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>
</div>
</div>
</blockquote>
<br>
If I remember correctly, "Intermediate" exposes some "medium"
ciphers. <br>
<br>
<blockquote
cite="mid:CAAfQ1EMXqApSh0yFtM3XEeTG2CLFKOmzoGJ7ddoEq0rVm3mgxA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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. <br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
"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.<br>
<br>
<blockquote
cite="mid:CAAfQ1EMXqApSh0yFtM3XEeTG2CLFKOmzoGJ7ddoEq0rVm3mgxA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>Totally happy to use the <a moz-do-not-send="true"
href="http://cipherli.st" target="_blank">cipherli.st</a>
or whatever else fixes the reported issues instead, which
is why I linked to <a moz-do-not-send="true"
href="http://cipherli.st" target="_blank">cipherli.st</a>
in the first place. <br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
You once again missed my point about "Why should we be forced to
test individual ciphers rather than just rely on the groups?"<br>
<br>
<blockquote
cite="mid:CAAfQ1EMXqApSh0yFtM3XEeTG2CLFKOmzoGJ7ddoEq0rVm3mgxA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>However <a moz-do-not-send="true"
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 moz-do-not-send="true"
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>
</div>
</div>
</blockquote>
<blockquote
cite="mid:CAAfQ1EMXqApSh0yFtM3XEeTG2CLFKOmzoGJ7ddoEq0rVm3mgxA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote"><br>
<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>
<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). <br>
</div>
</div>
</div>
</div>
</blockquote>
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.<br>
<br>
<blockquote
cite="mid:CAAfQ1EMXqApSh0yFtM3XEeTG2CLFKOmzoGJ7ddoEq0rVm3mgxA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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. <br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
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?<br>
<br>
<blockquote
cite="mid:CAAfQ1EMXqApSh0yFtM3XEeTG2CLFKOmzoGJ7ddoEq0rVm3mgxA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<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><br>
</div>
<div> - Having better defaults for the people who don't care</div>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<blockquote
cite="mid:CAAfQ1EMXqApSh0yFtM3XEeTG2CLFKOmzoGJ7ddoEq0rVm3mgxA@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> - Linking somewhere downstream (whether Moz or <a
moz-do-not-send="true" 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. <br>
</div>
</div>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
<br>
So once again, you haven't proved how your proposed cipherset is
actually superior to the nginx defaults. I only see detriments:<br>
* Forcing nginx developers to keep this list up to date and
maintained<br>
* Forcing nginx developers to have to keep tabs and constantly
revise the defaults for all security vulnerabilies<br>
* Making understanding the defaults harder for non-experienced
adminisitrators.<br>
<br>
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'.<br>
<br>
<br>
<br>
<br>
Thomas<br>
<br>
</body>
</html>