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.
