Open Stack

Hi,

I missed this thread, so top posting with a related topic..

We discussed FIPS 140-2 yesterday in the OSSP irc meeting.

I recently tried running OpenStack on a FIPS 140-2 enabled kernel in
CentOS, and all of instances of MD5 use (mainly hashlib.md5) were rejected
resulting in the various python scripts bailing out with a stack trace. As
someone pointed out already, MD5 is considered weak, and does not meet the
FIPS list of secure crypto. I understand some projects might well use MD5
for non security related functions, but when it comes to government
compliance and running OpenStack on public clouds (and even private for the
Telcos / NFV), not meeting FIPS will in some cases block production getting
a green light, or at least make it a big challenge to push through.

With this in mind, perhaps all projects should seriously consider migrating
to more up to date methods such as sha256 or bcrypt, and start to
depreciate MD5 use.

I proposed raising bugs on launchpad for each instance discovered, so that
if anything, we at least have an idea of the extent of work needed to reach
the needed level of compliance for FIPS 140-2.

Thoughts welcome?

Luke

On Wed, Nov 9, 2016 at 1:56 PM, Ian Cordasco <sigmavirus24 at gmail.com> wrote:

> Apparently Paul's email didn't make it through, so I'm forwarding it
> to y'all since it pertinent information.
>
> -----Original Message-----
> From: Paul Kehrer <paul.kehrer at rackspace.com>
> Reply: Paul Kehrer <paul.kehrer at rackspace.com>
> Date: November 8, 2016 at 23:39:32
> To: Ian Cordasco <sigmavirus24 at gmail.com>, OpenStack Development
> Mailing List (not for usage questions)
> <openstack-dev at lists.openstack.org>
> Subject:  Re: [openstack-dev] [requirements][kolla][security] pycrypto
> vs cryptography
>
> > Cryptography will build just fine against a FIPS OpenSSL (1.0.0 or
> newer, although we’re
> > in the process of dropping < 1.0.1 support in the next several months).
> It is a supported
> > configuration, but enabling FIPS mode (if it’s not on by default) is not
> something cryptography
> > currently exposes (FIPS_mode_set). Rob and Ian’s points about the value
> of FIPS are
> > generally in line with my own opinions. In the absence of an audit
> requirement I’d recommend
> > looking for well-vetted and widely used libraries above trying to meet a
> specific compliance
> > regime.
> >
> > -Paul
> >
> > On 11/9/16, 5:11 AM, "Ian Cordasco" wrote:
> >
> > -----Original Message-----
> > From: Rob C
> > Reply: OpenStack Development Mailing List (not for usage questions)
> >
> > Date: November 7, 2016 at 07:39:57
> > To: OpenStack Development Mailing List (not for usage questions)
> >
> > Subject: Re: [openstack-dev] [requirements][kolla][security] pycrypto
> > vs cryptography
> >
> > > Good question, I know issues around this have arisen before.
> > >
> > > I think the main points have been covered well already, for my part I
> will
> > > always lean toward the better supported or actively developed project.
> >
> > At this point PyCrypto actively tells users that it's not supported or
> > developed. They've been pushing people towards Cryptogrpahy.
> >
> > > I understand the desire to look for FIPS 140-2 compliance, however I'd
> > > caution about this being the only deciding factor, it makes software
> > > development messy as only specific implementations can be validated.
> If you
> > > want to update code to make improvements etc you can need a whole
> > > re-validation. I'm not saying that FIPS 140-2 doesn't have value but I
> know
> > > of software projects that have used known-bad implementations that had
> > > certification rather use an updated version with no issues - (like I
> said,
> > > it gets messy).
> > >
> > > The OpenSSL guys wrote a good article on FIPS validation, how they
> tackled
> > > it and some of the impact etc [1]
> > >
> > > -Rob
> > >
> > > [1] https://www.openssl.org/docs/fipsnotes.html
> >
> > I would strongly suggest you read Rob's link. It's very enlightening
> > to know why, while FIPS may be a requirement, it's not necessarily
> > beneficial from a security standpoint. It's also ridiculously
> > expensive and restrictive.
> >
> > I've CC'd one of the lead developers from the Cryptography project to
> > comment on this. I would hazard a guess that one could compile
> > Cryptography against a version of OpenSSL that is FIPS compliant, but
> > I doubt it'll be considered supported. I know Cryptography recently
> > dropped support for a few older versions of OpenSSL, and to work with
> > that you'd have to stick to an older version of Cryptography.
> >
> > Can I ask why FIPS compliance is a requirement for Kolla? This seems
> > like an odd request for a deployment project.
> >
> > > On Sun, Nov 6, 2016 at 4:44 PM, Jeremy Stanley wrote:
> > >
> > > > On 2016-11-06 14:59:03 +0000 (+0000), Jeremy Stanley wrote:
> > > > > On 2016-11-06 08:05:51 +0000 (+0000), Steven Dake (stdake) wrote:
> > > > [...]
> > > > > > An orthogonal question I have received from one of our community
> > > > > > members (Pavo on irc) is whether pycrypto (or if we move to
> > > > > > cryptography) provide FIPS-140-2 compliance.
> > > > >
> > > > > My understanding is that if you need, for example, a FIPS-compliant
> > > > > AES implementation under the hood, then this is dependent more on
> > > > > what backend libraries you're using... e.g.,
> > > > > https://www.openssl.org/docs/fips.html
> > > > > https://www.openssl.org/docs/fipsvalidation.html
> >
> > --
> > Ian Cordasco
> >
> >
> >
>
> --
> Ian Cordasco
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Luke Hinds | NFV Partner Engineering | Office of Technology | Red Hat
e: lhinds at redhat.com | irc: lhinds @freenode | m: +44 77 45 63 98 84 | t: +44
12 52 36 2483
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161118/bd7ff652/attachment.html>