Re: squid md5 and fips mode

On Tue, Jun 19, 2012 at 9:10 AM, Paul Wouters <pwouters_at_redhat.com> wrote:
>
>
> Hi,
>
> I have been looking at FIPS issues with squid in both RHEL5 and RHEL6.
>
> In fips mode, MD5 is not allowed for securing web traffic (with some TLS
> exceptions) nor user authentication. It is allowed for other things,
> such as hashes for disk objects.
>
> The problem in older versions of squid was that the cache object code
> used md5, and since openssl did not allow it, it would die. This was
> fixed with a patch by using the squid buildin md5 functions for the
> cache object hashes. See https://bugzilla.redhat.com/show_bug.cgi?id=705097
>
> Now for recent versions of squid, I have the reverse problem. The
> openssl md5 code is never used, so I had to patch it back to using
> openssl with the exception for the cache object id where I used
> private_MD5_Init()
>
> It basically undoes most of these commits:
>
> - Changing 'xMD5' function name to 'SquidMD5'
> - Changing 'MD5_CTX' typedef to 'SquidMD5_CTX'
> - Changing 'MD5_DIGEST_CHARS' define to 'SQUID_MD5_DIGEST_LENGTH'
> - Changing 'MD5_DIGEST_LENGTH' define to 'SQUID_MD5_DIGEST_LENGTH'
> - Removing messy #ifdef logic in include/md5.h that tries to use
>  the system libraries if available.  We'll always use the Squid MD5
>  routines.
>
> My request is to basically undo this change, and to use openssl again
> where possible, so that fips enforcement does not fail with the custom
> crypto code that goes undetected. A rought patch (that does not take
> into account systems with no crypt()) is attached at:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=833086

A few quick thoughts:
 - We'd love patches that make squid explicitly aware of e.g. FIPS
mode, so that we can enforce it ourselves. We've no idea today when we
change something whether its going to impact on such external needs,
and frankly, tracking it is going to be tedious and error prone,
leading to the sort of flip-flop situation you have.
 - as we don't have an OpenSSL exception in our copyright (and its
-hard- to add one today), you can't legally ship a squid binary linked
against openSSL anyway.
http://gplv3.fsf.org/wiki/index.php/Compatible_licenses#GPLv2-incompatible_licenses.
Note that our COPYING file says 'version 2' not 'version 2 or later',
though at least some source files say 'version 2 or later' - we'll
need to figure out what to do about *that* in due course. So,
basically every build of squid that uses openSSL has to have been
built by the end user locally, anyway. Yes, this kindof sucks.

That said, if the FIPS standard doesn't like MD5, there is no need for
use to use it at all, we could use sha1 as a build time option for
cache keys (or take the first N bits of sha1), if that helps: that
would allow us to be entirely MD5 free when desired.

-Rob
Received on Tue Jun 19 2012 - 09:05:52 MDT