[PATCH RFC 4/5] net/tls: Add support for PF_TLSH (a TLS handshake listener)

[Chuck Lever III]

> On Apr 28, 2022, at 4:49 AM, Boris Pismenny <borispismenny at gmail.com> 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