I have a python application which comes packaged with Python and Libcrypto and LibSSL shared objects. The application was built with Openssl Fips Module 2.0. These shared objects are used by Python's request module and urllib3 under the hood to make TLS requests.
I enabled the OPENSSL_FIPS flag in the environment where i was building the application. Now if want to check whether the shared objects have the fips mode enabled when i take them out of the development environment and put them in another machine, how can i do that?
How can i check whether the fips mode is enabled or not? And if it isn't, how can i enable the fips mode for these shared objects?
Additional Details that might help:
OpenSSL Version: 1.0.2h (built from source)
Fips Module: 2.0.12 (built from source)
Python: 3.6
OS: Ubuntu 16.04 LTS
Please let me know if any additional details are required.
Thanks!
I've built the OpenSSL-fips module using regular flags (e.g.: no-asm, shared, some ancient ciphers disabled):
And started playing a little bit with it:
Note the "(Library: OpenSSL 1.0.2g 1 Mar 2016)" part. That (being present) states that the openssl executable is OK (expected version), but it's using a wrong libcrypto (it's the one that comes installed by default on the system - under /lib - and typically that one isn't built with FIPS support).
It must load our libraries, and that is done by setting LD_LIBRARY_PATH (the same behavior could have also been achieved by setting an env var when building OpenSSL that would have set the rpath in the openssl executable, but I forgot, and I didn't want to build it again):
Now, that the setup is successful, let's dive into OPENSSL_FIPS env var:
As seen from above, the md5 hash behavior is influenced by the OPENSSL_FIPS env var (when FIPS mode is on, its usage is not allowed).
Notes:
Since OPENSSL_FIPS env var is handled at openssl executable level, which will be bypassed (as libcrypto will be used directly), it's no use for the current situation, so we have to go deeper. These are the functions that control FIPS mode in a loaded libcrypto instance:
They will be used to read/write FIPS mode. In order to test whether FIPS mode is really set, md5 hash (from the example above) will be used.
code.py:
Notes:
import hashlib
statement is located after setting the FIPS mode (and not at the file beginning, as it should be), because hashlib does some caching at import time, so it captures the FIPS value at import time, and doesn't care if it changes afterwardsOutput:
As seen, setting FIPS mode via ctypes, really sets it.
I don't know why it segfaults, but the md5 related code is there only for testing purposes, so it's not needed in production.
I remember that on some Lnx version (might be RH based), FIPS mode could also be set (globally for the system), by editing some entry (under /proc ?), but I can't remember it.
A more elegant approach would be to expose Python wrappers for the 2 functions.
Check [Python]: Issue 27592: FIPS_mode() and FIPS_mode_set() functions in Python (ssl), I've also submitted a patch for Python 3.4 (where they were exposed by the ssl module), but it was rejected based on the following arguments (out of which the 1st 2 are relevant):
You can apply it to Python 3.6 (I don't think it will work OOTB, since line numbers most likely changed), and (obviously) you'll have to build Python from sources.
Bottom line:
@EDIT0:
It just stroke me, the behavior that you're encountering on [SO]: Not able to call FIPS_mode_set() of libcrypto.so with Python ctypes [duplicate] might also be related to the wrong libcrypto being loaded (check the
openssl version
tests w/wo LD_LIBRARY_PATH from the beginning).A non FIPS capable OpenSSL will still export the 2 functions, but they both simply return 0.
So, make sure to load the correct libraries by specifying LD_LIBRARY_PATH ! (there are other ways, but this is the most straightforward one).