[ale] Libgcrypt warning: MD5 used - FIPS mode inactivated

[Adrya Stembridge]

I noticed a difference in output of openssl ciphers -v 'HIGH:MEDIUM:!ADH'
between the working box, and the one generating libgcrypt warnings.

The latter shows the following ciphers in use:

DES-CBC3-MD5            SSLv2 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=MD5
KRB5-DES-CBC3-MD5       SSLv3 Kx=KRB5     Au=KRB5 Enc=3DES(168) Mac=MD5
IDEA-CBC-MD5            SSLv2 Kx=RSA      Au=RSA  Enc=IDEA(128) Mac=MD5
RC2-CBC-MD5             SSLv2 Kx=RSA      Au=RSA  Enc=RC2(128)  Mac=MD5
KRB5-IDEA-CBC-MD5       SSLv3 Kx=KRB5     Au=KRB5 Enc=IDEA(128) Mac=MD5
RC4-MD5                 SSLv3 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5
RC4-MD5                 SSLv2 Kx=RSA      Au=RSA  Enc=RC4(128)  Mac=MD5
KRB5-RC4-MD5            SSLv3 Kx=KRB5     Au=KRB5 Enc=RC4(128)  Mac=MD5

The same version of openssl is used on both systems (OpenSSL
1.0.1e-fips 11 Feb 2013).  I am not seeing how to configure openssl to
not use MD5 by default.   This may or may not fix the libgcrypt issue,
but thought it is worth investigating.

The openssl package is from CentOS (same as the second machine that
does not have the libgcrypt FIPS warnings).  Is it possible to change
openssl's global config?  I see where to change ssh and httpd's
configs, but those aren't affecting what appears with openssl ciphers
-v 'HIGH:MEDIUM:!ADH'.




On Thu, Aug 13, 2015 at 4:54 PM, Jim Kinney <jim.kinney at gmail.com> wrote:

> You can run strace on the tsql process and see where the md5 bits are
> being found and delete the keys found.
>
> Is it possible that the far side of the tsql connection is using md5 based
> on prior connections before fips change?
> On Aug 13, 2015 4:38 PM, "Adrya Stembridge" <adrya.stembridge at gmail.com>
> wrote:
>
>> ls -ltR /etc/pki/ reveals no newly created files prior to enabling FIPS.
>>
>> There are a few package differences, but for things like openmanage and
>> some additional tools needed on the production side.   libgcrypt and
>> freetds (contains tsql) are identical.
>>
>> Last night I removed/reinstalled freetds with no success (the old conf
>> file was moved out of the way).
>>
>> On Thu, Aug 13, 2015 at 2:36 PM, Jim Kinney <jim.kinney at gmail.com> wrote:
>>
>>> OK. Time to run rpm -qa on both dev and new and diff the list. Something
>>> is missing or diff version on new system.
>>>
>>> Hmm. So the pre-fips connection with tsql worked. That implies it was
>>> using md5. Converting the system to fips compliant didn't change the tsql
>>> config to use sha1 keys so it still uses (tries) md5.
>>>
>>> Delete the old md5 keys for tsql or remove the package entirely and
>>> reinstall (after renaming out the config as conf.old). Do you see keys with
>>> creation dates prior to FIPS in /etc/pki?
>>>
>>> On Thu, 2015-08-13 at 14:22 -0400, Adrya Stembridge wrote:
>>>
>>> On Thu, Aug 13, 2015 at 12:25 PM, Jim Kinney <jim.kinney at gmail.com>
>>> wrote:
>>>
>>> The rhel instructions look like the system keys will default to weaker
>>> non-FIPS unless fips=1 is a kernel param at at system installation. So *converting
>>> an existing system won't work*. So weak keys with libgcrypt will call
>>> for fallback to non-fips but then fails since it's a denied operations mode.
>>>
>>>
>>> I went through the same steps of activating FIPS on my dev instance, and
>>> do not have the libgcrypt error, and am able to tsql to my SQL Server
>>> machine.   Confirmed FIPS is active and working using the steps written in
>>> my initial post to the list.
>>>
>>>
>>> --
>>> James P. Kinney III
>>>
>>> Every time you stop a school, you will have to build a jail. What you
>>> gain at one end you lose at the other. It's like feeding a dog on his
>>> own tail. It won't fatten the dog.
>>> - Speech 11/23/1900 Mark Twain
>>> http://heretothereideas.blogspot.com/
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ale.org/pipermail/ale/attachments/20150818/36306b6e/attachment.html>