This is a discussion on Re: Explicit cipher name behaviour has changed. - Openssl ; Sorry for a delay... 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 am. Initially, I found the problem when regression ...
Sorry for a delay...
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.
> Anyway. The proper way to fix this in OpenSSL is to extend the bit
> masks so that we can get two bits for AES128 and AES256 instead of
> just a single AES bit (and similarly for Camellia). Then "AES128-SHA"
> will give a pattern that matches just the AES128-SHA ciphersuite,
> and not AES256-SHA as well.
> For now, please try the following patch, play around with various
> ciphersuite description strings that you can think of, and let me know
> if it appears to work properly. (This patch is for the 0.9.8 branch,
> trivial manual editing would be required for applying it to the 0.9.9
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.
OpenSSL Project http://www.openssl.org
Development Mailing List email@example.com
Automated List Manager firstname.lastname@example.org