On 2015-07-18 6:12 PM, William A Rowe Jr wrote:
This was addressed for 2.2.31 and 2.4.16... See the significantly revised
default docs/conf/extra/httpd-ssl.conf.in template for our recommended
config.
I am "behind the times" obviously here.
I have some regular work to do, but I shall try adopting the settings in
httpd-ssl.conf and see if it has any effect on the tests when using
OpenSSL. Ideally, I will be able to set "my defaults" so that a test
with a CipherSuite setting that is lower that I want to serve - as a
server - will also 'FAIL' because the renegotiation is not permitted "by
me".
We won't be entertaining patches to change the compiled-in behavior in
these maintenance branches, this has severely negative impacts on users
updating to the same version major.minor for security updates on an
expedited basis.
I was not expecting anything "compiled-in", why I was thinking
httpd.conf to "literally" put in a place that cannot be avoided rather
than somewhere someone should be looking (like asking people to read the
manual :) )
Our discussions of compiled-in behavior changes is limited to svn trunk
(what will become httpd 2.6 or 3.0).
Much of this discussion becomes mute in the coming year or few as users
deploy OpenSSL, LibreSSL or GNUTLS with all legacy SSLv3 and TLSv1.0
support eliminated.
Yes, this is also what got me digging - the absolute demand that
a) system already running TLS1.0 are permissable but must come up with a
change plan
b) systems not running TLS1.2 must do so by 1 July 2016
c) all new systems MUST use TLS1.2 from the start.
(paraphrased from memory, so I hope I have the key points correct!)
Many thanks for your reply!
On Jul 18, 2015 10:40, "Michael Felt"<[email protected]> wrote:
A) OpenSSL and LibreSSL behave differently. Not surprising, because
LibreSSL got it's start because OpenBSD was (my words) - fed up - with the
upkeep of OpenSSL. And there are several presentations of "the first 30
days of LibreSSL" where the focus was on cutting out anything they felt was
inherently insecure (keeping calls for "linking", but having them be a
no-op).
B) Maybe for a long time - 'attackers' have been targeting weaknesses in
the OpenSSL specification (e.g. arbitrary order decidedfor ciphers, kex,
etc.). Since HeartBleed and POODLE there is, in any case, a lot more
attention to these issues.
My (humble) opinion: for something as important to society - as httpd is
these days - httpd should do (and maybe you have already!) to make sure
that "any client" cannot break a server, or force into low modes of
encryption. "The server should decide" and the defaults should be higher
than they are now - even if it be arranged by a "simple change" (I would
hope) to httpd.conf where a configuration line is added to force "TLS1.2"
as minimum encryption - should it be used.
p.s. - my goal is to start a discussion - if this is not the right place -
"kick me", and I shall look for a better venue.
regards,
Michael
On 2015-07-18 3:44 PM, Eric Covener wrote:
On Sat, Jul 18, 2015 at 8:47 AM, Michael Felt<[email protected]> wrote:
* Should the server determine that for a specific "Location"/"Directory"
more strict levels
are needed then a new handshake (renegotiate if you prefer) for a
stricter
cipher should start. However, based on the assumption above (the
strictest
cipher that the client has is already being used) - this should always
fail
because the client is not already at that level.
The assumption is not right. The servers list and the clients list
are in an arbitrary order decided by whoever wrote and configured the
software, and the server can choose to honor either (or neither, but
that would be weird) ordering. Also, some ciphers do not have such a
strict relative ordering of strength.
