netdev - Re: [PATCH RFC 4/5] net/tls: Add support for PF

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <33F93223-519B-47E9-8578-B18DCB8F1F8E@oracle.com>
Date:   Thu, 28 Apr 2022 15:24:55 +0000
From:   Chuck Lever III <chuck.lever@...cle.com>
To:     Boris Pismenny <borispismenny@...il.com>
CC:     Alexander Krizhanovsky <ak@...pesta-tech.com>,
        Simo Sorce <simo@...hat.com>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        "linux-cifs@...r.kernel.org" <linux-cifs@...r.kernel.org>,
        Linux NFS Mailing List <linux-nfs@...r.kernel.org>,
        "linux-nvme@...ts.infradead.org" <linux-nvme@...ts.infradead.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        Jakub Kicinski <kuba@...nel.org>
Subject: Re: [PATCH RFC 4/5] net/tls: Add support for PF_TLSH (a TLS handshake
 listener)



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