OpenSSL instead of LibreSSL? (FIPS mode ...)

FoundationDB’s TLS system uses LibreSSL “by default”. While I applaud that choice, we’re looking at some deployments where we’ll need to be using FIPS-140-2 validated cryptographic modules, and the LibreSSL folks have taken a principled stand against ever going down that road.

Is the TLS integration designed to support other implementations besides LibreSSL via changes to the build system?

A long long time ago, there was a release called FDB 5.2. In these prehistoric times, TLS code existed as a plugin, under the idea that alternative TLS implementations could be used. This plugin caused a great headache for both operations and testing. Operationally, it added another shared library that needed to be deployed alongside the client library, that all client libraries needed to be able to use the same version of the TLS plugin, and understand how to find it. In testing, the TLS plugin needed to be available for simulation testing, as TLS being enabled or disabled would affect determinism. Thus, as it was causing a headache for developers and operators of FDB alike, it was just compiled into FDB as a static library from FDB 6.0 onwards.

However, the code itself for TLS is still written as a plugin and still loaded as a plugin, using the TLS Plugin framework. This leaves the door pretty open for someone to go and undo the changes that made LibreSSL compiled-in and re-enable the now ignored --tls_plugin flag and options to allow specifying an additional external TLS library, and then make a way to configure which TLS implementation to use.

1 Like

After some investigations into how to speed up TLS connection times, we’ve discovered that OpenSSL appears to have some optimizations that LibreSSL, and that Boost.SSL exists, which would drastically simplify our TLS code. We’re likely going to be landing changes soon to cut the TLS implementation over to that, and statically link OpenSSL into FDB, which should then make getting FIPS also available a much easier process for you.

1 Like

how did this go? I’ve got FreeBSD building against LibreSSL in ports, but it fails when using base OpenSSL (which is pretty up to date):


[524/697] : && /usr/bin/c++ -fPIC -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -O2 -pipe -fstack-protector-strong -fno-strict-aliasing  -fstack-protector-strong   -static-libstdc++ -static-libgcc -Xlinker --version-script=/tmp/usr/ports/databases/foundationdb-devel/work/fdb-aeefe57/bindings/c/fdb_c.map -Xlinker -z -Xlinker nodelete -shared -Wl,-soname,libfdb_c.so -o lib/libfdb_c.so bindings/c/CMakeFiles/fdb_c.dir/fdb_c.cpp.o bindings/c/CMakeFiles/fdb_c.dir/ThreadCleanup.cpp.o bindings/c/CMakeFiles/fdb_c.dir/fdb_c.g.S.o  -Wl,-rpath,/usr/local/lib:  lib/libfdbclient.a  lib/libfdbrpc.a  lib/libthirdparty.a  lib/libflow.a  /usr/local/lib/libeio.so  -lrt  -lexecinfo  -ldevstat  /usr/lib/libssl.a  /usr/lib/libcrypto.a  -pthread && :
FAILED: lib/libfdb_c.so 
: && /usr/bin/c++ -fPIC -O2 -pipe -fstack-protector-strong -fno-strict-aliasing -O2 -pipe -fstack-protector-strong -fno-strict-aliasing  -fstack-protector-strong   -static-libstdc++ -static-libgcc -Xlinker --version-script=/tmp/usr/ports/databases/foundationdb-devel/work/fdb-aeefe57/bindings/c/fdb_c.map -Xlinker -z -Xlinker nodelete -shared -Wl,-soname,libfdb_c.so -o lib/libfdb_c.so bindings/c/CMakeFiles/fdb_c.dir/fdb_c.cpp.o bindings/c/CMakeFiles/fdb_c.dir/ThreadCleanup.cpp.o bindings/c/CMakeFiles/fdb_c.dir/fdb_c.g.S.o  -Wl,-rpath,/usr/local/lib:  lib/libfdbclient.a  lib/libfdbrpc.a  lib/libthirdparty.a  lib/libflow.a  /usr/local/lib/libeio.so  -lrt  -lexecinfo  -ldevstat  /usr/lib/libssl.a  /usr/lib/libcrypto.a  -pthread && :
c++: warning: argument unused during compilation: '-static-libstdc++' [-Wunused-command-line-argument]
c++: warning: argument unused during compilation: '-static-libgcc' [-Wunused-command-line-argument]
ld: error: can't create dynamic relocation R_X86_64_32 against local symbol in readonly segment; recompile object files with -fPIC or pass '-Wl,-z,notext' to allow text relocations in the output
>>> defined in /usr/lib/libssl.a(methods.o)
>>> referenced by methods.c
>>>               methods.o:(TLS_method) in archive /usr/lib/libssl.a

full build log

Personally I’d prefer to statically build in LibreSSL or OpenSSL from ports, and then have a TLS enabled FDB that has no external TLS dependency. If that’s not possible I will probably make TLS an enabled-by-default option.

I can move this to an issue if needed.

Builds successfully against OpenSSL 1.1.1f in ports.

Hi Dave,
I know this is an old topic, but I would also want to understand how that FIPS compliance work. From the look of the conversation, as long as I can compile say with a version of openssl that is FIPS like what you have in your case (openssl 1.1.1f), that will make it compliance when running on a FIPS enabled host? Is that right? Thus, I just need to make sure if I use the docker file build env. that FDB provide, or I try to compile it on a RHEL7/Centos7 host, that should work?