Hi Jakub- > On Apr 25, 2022, at 1:14 PM, Jakub Kicinski <kuba@xxxxxxxxxx> wrote: > > On Mon, 18 Apr 2022 12:49:50 -0400 Chuck Lever wrote: >> In-kernel TLS consumers need a way to perform a TLS handshake. In >> the absence of a handshake implementation in the kernel itself, a >> mechanism to perform the handshake in user space, using an existing >> TLS handshake library, is necessary. >> >> I've designed a way to pass a connected kernel socket endpoint to >> user space using the traditional listen/accept mechanism. accept(2) >> gives us a well-understood way to materialize a socket endpoint as a >> normal file descriptor in a specific user space process. Like any >> open socket descriptor, the accepted FD can then be passed to a >> library such as openSSL to perform a TLS handshake. >> >> This prototype currently handles only initiating client-side TLS >> handshakes. Server-side handshakes and key renegotiation are left >> to do. >> >> Security Considerations >> ~~~~~~~~ ~~~~~~~~~~~~~~ >> >> This prototype is net-namespace aware. >> >> The kernel has no mechanism to attest that the listening user space >> agent is trustworthy. >> >> Currently the prototype does not handle multiple listeners that >> overlap -- multiple listeners in the same net namespace that have >> overlapping bind addresses. > > Create the socket in user space, do all the handshakes you need there > and then pass it to the kernel. This is how NBD + TLS works. Scales > better and requires much less kernel code. The RPC-with-TLS standard allows unencrypted RPC traffic on the connection before sending ClientHello. I think we'd like to stick with creating the socket in the kernel, for this reason and for the reasons Hannes mentions in his reply. -- Chuck Lever
