This is a discussion on Explicit cipher name behaviour has changed. - Openssl ; Hi, Working on openssl library upgrade from 0.9.7d to 0.9.8a I found a change in explicit cipher name behaviour. E.g., in version 0.9.7 "openssl ciphers -v RC4-MD5" gets 2 ciphers named RC4-MD5, for SSLv3 and SSLv2, and "openssl ciphers -v ...
Working on openssl library upgrade from 0.9.7d to 0.9.8a I found a
change in explicit cipher name behaviour.
E.g., in version 0.9.7
"openssl ciphers -v RC4-MD5" gets 2 ciphers named RC4-MD5, for SSLv3 and SSLv2,
"openssl ciphers -v AES128-SHA" gets the single cipher, as was expected.
In 0.9.8a this command in the first case behaves in the same way, but
in the second case both AES128-SHA and AES256-SHA was returned.
I found a change in the version 0.9.8b (Check-in Number: 15185) which
has fixed the problem in the case of AES ciphers.
However, the same change affects the case of the same name and
different protocols, e.g., there is only SSLv3 RC4-MD5 cipher in the
first example output. The similar problem occur in any case when same
cipher name exist in both SSLv3 and SSLv2: when first cipher_id is
found in ssl_cipher_process_rulestr function (from the check-in
15185), the function does not continue the searching process.
Thus, both openssl 0.9.8a and 0.9.8b behave differently from 0.9.7
branch. I'm confused which behaviour is correct, but the both of the
new ones seem to be problematical. They cause to either wrong cipher
using (AES128-SHA instead of AES256-SHA in 0.9.8a) or SSLv2 connection
failure (in 0.9.8b).
Could you comment that and to suggest a solution?
OpenSSL Project http://www.openssl.org
Development Mailing List email@example.com
Automated List Manager firstname.lastname@example.org