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

[Chuck Lever III]

> On Apr 28, 2022, at 9:12 AM, Simo Sorce <simo at redhat.com> wrote:
> 
> On Thu, 2022-04-28 at 11:49 +0300, Boris Pismenny 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.
>> 
>> 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?
> 
> JFYI:
> For in kernel NFSD hadnshakes we also use the gssproxy unix socket in
> the kernel, which allows GSSAPI handshakes to be relayed from the
> kernel to a user space listening daemon.
> 
> The infrastructure is technically already available and could be
> reasonably simply extended to do TLS negotiations as well.

To fill in a little about our design thinking:

We chose not to use either gssproxy or gssd for the TLS handshake
prototype so that we don't add a dependency on RPC infrastructure
for other TLS consumers such as NVMe. Non-RPC consumers view that
kind of dependency as quite undesirable.

Also, neither of those existing mechanisms helped us address the
issue of passing a connected socket endpoint.
listen/poll/accept/close addresses that issue quite directly.


--
Chuck Lever