[Ach] Fwd: Re: Inconsistency with handling preferences of Cipherstrings (>=0.9.7m <1.0.0a)
azet at azet.org
Tue May 13 11:12:29 CEST 2014
-------- Original Message --------
Subject: Re: Inconsistency with handling preferences of Cipherstrings
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
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  - we are currently discussing updating our
> >> recommendation to an augmented version of this ciphersuite .
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
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
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev at openssl.org
Automated List Manager majordomo at openssl.org
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: OpenPGP digital signature
More information about the Ach