Thank you. Just an update. We've definitely narrowed it down to one of a handful of changes at this point.
It's seems that simply removing the call SSL_CTX_set_options( ssl_ctx_server, SSL_OP_CIPHER_SERVER_PREFERENCE ); has resulted in normal operations. Clearly this would be impacting the cipher choice, and it may well be choosing AES over another with the server preference on, so the next thing we'll try is re-inserting the server preference, and immediately after the process SSL_library_init() we'll run a OPENSSL_ia32cap = OPENSSL_ia32cap & ~0x200000200000000; as suggested (this is running on a Windows server FYI). Presumably that'll mean don't use the Intel AES instructions and run the "normal" code. This test will have to wait until another production update opportunity but I wanted to thank your for the feedback. Mark. ________________________________ From: Dr. Stephen Henson <[email protected]> To: [email protected] Sent: Friday, August 23, 2013 1:27 PM Subject: Re: Fw: 1.0.0e decryption failed or bad record mac On Fri, Aug 23, 2013, Mark Pietras wrote: > More information on our issue... it appears that the failure is occurring in > a SSL_read that had immediately followed a SSL_write on the > same SSL-instance/socket. Some instances of the issue are during the same > thread slice and some have a context-switch or two between them (for > whatever that's worth). Is there a case/need of some kind of "flush" > between transitions of reading and writing? I'm assuming not, but just > fishing for leads/ideas... > Try disabling AES-NI. That can be done with an environment variable: OPENSSL_ia32cap=~0x200000200000000 Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
