On 02/06/2013 02:14 PM, Dr. Stephen Henson wrote:
On Wed, Feb 06, 2013, Brad House wrote:
On 02/06/2013 01:37 PM, Dr. Stephen Henson wrote:
A possibility is the AESNI+SHA1 stitched code which is handled as a special
case. You'd only see that with AES+SHA1 ciphersuites on AES-NI supporting
processors.
DHE-RSA-CAMELLIA256-SHA also has the same issue. I'm thinking it may be
a -SHA issue as the only -SHA cipher I've gotten to work so far is RC4-SHA.
Note though the TLSv1.2+HIGH ciphers that use SHA256 and greater look fine.
Hmmm... if it's a problem with the CVE-2013-0169 it would appear when you
select a ciphersuites using a block cipher. So AES would exhibit it but not
RC4 and not AES-GCM.
Possibly a problem with the constant time SHA1 code but then shouldn't get
that in FIPS mode.... weird.
In ssl/s3_cbc.c and the function ssl3_cbc_record_digest_supported try
setting it to return 0 when NID_sha1 is passed.
I'll try modifying ssl/s3_cbc.c in 1.0.1d in a follow-up.
Have you not been able to reproduce this issue? I've seen it on more than
one machine.
I've not seen it yet, no. Do you get the same problem with OpenSSL 1.0.0k?
I just tried 1.0.0k, it is fine. No issues there.
-Brad
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
