From: Hannes Reinecke <firstname.lastname@example.org> To: Chuck Lever III <email@example.com>, Boris Pismenny <firstname.lastname@example.org> Cc: Alexander Krizhanovsky <email@example.com>, Simo Sorce <firstname.lastname@example.org>, linux-fsdevel <email@example.com>, "firstname.lastname@example.org" <email@example.com>, Linux NFS Mailing List <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, "email@example.com" <firstname.lastname@example.org>, Jakub Kicinski <email@example.com> Subject: Re: [PATCH RFC 4/5] net/tls: Add support for PF_TLSH (a TLS handshake listener) Date: Fri, 29 Apr 2022 08:25:40 +0200 [thread overview] Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <33F93223-519B-47E9-8578-B18DCB8F1F8E@oracle.com> On 4/28/22 17:24, Chuck Lever III wrote: > > >> On Apr 28, 2022, at 4:49 AM, Boris Pismenny <email@example.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. > Yeah, and I guess that'll be the hard part. We would need to design an entirely data path for gnutls when going down that path. The beauty of the fd-passing idea is that gnutls (and openssl for that matter) will 'just work' (tm), without us have to do larger surgery there. Just for reference, I've raised an issue with gnutls to accept long identifiers in TLS 1.3 (issue #1323), which is required for NVMe-over-TLS support. That one is lingering for over two months now. And that's a relatively simple change; I don't want to imagine how long it'd take to try to push in a larger redesign... Cheers, Hannes -- Dr. Hannes Reinecke Kernel Storage Architect firstname.lastname@example.org +49 911 74053 688 SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg HRB 36809 (AG Nürnberg), Geschäftsführer: Felix Imendörffer
next prev parent reply other threads:[~2022-04-29 6:25 UTC|newest] Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-04-18 16:49 [PATCH RFC 0/5] Implement a TLS handshake upcall Chuck Lever 2022-04-18 16:49 ` [PATCH RFC 1/5] net: Add distinct sk_psock field Chuck Lever 2022-04-21 7:35 ` Hannes Reinecke 2022-07-13 4:46 ` Hawkins Jiawei 2022-07-13 4:46 ` Hawkins Jiawei 2022-04-18 16:49 ` [PATCH RFC 2/5] tls: build proto after context has been initialized Chuck Lever 2022-04-25 17:11 ` Jakub Kicinski 2022-04-25 17:51 ` Chuck Lever III 2022-05-20 16:39 ` Chuck Lever III 2022-04-18 16:49 ` [PATCH RFC 3/5] net/tls: Add an AF_TLSH address family Chuck Lever 2022-04-21 7:35 ` Hannes Reinecke 2022-04-18 16:49 ` [PATCH RFC 4/5] net/tls: Add support for PF_TLSH (a TLS handshake listener) Chuck Lever 2022-04-21 7:36 ` Hannes Reinecke 2022-04-25 17:14 ` Jakub Kicinski 2022-04-26 9:43 ` Hannes Reinecke 2022-04-26 14:29 ` Sagi Grimberg 2022-04-26 15:02 ` Jakub Kicinski 2022-04-26 15:58 ` Hannes Reinecke 2022-04-27 0:03 ` Jakub Kicinski 2022-04-27 15:24 ` Chuck Lever III 2022-04-28 7:26 ` Hannes Reinecke 2022-04-28 13:30 ` Jakub Kicinski 2022-04-28 13:51 ` Hannes Reinecke 2022-04-28 14:09 ` Benjamin Coddington 2022-04-28 21:08 ` Jakub Kicinski 2022-05-24 10:05 ` [ovs-dev] " Ilya Maximets 2022-04-26 14:55 ` Jakub Kicinski 2022-04-26 13:48 ` Chuck Lever III 2022-04-26 14:55 ` Jakub Kicinski 2022-04-26 15:58 ` Chuck Lever III 2022-04-26 23:47 ` Jakub Kicinski 2022-04-27 14:42 ` Chuck Lever III 2022-04-27 23:53 ` Jakub Kicinski 2022-04-28 1:29 ` Chuck Lever III 2022-04-28 21:08 ` Jakub Kicinski 2022-04-28 21:54 ` Chuck Lever III 2022-04-28 8:49 ` Boris Pismenny 2022-04-28 13:12 ` Simo Sorce 2022-04-29 15:19 ` Chuck Lever III 2022-04-28 15:24 ` Chuck Lever III 2022-04-29 6:25 ` Hannes Reinecke [this message] 2022-04-18 16:49 ` [PATCH RFC 5/5] net/tls: Add observability for AF_TLSH sockets Chuck Lever 2022-04-21 7:36 ` Hannes Reinecke
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: [PATCH RFC 4/5] net/tls: Add support for PF_TLSH (a TLS handshake listener)' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.