From: Chuck Lever III <firstname.lastname@example.org> To: Jakub Kicinski <email@example.com> Cc: Hannes Reinecke <firstname.lastname@example.org>, Sagi Grimberg <email@example.com>, netdev <firstname.lastname@example.org>, Linux NFS Mailing List <email@example.com>, "firstname.lastname@example.org" <email@example.com>, CIFS <firstname.lastname@example.org>, linux-fsdevel <email@example.com>, Alexander Krizhanovsky <firstname.lastname@example.org>, Boris Pismenny <email@example.com>, "firstname.lastname@example.org" <email@example.com> Subject: Re: [PATCH RFC 4/5] net/tls: Add support for PF_TLSH (a TLS handshake listener) Date: Wed, 27 Apr 2022 15:24:25 +0000 [thread overview] Message-ID: <238292F3-12FD-49EB-834F-F84A06AA866A@oracle.com> (raw) In-Reply-To: <firstname.lastname@example.org> > On Apr 26, 2022, at 8:03 PM, Jakub Kicinski <email@example.com> wrote: > > On Tue, 26 Apr 2022 17:58:39 +0200 Hannes Reinecke wrote: >> >> - Establishing sockets from userspace will cause issues during >> reconnection, as then someone (aka the kernel) will have to inform >> userspace that a new connection will need to be established. >> (And that has to happen while the root filesystem is potentially >> inaccessible, so you can't just call arbitrary commands here) >> (Especially call_usermodehelper() is out of the game) > > Indeed, we may need _some_ form of a notification mechanism and that's > okay. Can be a (more generic) socket, can be something based on existing > network storage APIs (IDK what you have there). > > My thinking was that establishing the session in user space would be > easiest. We wouldn't need all the special getsockopt()s which AFAIU > work around part of the handshake being done in the kernel, and which, > I hope we can agree, are not beautiful. In the prototype, the new socket options on AF_TLSH sockets include: #define TLSH_PRIORITIES 1 /* Retrieve TLS priorities string */ #define TLSH_PEERID 2 /* Retrieve peer identity */ #define TLSH_HANDSHAKE_TYPE 3 /* Retrieve handshake type */ #define TLSH_X509_CERTIFICATE 4 /* Retrieve x.509 certificate */ PRIORITIES is the TLS priorities string that the GnuTLS library uses to parametrize the handshake (which TLS versions, ciphers, and so on). PEERID is a keyring serial number for the key that contains the a Pre-Shared Key (for PSK handshakes) or the private key (for x.509 handshakes). HANDSHAKE_TYPE is an integer that represents the type of handshake being requested: ClientHello, ServerHello, Rekey, and so on. This option enables the repertoire of handshake types to be expanded. X509_CERTIFICATE is a keyring serial number for the key that contains an x.509 certificate. When each handshake is complete, the handshake agent instantiates the IV into the passed-in socket using existing kTLS socket options before it returns the endpoint to the kernel. There is nothing in these options that indicates to the handshake agent what upper layer protocol is going to be used inside the TLS session. ---- The new AF_TLSH socket options are not there because the handshake is split between the kernel and user space. They are there because the initial requester is (eg, in the case of NFS) mount.nfs, another user space program. mount.nfs has to package up an x.509 cert or pre-shared key and place it on a keyring to make it available to the handshake agent. The basic issue is that the administrative interfaces that parametrize the handshakes are quite distant from the in-kernel consumers that make handshake requests. ---- Further, in order to support server side TLS handshakes in the kernel, we really do have to pass a kernel-created socket up to user space. NFSD (and maybe the NVMe target) use in-kernel listeners to accept incoming connections. Each new endpoint is created in the kernel. So if you truly seek generality in this facility, the user space componentry must work with passed-in sockets rather than creating them in user space. -- Chuck Lever
next prev parent reply other threads:[~2022-04-27 15: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 [this message] 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 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 \ --in-reply-to=238292F3-12FD-49EB-834F-F84A06AA866A@oracle.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 \ --email@example.com \ --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.