[Ach] Fwd: Re: Inconsistency with handling preferences of Cipherstrings (>=0.9.7m <1.0.0a)

ianG iang at iang.org
Tue May 13 15:05:16 CEST 2014

On 13/05/2014 10:12 am, Aaron Zauner wrote:
> -------- Original Message --------
> Subject: Re: Inconsistency with handling preferences of Cipherstrings
> (>=0.9.7m <1.0.0a)
> Date: Tue, 13 May 2014 03:57:44 +0000
> From: Viktor Dukhovni <openssl-users at dukhovni.org>
> Reply-To: openssl-dev at openssl.org
> To: openssl-dev at openssl.org
> On Tue, May 13, 2014 at 03:02:21AM +0200, Aaron Zauner wrote:
>>> Can you describe in words what you believe to be the nature of the
>>> "inconsistency" you found?  The semantics of OpenSSL cipherlist
>>> strings definitely changed for the better in 1.0.0, were you
>>> expecting identical results?
>> Yes I was. We have all expected OpenSSL to always prefer DHE based
>> suites if they are possible to negotiate. It seems this is an issue with
>> our cipherstring recommendation for OpenSSL versions <1.0.0 not OpenSSL
>> itself.
> You're also not using the correct primitive cipherlist attribute
> to select DH key exchange.  It is called "kEDH" (recently aliased
> to kDHE, but that's not yet in most releases) not "DHE" or "EDH".
> With OpenSSL 1.0.0, there is also an "EDH", but it is not primitive,
> it is equivalent to "kEDH:!aNULL" (it excludes the anonymous cipher
> suites).  In 0.9.8 there is no "EDH", only kEDH.
> Ditto for EECDH vs kEECDH.
>>>> In particular, given our cipherstring recommendation we encounter that
>>>> DHE and ECDHE based ciphersuites and their preference are neglected by
>>>> these OpenSSL versions [0] - we are currently discussing updating our
>>>> recommendation to an augmented version of this ciphersuite [1].
> One needs to RTFS a lot more closely to create a sensible cipherlist
> that works reasonably well with both 0.9.8 and 1.0.0.  It is
> possible, but requires a bit more attention to detail.
> A problem with explicit cipherlist recommendations is that they
> tend to get deployed in a cargo-cult manner long after they've been
> superceded.  I'd rather see progressive backwards-compatible
> improvements in the DEFAULT and ALL cipherlists in OpenSSL coupled
> with mechanisms such as the new security levels under development
> on the master branch.  I think these will serve users better than
> point-in-time cipherlist tweaks that no two people would make the
> same.
> This is not too say that no users will benefit from various
> recommendations.  Recommend more than selection, each emphasizing
> a slightly different aspect of the space.
>     - Performance at adequate security
>     - Maximal symmetric algorithm + mode security
>     - PFS
>     ...

quick quiz -- what do all the above mean?

Algorithmic agility is a blinky light for developers, not a feature for


More information about the Ach mailing list