httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Felt <mamf...@gmail.com>
Subject CipherLists and who has control: aka what to do re: renegotiate - a simple way to set minimum levels in "core"?
Date Sat, 18 Jul 2015 15:40:40 GMT
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<mamfelt@gmail.com>  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.


Mime
View raw message