Adding a second TLS implementation

[Kevin Burke]

Thanks for the prompt reply.

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.


If implemented, would the additional wrapper functions make it possible to
compile in a memory safe TLS integration as a third party module?

On Wed, Feb 10, 2021 at 6:38 PM Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> 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 https://github.com/ctz/rustls. 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
> http://mdounin.ru/
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20210210/0ffc9cdd/attachment-0001.htm>