A Survey of Database TLS Libraries
I was curious how much the choice of which TLS library to use in a database has been affected by all of the OpenSSL security vulnerabilities, so I checked the code of a number of OSS databases.
Visual Results
Thoughts
OpenSSL, and not one of its forks, is still by far the most common choice. Some of its usage is transitive (via netty or asio), but some comparitively newer databases have still directly coded their TLS implementation against OpenSSL. LibreSSL removed FIPS and dropped optimized assembly routines, so I’m not surprised it hasn’t seen adoption, but I would have expected more BoringSSL usage.
I’m not a Java or Go person, so I learned as part of this that they have their own bespoke TLS implementations. Go wanting to avoid a C dependency tracks with the overall distaste for cgo that I’ve seen. I’m a bit surprised by netty preferring OpenSSL over JDK’s own TLS, but they do have their reasons.
I asked ScyllaDB developers about their (unusual) choice of GnuTLS, and was told that the motivation was due to concerns about OpenSSL’s code quality and maintenance. Which, as the years unfolded, turned out to be an incredibly wise decision at the time.
Advice
If you’re here to decide what TLS implementation you should use when developing your own database, then my advice would be:
-
If available, use your RPC/network/eventloop provider’s TLS implementation (e.g. ASIO’s TLS support[1], netty’s SSL). [1]: And consider paying for WolfSSL over using OpenSSL as the ASIO TLS implementation.
-
If available, you should use your language’s native TLS implementation (e.g. java => JDK, golang => crypto/tls).
-
Otherwise, code against libtls, using LibreSSL.
-
Once your project is mature enough that you care about LibreSSL benchmarking worse than OpenSSL, switch to libretls.
-
-
If you must directly use OpenSSL, using BoringSSL.
(There exist other implementations of the libtls api (michaelforney/libtls-bearssl, mirleft/libnqsb-tls
), but I’m not sure when I’d specifically recommend using them. BearSSL might be a good choice for embedded platforms if you don’t have the budget to pay for WolfSSL. Not Quite So Broken might only be of interest if there’s no possibility of ever patching a future TLS vulnerability?)
Tabular Results
This table was constructed out of manual review. In each codebase, I tried (via searching) to differentiate OpenSSL from its forks (LibreSSL or BoringSSL).
| Database | TLS Provider | Note | Source |
|---|---|---|---|
MySQL |
OpenSSL |
||
PostreSQL |
OpenSSL |
||
MongoDB |
OpenSSL |
via ASIO |
|
Redis |
OpenSSL |
||
Elasticsearch |
JDK |
||
Cassandra |
OpenSSL |
JDK fallback, via netty |
|
MariaDB |
WolfSSL |
||
Neo4j |
JDK |
via jetty |
|
InfluxDB |
crypto/tls |
via net/http/server |
|
Couchbase |
OpenSSL |
||
Realm |
OpenSSL |
||
CockroachDB |
crypto/tls |
||
RiakKV |
OpenSSL |
via OTP, LibreSSL supported |
|
ArangoDB |
OpenSSL |
||
ScyllaDB |
GnuTLS |
||
TiDB |
crypto/tls |
||
Yugabyte |
OpenSSL |
||
FoundationDB |
OpenSSL |
Supports LibreSSL, BoringSSL, and WolfSSL |