A Survey of Database TLS Implementations

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:

(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).

See discussion of this page on Reddit, HN, and lobsters.