Viktor Dukhovni wrote: > Be careful what you advise, sometimes seemingly more secure settings > result in substantially reduced security if the result is a failed > handshake and fallback to even weaker protection (possibly cleartext). We are. We'd be happy for more people of the OpenSSL team to review our recommendations.
> In particular, anything that radically restricts cipherlists for > SMTP (e.g. by disabling RC4) may well substantially reduce security. Those issues are noted and dealt with in the paper. > The cipher-suite ordering in OpenSSL 0.9.8 is rather fragile. It > was overhauled for 1.0.0 and later, but the improvements required > an ABI change since the bitmask holding various cipher properties > had to be split into multiple structure elements (more bits and > better organization). > > Also the order of DEFAULT in 1.0.0 is correctly inherited from the > ordering of ALL, while in 0.9.8, any ordering of ALL is accidental. > Finally 1.0.0 makes it easier to fine-tune the order by introducing > "FOO:-FOO:ALL" as a mechanism to tweak the cipher order. This is > not available in 0.9.8. Thanks for your insight. > 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. >> 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]. > > EC is "experimental" in 0.9.8 and not enabled by default. You > should not enable EC with 0.9.8, so ECDHE should be out of scope. Thanks, I've already addressed this on our list. This is not our current recommendation BTW. I'm just trying to figure out a cipherstring that will yield the appropriate security policies described in our paper for both 0.9.8 and 1.0.0+. Aaron
signature.asc
Description: OpenPGP digital signature
