On Wed, Jul 22, 2009, David Schwartz wrote: > > Michael Kurecka wrote: > > > Thank you for your help that is definitely a point in the right > > direction; however, it leaves me more baffled. I found the only > > SSL_CTX_new function that is in the code and it is being passed > > the TLSv1_method not an SSLv*_method which is what it should be > > according to your statement. So what else could cause it to call > > a different method? Is there an attribute of the SSL_CTX structure > > that I could display to see what version is going to be called that > > I could use to help trace the problem? > > Most likely, you're getting a connection from a non-FIPS endpoint that's > forcing you to use a protocol that's not FIPS compliant. I'm not sure why > you're seeing what you're seeing though -- it should just have reported that > it was unable to negotiate compatible protocols (assuming the other end was > not capable of TLSv1). >
Yes in FIPS mode non-compliant ciphersuites are disabled and so should never be seen. If there is some way to use them which is triggering this in unmodified OpenSSL 0.9.8k I'd like to know what it is as that's a bug which should be fixed. My guess is that the wpa_supplicant stuff is being called at this point and it is that which is using MD5. My earlier post describing how to set breakpoints at the relevant position should enable you to track it down, but you might also have to disable the FIPS integrity check when you do that as setting a breakpoint may cause it to fail. 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 User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
