<div dir="ltr">Thanks for the prompt reply.<div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">We are, however, open for patches to improve portability of the<br>SSL code, such as providing ngx_ssl_*() wrapper functions in (very<br>few, actually) places where SSL library interfaces are used<br>directly rather than via appropriate ngx_ssl_*() wrappers.</blockquote><div><br></div><div>If implemented, would the additional wrapper functions make it possible to compile in a memory safe TLS integration as a third party module? </div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 10, 2021 at 6:38 PM Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
<br>
On Wed, Feb 10, 2021 at 05:02:54PM -0800, Kevin Burke wrote:<br>
<br>
> Hi,<br>
> There has been a recent push by some members of the security community to<br>
> try to make more critical code run in memory safe languages, because of the<br>
> high prevalence of security issues related to memory safety, for example,<br>
> use-after-free, double-free or heap buffer vulnerabilities.<br>
> <br>
> In that light, I was wondering if you'd be open to adding a second TLS<br>
> implementation that could be used in place of OpenSSL. Ideally, the target<br>
> would be a TLS implementation in a memory safe language, for example,<br>
> rustls, available at <a href="https://github.com/ctz/rustls" rel="noreferrer" target="_blank">https://github.com/ctz/rustls</a>. Curl just merged a<br>
> patch to support the rustls backend.<br>
> <br>
> This would require a lot of changes to make the TLS implementation portable<br>
> so before investigating it I figured I would see if you're open to it at<br>
> all.<br>
<br>
We already support three distinct SSL libraries: OpenSSL, <br>
LibreSSL, and BoringSSL.  It is unlikely that support for other <br>
libraries will be considered: that's already way more than it's <br>
comfortable to support.<br>
<br>
We are, however, open for patches to improve portability of the <br>
SSL code, such as providing ngx_ssl_*() wrapper functions in (very <br>
few, actually) places where SSL library interfaces are used <br>
directly rather than via appropriate ngx_ssl_*() wrappers.<br>
<br>
-- <br>
Maxim Dounin<br>
<a href="http://mdounin.ru/" rel="noreferrer" target="_blank">http://mdounin.ru/</a><br>
_______________________________________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org" target="_blank">nginx-devel@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" rel="noreferrer" target="_blank">http://mailman.nginx.org/mailman/listinfo/nginx-devel</a><br>
</blockquote></div>