Open MayurMudgal opened 4 years ago
Hi MayurMudgal,
Thanks for bringing this to our attention. We are looking into the issue and will have more information for you soon.
There are a few issues at play.
1. The aerospike package from pip comes with precompiled binaries
The aerospike package from pip comes with precompiled binaries (wheels), and the manylinux wheel includes OpenSSL.
The 2.0 FIPS module is compatible with OpenSSL releases 1.0.1 and 1.0.2, and no others. The wheels that come from pip will have a FIPS incompatible version of OpenSSL that the Python client is linked agains.
So, you're going to need to use the --no-binary
flag of pip to make it grab the source code and compile locally. Locally, you're going to want to make sure you have OpenSSL 1.0.1 or 1.0.2 with the 2.0 FIPS module, and limit what is available locally to only validated cryptography. Try that first.
That is just a fact, so if you're using cryptography that isn't in the existing 2.0 FIPS module list, nothing will change until the 3.0 FIPS module (FOM) and version 3.0 of OpenSSL supporting it.
An OpenSSL blog post from 2018 stated "We are mindful of the end-of-life date for OpenSSL-1.0.2 (31-Dec-2019) and the end-of-life (sunset date) of the existing OpenSSL FIPS Object Object (29-Jan-2022) and our objective remains to have a validated cryptographic module in place well before 31-Dec-2019" - that date has passed.
The latest November 2019 blog post addresses this, with Q4 2020 as the target date for OpenSSL 3.0. Still, there will be a gap period where OpenSSL 1.0.2 is EOL and OpenSSL 3.0 with FOM isn't yet in place.
RIPEMD-160 is used to hash the set and userKey into a 20B digest, which is the actual unique identifier of the record, and from which the (consistently hashed) partition ID is derived. That's it. It has nothing to do with client-server or node-to-node encryption functions. It's never actually used by TLS encryption. If it still comes up after step (1), you will need to look into bypassing this warning for now, because it has nothing to do with encryption of data in transit or at rest (storage layer).
Not with Aerospike. If you're asking about TLS you're already an enterprise customer, and should be directing your questions to the support system, and be talking to a solutions architect at Aerospike. You must be a commercial entity, which isn't using the Community Edition of Aerospike (that edition doesn't have TLS).
Most Aerospike customers do not care about FIPS validation per se, they just want cryptographic algorithms to work, which they do. FIPS isn't at all about the cryptographic modules, it's about having them validated by a third-party. I mean that you should get a support contract with OpenSSL, which is mentioned in the latest blog post from OpenSSL. You can contact osf-contact@openssl.org . The answer to what will be up with RIPEMD-160 in the future, and whether you can set FIPS mode to bypass a warning for a component that isn't used in encryption, is one for the people actually developing this software. Also this premium support from OpenSSL should provide you with an extension to the life of release 1.0.2 and FIPS module 2.0 till the end of the year.
See the Algorithm Selection section of OpenSSL 3.0.0 Design doc. Aerospike will be able to add a bypass only for RIPEMD-160, once that feature of the 3.0 module and OpenSSL 3.0 library exists.
The Aerospike Client uses digest RIPEMD160 which is forbidden in openssl fips version. It throws error while calling connect function. Below is the sample code which is crashed during SSL handshaking.
Code: tls_config = { "cafile": "/path/to/cacert.pem", "keyfile": /path/to/key, "certfile": /path/to/certfile, "enable": True }
client = aerospike.client({ "hosts": hosts, "tls": tls_config })
client.connect()
Error: rmd_dgst.c(73): OpenSSL internal error, assertion failed: Digest RIPEMD160 forbidden in FIPS mode!