httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Felt <>
Subject Re: CipherLists and who has control: aka what to do re: renegotiate - a simple way to set minimum levels in "core"?
Date Sun, 19 Jul 2015 21:02:05 GMT
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/ 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 
> 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"<>  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<>   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.

View raw message