API to directly open TLS connections, instead of upgrading an existing socket

[armanbilge]

Background: currently to get a TLSSocket, you first create a non-encrypted Socket, then upgrade it via TLSContext to get a TLSSocket. This proposal is for new TLSContext APIs to directly create client/server TLSSockets.

Motivation:

• On Native, s2n-tls is capable of interfacing directly with the underlying socket's file descriptor. This should have higher performance and is probably easier to implement than redirecting it through an FS2 Socket.

  Even more compelling, s2n-tls also supports using Kernel TLS, where all the encryption/decryption happens in kernel-space. This minimizes data copies.

• On JS, the upgrade is implemented by a costly Node.js Socket <-> FS2 Socket <-> Node.js Socket <-> Node.js TLS Socket <-> FS2 TLS Socket conversion. In Node.js it is possible to directly open TLS connections/servers directly, and thus skip a few layers of conversion.

I'm not aware of any motivation to do this on the JVM, at least with the JDK. Probably a hypothetical Netty-based TLSContext could take advantage of this.

Questions:

1. Could e.g. Ember and Skunk take advantage of such an API, instead of manually upgrading?
2. Alternatively, could we make these optimizations within the upgrade mechanism, without exposing a new API? Seems hard, since in theory the user could continue doing things with the raw Socket even after upgrading it. If we assume that won't happen, then maybe it can work.

[armanbilge]

On Native, s2n-tls is capable of interfacing directly with the underlying socket's file descriptor. This should have higher performance

There is a significant caveat to this: s2n-tls does not (and cannot without redesign) use io_uring for dispatching the reads/writes. So it might not have higher performance compared to our io_uring-powered sockets.

There's still a chance for kTLS to be compatible with io_uring, depending on the implementation strategy taken.

• https://github.com/aws/s2n-tls/issues/773