This is a discussion on Re: Explicit cipher name behaviour has changed. - Openssl ; On Tue, Sep 12, 2006 at 11:17:16AM +0300, Vlad W. wrote: > On 9/6/06, Bodo Moeller wrote: >> Question: Are you sure about the 0.9.7 (or 0.9.7d) behavior regarding >> "AES128-SHA"? What is the exact OpenSSL version? > Yes, I ...
On Tue, Sep 12, 2006 at 11:17:16AM +0300, Vlad W. wrote:
> On 9/6/06, Bodo Moeller
>> Question: Are you sure about the 0.9.7 (or 0.9.7d) behavior regarding
>> "AES128-SHA"? What is the exact OpenSSL version?
> Yes, I am. Initially, I found the problem when regression test of my
> application failed. Then, I found the same effect in openssl ciphers
> The version was definitely 0.9.7d.
Hm. I've tried this again in the 0.9.7 branch, using the ssl_ciph.c
version from 0.9.7d, and found that "openssl ciphers -v RC4-MD5"
correctly gets two ciphersuites (SSLv3 and SSLv2) and that "openssl
ciphers -v AES128-SHA" incorrectly gets the two ciphersuites
AES256-SHA and AES128-SHA. However, you reported that "openssl
ciphers -v AES128-SHA" returns the single cipher in 0.9.7[d], and I
don't see how this can be true for the 0.9.7 branch without additional
As far as I know, the problem that "openssl ciphers -v RC4-MD5"
selects just a single ciphersuite should exist in all OpenSSL releases
so far in which "openssl ciphers -v AES128-SHA" correctly selects just
a single ciphersuite. There's always one of the two bugs. The former
was introduced in OpenSSL 0.9.8b as a side-effect of fixing the
latter, which used to exist since AES ciphersuites were added with
the OpenSSL 0.9.7 release.
OpenSSL 0.9.8d will incorporate my patch to solve the problem.
> Thank you very much, your patch solved the problem, for both openssl
> ciphers util's symptom and my application.
> However, the fix based on mask matching is still interesting. May be,
> I'm a paranoiac, but I don't like mixing names and bit masks in the
> same mechanism, especially if previous versions worked without it. The
> cipher_id parameter had been added to ssl_cipher_apply_rule function
> only in 0.9.8b version, and I cannot understand how the mechanism
> worked without it in 0.9.7. Anyway, that's rather interesting than
> necessary for now.
Well, I can't really believe that the mechanism worked before. It can
only work without tricks like the one in the patch if there are
separate bits for AES128 and AES256 (same for Camellia), which is
something that we can do in OpenSSL 0.9.9 by changing the SSL_CIPHER
structure. (Of course the problem did not exist before OpenSSL 0.9.7,
when the AES ciphersuites were not in OpenSSL.)
OpenSSL Project http://www.openssl.org
Development Mailing List email@example.com
Automated List Manager firstname.lastname@example.org