> On Apr 28, 2022, at 4:49 AM, Boris Pismenny <borispismenny@xxxxxxxxx> wrote: > > On 18/04/2022 19:49, 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. >> > > Thanks for posting this. As we discussed offline, I think this approach > is more manageable compared to a full in-kernel TLS handshake. A while > ago, I've hacked around TLS to implement the data-path for NVMe-TLS and > the data-path is indeed very simple provided an infrastructure such as > this one. > > Making this more generic is desirable, and this obviously requires > supporting multiple listeners for multiple protocols (TLS, DTLS, QUIC, > PSP, etc.), which suggests that it will reside somewhere outside of net/tls. > Moreover, there is a need to support (TLS) control messages here too. > These will occasionally require going back to the userspace daemon > during kernel packet processing. A few examples are handling: TLS rekey, > TLS close_notify, and TLS keepalives. I'm not saying that we need to > support everything from day-1, but there needs to be a way to support these. I agree that control messages need to be handled as well. For the moment, the prototype simply breaks the connection when a control message is encountered, and a new session is negotiated. That of course is not the desired long-term solution. If we believe that control messages are going to be distinct for each transport security layer, then perhaps we cannot make the handshake mechanism generic -- it will have to be specific to each security layer. Just a thought. > A related kernel interface is the XFRM netlink where the kernel asks a > userspace daemon to perform an IKE handshake for establishing IPsec SAs. > This works well when the handshake runs on a different socket, perhaps > that interface can be extended to do handshakes on a given socket that > lives in the kernel without actually passing the fd to userespace. If we > avoid instantiating a full socket fd in userspace, then the need for an > accept(2) interface is reduced, right? Certainly piping the handshake messages up to user space instead of handing off a socket is possible. The TLS libraries would need to tolerate this, and GnuTLS (at least) appears OK with performing a handshake on an AF_TLSH socket. However, I don't see a need to outright avoid passing a connected endpoint to user space. The only difficulty with it seems to be that it hasn't been done before in quite this way. -- Chuck Lever
