HAProxy was built with support with multiple SSL libraries in mind, even if all the work started on OpenSSL. Over time a lot of features were added based on features available in OpenSSL and certain features were implemented "the OpenSSL way". When the Heartbleed attack happened in 2014, some forks started to appear with significant divergence from the original project. Some features were dropped and others added in these libaries. By then most of the features selection in HAProxy was solely OpenSSL version-based so there were a few difficult years during which support for such forks was sometimes a bit chaotic. Since HAProxy 2.7 due to more important API differences, the features are essentially conditioned on a per-library basis so it has become much more portable, but with functional differences between implementations. However the API is still extremely OpenSSL-centric since it's what each library provides and there's no point reimplementing all sample-fetch functions for a single exotic library.

(please note that information mentioned here concerns the development version, and to some extents the previous ones when it's mentioned that they are also compatible).

The list of SSL/TLS libraries which are known to build and generally work with current versions of HAProxy is: OpenSSL, QuicTLS, LibreSSL, AWS-LC, WolfSSL.

At the time of writing this (2023-09-22) OpenSSL builds and works for versions 1.0.0 to 3.1. Note that support for versions 1.1.1 (and older) was dropped by the OpenSSL team on 2023-09-11 with 1.1.1w being the last version they will support.

While once the most complete library, OpenSSL is now known for being affected by multiple limitations. The first one is that OpenSSL is the only library supported by HAProxy that lacks QUIC (HTTP/3) support. A limited compatibility layer was added in HAProxy 2.9 to allow to use QUIC with a reduced feature set on top of OpenSSL to help users test their infrastructure and prepare their setups, but for anything serious, an alternative library with native support is preferred.

OpenSSL suffers from massive performance regressions since version 3.0. Many of them are caused by excessive locking on large code areas, but the too dynamic architecture is also to blame, by which once-constant values are now looked for by scanning linked lists...

The frontend side is particularly affected, with 3.0.2 showing ~1/10 of the performance of 1.1.1, recovering a little bit to 1/4 around 3.0.9. Sadly, some operating systems such as Ubuntu 22.04 ship with the worst performer (3.0.2), forcing some users to add more hardware just for the version switch. Version 3.1 is still at ~1/2 of the 1.1.1 performance on the frontend at the time of writing.

The backend side is severely affected by version 3.0 to the point of being totally unusable by certain users since health checks alone can be sufficient to completely saturate the CPU with a few hundreds servers. Adding more CPUs does not work due to the extreme locking in the OpenSSL code which limits the scalability to just a few cores, the rest being spent waiting in locks. Note that 1.1.1 was already far from being a champion regarding locking and scalability but at least it did work.

At this point, OpenSSL 3.x is basically only usable for personal sites. Users seeking anything serious performance-wise will need to stay on version 1.1.1 provided by their vendor or to recompile one of the alternate libraries below.

QuicTLS is simply what OpenSSL ought to have become, i.e. the small set of QUIC patches from BoringSSL applied on top of OpenSSL. QuicTLS follows the exact same versions as OpenSSL and advertises itselfs as "openssl+quic". Since it's a volunteer's effort, it cannot do more than support the supported versions of OpenSSL. Thus since version 3.x it's perfect for small sites which only need QUIC support on top of OpenSSL, but it suffers from the exact same performance issues as OpenSSL. It's unknown if the patches apply on top of the supported Linux distro forks of OpenSSL 1.1.1 since these ones are usually early and might miss many bug fixes. As such, some previous users of QUIC on 1.1.1 might be left without an easy solution now, or may have to enable the QUIC compatibility layer in HAProxy and stick to 1.1.1 as supported by their vendor.

Since version 3.3, Quictls become a real fork instead of just a QUIC patchset on top of OpenSSL. The patchset which was hosted at https://github.com/quictls/openssl is not maintained anymore. The hard fork of OpenSSL 3.3 lives here https://github.com/quictls/quictls. HAProxy does not supports it for now, and no clear maintenance cycle is defined for now.

LibreSSL is the fork made by OpenBSD from OpenSSL. Just like BoringSSL it dropped a lot of old unmaintained code and lacks certain features. It tends to be more stable over time than BoringSSL as it emits versions that are supported for a bit more than one year. It also supports the BoringSSL QUIC API since version 3.6. It does not support OpenSSL engines. Just like with BoringSSL, it's difficult to assess what is supported and what is not, so before using it, tests are required (including performance tests since certain machine-specific optimizations were apparently also removed). Certain internal API parts look like the BoringSSL version rather than the OpenSSL version, so certain features may be limited on both, or be supported by both. It's worth noting that lately the interest for this library from Linux distros seems to have started to fade away.

WolfSSL is a completely separate project, led by the WolfSSL team. It does not inherit code from OpenSSL and has it roots in embedded systems where resources are scarce. As such it's an extremely configurable library where each individual algorithm, feature, hardware optimization has to be chosen at build time. When built with proper options, this library is extremely fast (typically 10 times faster than OpenSSL 3.0.8 on a large system, using 1 lock per connection vs 691 for OpenSSL). This library support in haproxy is young and its support is still not as complete as other libs'. However it does support QUIC and is already fairly complete. At the time of writing, certain limitations have been identified:

• the configuration will not load if a certificate has an expired date
• the certificate load order is stricter than what is currently done in haproxy, some configs may fail to load
• some OCSP issues have been spotted (yet to be qualified)
• there seems to be some (not well qualified yet) issues when using server certificates and client certificates
• the generate-certificate action does not work
• the way the SNI callback used to select the certificate does not work like the OpenSSL one, which can lead to issues when falling back to the default certificate. (This was fixed with WolfSSL 5.6.6 + HAProxy 3.0)
• the method to chose between an RSA and ECDSA certificate for the same name is different from OpenSSL and mixing them at the moment may yield undefined results. (This was fixed with WolfSSL 5.6.6 + HAProxy 3.0)
• error codes differ from OpenSSL and are one reason why some HAProxy's regtests fail, but this is not a problem on either side, it's just that expecting one code when getting another will cause trouble. It means that those who would apply post-processing on their logs need to be aware of this. HAProxy now provides a function to emit a symbolic error name instead of the code for known errors, that greatly simplifies this.

Aside this for configurations that do not rely on any such advanced features, the library is doing its job. It is still evolving fast and is regularly adopted by popular Linux distributions such as Debian/Ubuntu. The HAProxy and WolfSSL teams have invested a lot of time on improving this support because there is good hope for a true long-term alternative here. And last but not least, this library builds very fast (a few seconds) so there's no fear experimenting with various options. Please have a look at the INSTALL file in HAProxy to get the complete build instructions. Support is experimental for now, it is recommended to use at least the 5.6.6 version.

This is AWS's libcrypto. It's made by assembling parts from BoringSSL, from OpenSSL 1.1.1 and some home-made ones. The focus is on performance, long-term stability, and FIPS certification. Support for this library was introduced in HAProxy 2.9, and it remains very close to OpenSSL 1.1.1 in appearance. The library does support QUIC, but some ciphers are missing because the API differs from OpenSSL for some of them, it will require some change in HAProxy to support them all. There is currently some ongoing discussion between the HAProxy and AWS-LC teams regarding the best way to adapt (i.e. should AWS-LC implement the missing functions or should HAProxy implement a different approach and maintain two APIs). The intent behind this library sounds good. It's unsure whether it's packaged yet in distros or even on AWS images by default, nor how the project will evolve, but like WolfSSL, it does look like a promising long-term alternative to OpenSSL. HAProxy 3.1 and AWS-LC 1.22.0 complete the missing SNI selection with ECDSA+RSA.

Based on this, it becomes quite difficult to figure what library to choose. We'll proceed in order to growing difficulty:

• if you don't need performance and are only hosting a handful of servers (home usage or small business), use your operating system vendor's library, possibly with the compatibility layer for limited QUIC support.
• if you'd like to support QUIC and benefit and don't need 0-RTT on a small deployment, check if LibreSSL is packaged by your operating system vendor. If it it, it might be a solution.
• if you don't need performance but need QUIC and LibreSSL is not packaged by your operating system vendor, you should probably use QuicTLS. It's based on OpenSSL so it inherits its functional coverage and its performance problems, but adds QUIC on top of it. You'll just have to rebuild it yourself after each and every announce of new OpenSSL version.
• if you need performance, and want QUIC, and are willing to build your own SSL packages, and do not want to invest much time on the SSL library maintenance, AWS-LC might be for you. It provides periodic releases and should offer the same functional coverage as OpenSSL.
• if you need strong performance, prefer to stick to a stable haproxy version, are willing to invest time to finely tune an SSL stack to get the most of your systems, and you do not use funky features, then you should very likely give wolfSSL a try (and please make sure to always use their most recent version as the project is catching up quickly with missing features).
• if you need the performance of 1.1.1 with its full features and with QUIC, and have a lot of time to invest on this, then there might also be the option of maintaining your own package based on the updated 1.1.1 security fixes from your distro and adding the QuicTLS patches on top of it.