Adding a second TLS implementation

Maxim Dounin mdounin at
Thu Feb 11 02:38:25 UTC 2021


On Wed, Feb 10, 2021 at 05:02:54PM -0800, Kevin Burke wrote:

> Hi,
> There has been a recent push by some members of the security community to
> try to make more critical code run in memory safe languages, because of the
> high prevalence of security issues related to memory safety, for example,
> use-after-free, double-free or heap buffer vulnerabilities.
> In that light, I was wondering if you'd be open to adding a second TLS
> implementation that could be used in place of OpenSSL. Ideally, the target
> would be a TLS implementation in a memory safe language, for example,
> rustls, available at Curl just merged a
> patch to support the rustls backend.
> This would require a lot of changes to make the TLS implementation portable
> so before investigating it I figured I would see if you're open to it at
> all.

We already support three distinct SSL libraries: OpenSSL, 
LibreSSL, and BoringSSL.  It is unlikely that support for other 
libraries will be considered: that's already way more than it's 
comfortable to support.

We are, however, open for patches to improve portability of the 
SSL code, such as providing ngx_ssl_*() wrapper functions in (very 
few, actually) places where SSL library interfaces are used 
directly rather than via appropriate ngx_ssl_*() wrappers.

Maxim Dounin

More information about the nginx-devel mailing list