Contributing new TLS implementation (s2n-tls)

[avirtuos]

Would you be open to accepting a contribution of a new TLS implementation to go alongside openssl / boring / rustls? It seems that user of Pingora can not presently provide their own implementation, despite it being mostly pluggable already because of this: https://github.com/cloudflare/pingora/blob/128aafe4ce8d84a1d768277a5f4aaf635aa25fae/pingora-core/src/protocols/tls/mod.rs

I am interested in s2n support because of its focus on security, especially its design focus on blinding side-channels.

It would be great to understand if you'd be open to such a contribution and/or making the TLS implementation truly pluggable before I go too much further down the path of this experiment.

Thanks.

[drcaramelsyrup]

Sure, we are not opposed to accepting new TLS implementations. The existing way the TLS APIs are set up should make it straightforward to configure a new implementation. This implementation looks notable enough to include.

[avirtuos]

Great. Thanks for the quick reply. I'll keep you posted once we have a PR worth sharing and some testing evidence and perf data.

[avirtuos]

@drcaramelsyrup one of my co-workers @gilbertw1 just posted a PR with an initial version of S2N support that we've been testing internally. Please let us know if you'd like to see any changes. In our testing so far, this has proven to be a bit more performant than openssl / boring / rustls and in our circles we prefer its security posture as well. Though we are mainly interesting in the security posture and robust support for TLS PSK as primary drivers for this contribution.