On 08/25/2016 03:34 PM, William A Rowe Jr wrote:
My 2c...
Exclusion lists are far preferable to allow lists. .conf files seem
to persist for a decade and longer. There is no anticipating what
will be added to the list of unwise ciphers a year from now, but that
goes for an explicit list or for an exception list.
I want to make sure I'm reading you correctly -- the config we're
discussing is in a snippet under the heading "Cipher Suites and
Enforcing Strong Encryption", after a big warning block stating that
strong encryption is a moving target, and a comment pointing them to an
online tool where they can generate the latest-and-greatest
cipherstring. I am explicitly warning the target audience that "strong
encryption" is not a set-and-forget operation (though, obviously, the
document will be read and used by those who set-and-forget anyway).
So I'm not advocating a change to our default configuration here -- just
to the "strong encryption" recommendation in a how-to document, which
should IMO not enable ciphers that are known (or even suspected) to be
weak, even in the case that this snippet is copy-pasted into an
out-of-date crypto installation.
(If that's already clear, and you'd still prefer a blacklist to a
whitelist, then at the moment I'm outvoted. Just wanted to make sure. :) )
SSLHonorCipherOrder on
In our default config, the client has no choice. We will enforce the ciphers
and their priority in negotiation. Any modern OpenSSL (1.0.2, 1.1.0 are
the only two which matter, 1.0.1 goes away at year end) is going to elect
the strongest possible ciphers offering forward secrecy by default.
Because httpd is not a crypto provider, but a crypto consumer, I think we
should leave the prioritization of ciphers to the administrator (if they want
to customize their list) or the crypto library. They are in the best position
to downgrade the priority of a newly-weakend cipher at the entire system-
wide scope.
I'm not sure whether this is agreeing with the current recommendation as
written, or disagreeing. Can you clarify?
(And thanks to you, and everyone else, for the input and suggestions!)
--Jacob
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscr...@httpd.apache.org
For additional commands, e-mail: docs-h...@httpd.apache.org
