I've been attempting to use xprtsec=tls with nfs, and ran into #44 so compiled my own version from f28f084 and ran into this issue:

Built from ktls-utils 0.11-dev on Mar 20 2024 15:29:20
x.509 priority string: SECURE256:+SECURE128:-COMP-ALL:-VERS-ALL:+VERS-TLS1.3:%NO_TICKETS:-CIPHER-ALL:+AES-256-GCM:+CHACHA20-POLY1305:+AES-128-GCM:+AES-128-CCM
PSK priority string: SECURE256:+SECURE128:-COMP-ALL:-VERS-ALL:+VERS-TLS1.3:%NO_TICKETS:-CIPHER-ALL:+AES-256-GCM:+CHACHA20-POLY1305:+AES-128-GCM:+AES-128-CCM:+PSK:+DHE-PSK:+ECDHE-PSK
Querying the handshake service
Parsing a valid netlink message
No peer identities found
No certificates found
Name or service not known
System config file: /etc/gnutls/config
gnutls(2): Initializing needed PKCS #11 modules
gnutls(2): p11: Initializing module: p11-kit-trust
gnutls(2): p11: No login requested.
gnutls(3): p11 attrs: CKA_CLASS (CERT), CKA_CERTIFICATE_TYPE
gnutls(3): p11 attrs: CKA_TRUSTED
gnutls(3): p11 attrs: CKA_CERTIFICATE_CATEGORY=CA
gnutls(2): p11: No login requested.
gnutls(3): p11 attrs: CKA_CLASS (CERT), CKA_CERTIFICATE_TYPE
gnutls(3): p11 attrs: CKA_TRUSTED
gnutls(3): p11 attrs: CKA_CERTIFICATE_CATEGORY=CA
gnutls(3): ASSERT: pkcs11.c[find_multi_objs_cb]:3105
gnutls(3): ASSERT: pkcs11.c[gnutls_pkcs11_obj_list_import_url3]:3416
System trust: Loaded 170 certificate(s).
Retrieved 2 x.509 server certificate(s) from /var/lib/lego/certificates/index.iscute.moe.crt
Retrieved private key from /var/lib/lego/certificates/index.iscute.moe.key
gnutls(5): REC[0x629c723ff5c0]: Allocating epoch #0
gnutls(3): ASSERT: handshake.c[gnutls_handshake]:2829
gnutls: No or insufficient priorities were set. (-326)
gnutls(5): REC[0x629c723ff5c0]: Start of epoch cleanup
gnutls(5): REC[0x629c723ff5c0]: End of epoch cleanup
gnutls(5): REC[0x629c723ff5c0]: Epoch #0 freed
Handshake with 'unknown' (2a11:f2c0:acac:10:783b:267d:d87e:9296) failed

I then tried version 591022d and then all is working fine. I didn't test f28f084.

Ultimately we would like to extend TLS protection to the root filesystem, for instance by supporting NFSROOT with TLS, or by supporting a root filesystem that resides on an NVMe that is protected with TLS. This goal has some special challenges when tlshd uses files that live on the root filesystem that is protected by TLS.

To work around these challenges, it might be possible to place tlshd and authentication material in the initrd, or the AM could placed in non-root storage, such as a TPM. The details need to be worked out, so parking this issue here for further thought and comment.

We believe that it might be common that either a TLS-enabled client or server might reside in more than one trust domain. It should be possible for the upper layer consumer (eg, NFS/RPC) to specify both a certificate and a specific trust bundle when initiating a TLS session.

Currently, an administrator can specify that tlshd use the system's default trust bundle, or one particular trust bundle for all in-kernel TLS consumers. This mechanism needs to be more flexible.

(mirrored from our bugzilla)
A partner of ours has seen a crash in __sys_recvfrom during NVMe-oF port toggles:

[ 2455.760904] RIP: 0010:__sys_recvfrom+0x94/0x110
[ 2455.760920] Code: 64 48 8d 54 24 04 44 89 ef 48 89 e6 e8 55 cd ff ff 48 85 c0 49 89 c5 74 49 48 8b 50 10 89 d8 48 8d 74 24 18 83 c8 40 4c 89 ef 42 41 08 0f 45 d8 89 da e8 2e d8 ff ff 48 85 ed 89 04 24 74 1a
[ 2455.760932] RSP: 0018:ffffa523cbb1bd00 EFLAGS: 00010202
[ 2455.760939] RAX: 0000000000000040 RBX: 0000000000000000 RCX: 0000000000000000
[ 2455.760946] RDX: 0000000000000000 RSI: ffffa523cbb1bd18 RDI: ffff926f7dfca700
[ 2455.760952] RBP: 0000000000000000 R08: 0000000000000006 R09: 0000000000000000
[ 2455.760957] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa523cbb1bd80
[ 2455.760963] R13: ffff926f7dfca700 R14: 0000000000000000 R15: 0000000000000000
[ 2455.760970] FS: 00007f1aa080f940(0000) GS:ffff927327c00000(0000) knlGS:0000000000000000
[ 2455.760977] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 2455.760984] CR2: 0000000000000041 CR3: 00000004d7dce003 CR4: 00000000003706e0
[ 2455.760990] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 2455.760996] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 2455.761003] Call Trace:
[ 2455.761009]
[ 2455.761033] ? __die_body+0x1a/0x60
[ 2455.761043] ? page_fault_oops+0x131/0x510
[ 2455.761053] ? ip_output+0x5d/0xf0
[ 2455.761064] ? ip_output+0x5d/0xf0
[ 2455.761070] ? exc_page_fault+0x69/0x150
[ 2455.761079] ? asm_exc_page_fault+0x22/0x30
[ 2455.761089] ? __sys_recvfrom+0x94/0x110
[ 2455.761095] ? fsnotify_destroy_marks+0x24/0x160
[ 2455.761104] ? __call_rcu_common.constprop.76+0x114/0x7f0
[ 2455.761111] ? __rseq_handle_notify_resume+0xab/0x4d0
[ 2455.761120] __x64_sys_recvfrom+0x24/0x30
[ 2455.761125] do_syscall_64+0x5b/0x80
[ 2455.761130] ? switch_fpu_return+0x4c/0xd0
[ 2455.761135] ? exit_to_user_mode_prepare+0x142/0x220
[ 2455.761141] ? syscall_exit_to_user_mode+0x1e/0x40
[ 2455.761147] ? do_syscall_64+0x67/0x80
[ 2455.761150] ? do_user_addr_fault+0x446/0x890
[ 2455.761157] ? exc_page_fault+0x69/0x150
[ 2455.761162] entry_SYSCALL_64_after_hwframe+0x72/0xdc
[ 2455.761167] RIP: 0033:0x7f1a9fb30ef9
[ 2455.761203] Code: 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 80 3d 39 cb 0d 00 00 41 89 ca 74 1c 45 31 c9 45 31 c0 b8 2d 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 67 c3 66 0f 1f 44 00 00 55 48 83 ec 20 48 89
[ 2455.761210] RSP: 002b:00007ffff80abe78 EFLAGS: 00000246 ORIG_RAX: 000000000000002d
[ 2455.761215] RAX: ffffffffffffffda RBX: 00000000011521b0 RCX: 00007f1a9fb30ef9
[ 2455.761218] RDX: 0000000000000005 RSI: 0000000001153e9b RDI: 0000000000000006
[ 2455.761222] RBP: 0000000001153e40 R08: 0000000000000000 R09: 0000000000000000
[ 2455.761225] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
[ 2455.761228] R13: 0000000000000005 R14: 0000000000000005 R15: 00007ffff80abf7c
[ 2455.761233]
[ 2455.761235] Modules linked in: nvme_tcp rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfsv3 nfs_acl nfs lockd grace fscache netfs rpcrdma sunrpc rdma_ucm ib_umad ib_iser rdma_cm iw_cm ib_ipoib libiscsi scsi_transport_iscsi ib_cm af_packet iscsi_ibft iscsi_boot_sysfs rfkill mlx5_ib ib_uverbs macsec ib_core ipmi_ssif intel_rapl_msr intel_rapl_common mlx5_core intel_uncore_frequency intel_uncore_frequency_common sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel iTCO_wdt mlxfw intel_pmc_bxt acpi_ipmi psample iTCO_vendor_support ipmi_si kvm tls joydev lpc_ich i2c_i801 mei_me ipmi_devintf pci_hyperv_intf(X) i2c_smbus mei ipmi_msghandler be2net pcspkr mfd_core irqbypass button ac dm_multipath dm_mod fuse dmi_sysfs ip_tables x_tables hid_generic usbhid lpfc nvmet_fc nvmet nvme_keyring configfs nvme_fc ahci nvme_fabrics libahci nvme_core libata megaraid_sas crc32_pclmul nvme_auth scsi_transport_fc sd_mod scsi_dh_emc ghash_clmulni_intel scsi_dh_rdac sha512_ssse3 scsi_dh_alua t10_pi sha256_ssse3 xhci_pci
[ 2455.761326] sha1_ssse3 xhci_pci_renesas xhci_hcd crc64_rocksoft_generic ehci_pci crc64_rocksoft ehci_hcd sg aesni_intel usbcore crypto_simd scsi_mod cryptd mgag200 i2c_algo_bit crc64 wmi btrfs blake2b_generic libcrc32c crc32c_intel xor raid6_pq msr
[ 2455.761371] Supported: No, Unreleased kernel
[ 2455.761376] CR2: 0000000000000041

Some documentation on how a kernel driver should use the handshake API would be helpful.

In tlshd_file_open(), tlshd uses openat2(..., RESOLVE_NO_SYMLINKS). This is in turn used to load the key material when nothing is provided via the keyring.

This seems overly strict, in my opinion. A lot of times certificates and keys are set up in a way they can be rotated by changing symlinks. For example, this is common when using Let's Encrypt with certbot, where the canonical location for key material is /etc/letsencrypt/live/<host>/privkey.pem, which are symlinks to /etc/letsencrypt/archive/<host>/privkey$GENERATION.pem. Every time the certificate gets renewed, the symlinks are updated.

Perhaps there is some security implication I am missing, but I would consider tlshd.conf as a trusted source, so I don't see the need for additional paranoia regarding symlinks.

Some authentication material (eg, x.509 certificates) might be stored in a local TPM rather than in files. For example, if TLS is used to protect traffic to and from the block device on which the root filesystem is stored, keeping certificates in the root filesystem is probably not feasible.

To use a TPM, some mechanism might access the TPM and move the needed authentication material into a keyring that can then be accessed by tlshd.

My TLS handshake was failing and verbose output would only have a general ENOENT error for the open without a name but using the strace revealed that tlshd was trying to open a file "/root/server.crt " where only "/root/server.crt" (no space in the end) existed.

The value in "authenticate.X" section for pathname is sensitive to appended spaces (possible tabs too).

In a test environment, I have a root CA, intermediate CA and the certs for the server/client (signed by the intermediate CA).

The root CA is in the system-wide trust store (/etc/ssl/certs), but the intermediate CA is not.

If I configure /etc/tlshd.conf on the server/client with x509.certificate= pointing to a bundle with the intermediate and server/client cert, things don't work (the log says the cert isn't trusted).

If I manually add the intermediate CA to /etc/ssl/certs, everything works as expected.

A CI build for i386 failed with the following error:

config.c: In function 'tlshd_config_read_datum':
config.c:155:52: error: comparison of integer expressions of different signedness: '__off_t' {aka 'long int'} and 'unsigned int' [-Werror=sign-compare]
  155 |         if (statbuf.st_size < 0 || statbuf.st_size > UINT_MAX) {
      |                                                    ^

The full build log is at https://salsa.debian.org/kernel-team/ktls-utils/-/jobs/4457752.

I am running on Ubuntu 24.04 LTS.

I installed the dependencies as suggested by Issue #47:

sudo apt install -y automake pkg-config cmake-data gnutls-bin libgnutls28-dev libkeyutils-dev libglib2.0-dev libnl-3-dev libnl-genl-3-dev

I removed the last 2 dependencies libgnutls30=3.7.3-4ubuntu1.4 and libgmp10=2:6.2.1+dfsg-3ubuntu1 since they could not be found.
If I attempt to install libgnutls30 and libgmp10 it will say they are already installed.

Then I cloned this repo and followed installation instructions, with no errors:

git clone https://github.com/oracle/ktls-utils
cd ktls-utils
./autogen.sh
./configure --with-systemd
make
sudo make install
sudo systemctl daemon-reload
sudo systemctl enable --now tlshd

When I run sudo systemctl, I see tlshd.service listed as loaded failed failed (corresponding to the fields LOAD ACTIVE SUB).

The package has been thoroughly reviewed by multiple security teams. We are confident it is safe to include in Linux distributions. To encourage this, remove the "Experimental" disclaimers from the source code.

The --with-systemd option to the configure script allows specifying a directory to install in. However, systemd/Makefile.am has a hardcoded installation directory. It should use the "unitdir" substitution.

Currently it appears that when the server is configured with "xprtsec=mtls", any client certificate issued by any CA in the system trust store will be accepted. I would guess that this is not what administrators would want from client authentication.

I would expect to be able to configure a server to trust only client certificates issued by a specific CA (perhaps an internal CA) and/or client certificates for hostnames with a specific domain. But it possibly makes sense to allow specifying required values for all of the standard subject fields.

QUICv1 is specified by RFC 9000.

Because a QUICv1 connect transaction makes use of the TLS v1.3 handshake, we believe that in-kernel support for the QUIC transport protocol can and should make use of tlshd and its netlink upcall to perform that handshake on behalf of kernel consumers (such as SMB).

Ran into a strange behavior (possibly due to a flaky DNS setup). The problem was hit but not consistently reproducible. Using this report to keep track.

Test did:
sudo tcpdump -i ens160 -s 0 -w /tmp/0.trc &
sudo mount -o vers=4.1,xprtsec=tls 192.168.68.16:/export /mnt/t
ll /mnt/t/
cat /mnt/t/data/file
sudo umount /mnt/t

sudo mount -o vers=4.1,xprtsec=tls 192.168.68.16:/export /mnt/t
sudo umount /mnt/t

sudo mount -o vers=4.1,xprtsec=tls 192.168.68.16:/export /mnt/t
ll /mnt/t/linux
cat /mnt/t/linux/README
sudo umount /mnt/t

No failures were seen executing the setup.

This is the output of tlshd -s (nfs-tls-5.log):

tlshd[5200]: gnutls(4): EXT[0x1c36e00]: Preparing extension (Post Handshake Auth/49) for 'client hello'
tlshd[5200]: Handshake with netapp16.linux.fake (192.168.68.16) was successful
tlshd[5290]: Handshake with 'unknown' () failed
tlshd[5316]: gnutls(4): EXT[0x1c36e00]: Preparing extension (Post Handshake Auth/49) for 'client hello'
tlshd[5316]: Handshake with netapp16.linux.fake (192.168.68.16) was successful

This is the output of journalctl (nfs-tls-5.msg), all three mounts were successful:

Jul 11 11:42:10 netapp30.linux.fake tlshd[5200]: gnutls(4): EXT[0x1c36e00]: Preparing extension (Post Handshake Auth/49) for 'client hello'
Jul 11 11:42:10 netapp30.linux.fake tlshd[5200]: Handshake with netapp16.linux.fake (192.168.68.16) was successful
Jul 11 11:43:00 netapp30.linux.fake tlshd[5285]: gnutls(4): EXT[0x16a8e00]: Preparing extension (Post Handshake Auth/49) for 'client hello'
Jul 11 11:43:00 netapp30.linux.fake tlshd[5285]: Handshake with netapp16.linux.fake (192.168.68.16) was successful
Jul 11 11:43:08 netapp30.linux.fake tlshd[5316]: gnutls(4): EXT[0x1c36e00]: Preparing extension (Post Handshake Auth/49) for 'client hello'
Jul 11 11:43:08 netapp30.linux.fake tlshd[5316]: Handshake with netapp16.linux.fake (192.168.68.16) was successful

In this case, Wireshark is able to successfully decrypt/dissect all packets for the first and third mounts since the master key file only had two secrets.

In src/tlshd/tlshd.conf.man, the heading (and a comment) say that it is tlshd(8), but it should be tlshd.conf(5).

In scenarios where a client kernel makes multiple socket connections to the same server on behalf of the same upper layer protocol (eg, NFS with nconnect), we would like amortize the cost of TLS session set-up by utilizing the same session for all of these connections.

The config file is confused whether the section for authentication should be named 'authenticate' or 'authentication'.
The commit message for 91287dd ("tlshd: Reorganize tlshd.conf") states that

    - move the "keyrings" option to [authenticate]

yet the patch has:

-       keyrings = g_key_file_get_string_list(tlshd_configuration, "main",
+       keyrings = g_key_file_get_string_list(tlshd_configuration,
+                                             "authentication",
                                              "keyrings", &length, NULL);

and the provided configuration example has:

+[authenticate]
 #keyrings= <keyring>;<keyring>;<keyring>

and all the other X.509 setting are using 'authentication', too.

So what is it now?

RFC 9289 specifies an Application-Layer Protocol Negotiation (ALPN) identifier for RPC-with-TLS, in addition to new extended key usage OIDs for RPC-with-TLS. Either tlshd or the kernel's RPC stack need to deal with these during certificate verification.

Currently tlshd and the netlink upcall protocol support TCP sockets with TLS, but do not support UDP sockets with DTLS. Eventually we'd like tlshd to handle DTLS, though there is much less of a need.

FreeBSD's RPC-with-TLS implementation supports a security policy mechanism that enables an x.509-authenticated client to tell an NFS server to squash all requests within its TLS session to a single specific user ID. The user ID is specified within the subjectAltName field of the client's certificate. We'd like to add that support to ktls-utils and the Linux kernel's RPC client and server.

I experienced an error while running this command:
sudo ./tlshd -c ./tlshd.conf -s
The following is the error message reproduced:
tlshd[9499]: Built from ktls-utils 0.11-dev on Mar 30 2024 11:17:25
tlshd[9499]: x.509 priority string: SECURE256:+SECURE128:-COMP-ALL:-VERS-ALL:+VERS-TLS1.3:%NO_TICKETS:-CIPHER-ALL:+AES-256-GCM:+AES-128-GCM:+AES-128-CCM
tlshd[9499]: PSK priority string: SECURE256:+SECURE128:-COMP-ALL:-VERS-ALL:+VERS-TLS1.3:%NO_TICKETS:-CIPHER-ALL:+AES-256-GCM:+AES-128-GCM:+AES-128-CCM:+PSK:+DHE-PSK:+ECDHE-PSK
tlshd[9499]: PSK SHA256 priority string: SECURE256:+SECURE128:-COMP-ALL:-VERS-ALL:+VERS-TLS1.3:%NO_TICKETS:-CIPHER-ALL:+AES-128-GCM:+AES-128-CCM:+DHE-PSK:+ECDHE-PSK
tlshd[9499]: PSK SHA384 priority string: SECURE256:+SECURE128:-COMP-ALL:-VERS-ALL:+VERS-TLS1.3:%NO_TICKETS:-CIPHER-ALL:+AES-256-GCM:+DHE-PSK:+ECDHE-PSK
tlshd[9499]: Kernel handshake service is not available
tlshd[9499]: Shutting down.
DBG<1>/build/libnl3-3mLT0Q/libnl3-3.4.0/./lib/cache_mngt.c:308 nl_cache_mngt_unregister: Unregistered cache operations genl/family

Following the instructions provided in tlshd.conf.man, I have configured tlshd.conf. The configuration content is as follows:
[debug]
loglevel=1
tls=1
nl=1
[authenticate]
#keyrings= <keyring>;<keyring>;<keyring>
[authenticate.client]
x509.truststore= /home/Downloads/ktls-utils/cert/x509.truststore
x509.certificate= /home/Downloads/ktls-utils/cert/x509.certificate
x509.private_key= /home/Downloads/ktls-utils/cert/x509.private_key
[authenticate.server]
x509.truststore= /home/Downloads/ktls-utils/cert/x509.truststore
x509.certificate= /home/Downloads/ktls-utils/cert/x509.certificate
x509.private_key= /home/Downloads/ktls-utils/cert/x509.private_key
By the way, I have tried different tools to create x509.certificate and x509.private_key files, such as: openssel and gnutls.
I have been using the following command to configure CONFIG_TLS:
sudo modprobe tls
I ran the command sudo ./tlshd -c ./tlshd.conf -s, and afterward, I checked with lsmod | grep tls. I found that the returned information was tls 114688 0.

As I am not well-versed with TLS, could you please provide some ideas or guidance on how to resolve this issue? Any help would be greatly appreciated.

Systemd has the capability of extracting blobs from UEFI and stuffing them onto a keyring: systemd. TLS-enabled storage tools can then direct tlshd to a particular key and/or keyring to obtain authentication material instead of tlshd reading it from a file.

Related to #30

We've had several independent requests (and a PR or two) to re-add support for the "-n" option, which disables tlshd's server certificate validation checking when it runs on the client. Checking would be disabled only for "encryption-only" mode -- for mtls, both peers would continue to validate the other's certificate.

The argument is that it makes code development easier, or that it simplifies deployment. When debugging or developing code, it should be simple enough to use self-signed certificates, and distribute an appropriate CA bundle for these certificates. We don't feel this is a compelling use case at this time.

The main use case, then, would be the desire to make the deployment of clients that need only encryption completely free from the problems of distributing certificate material. Currently one can do this only when the server's certificate has been signed by a well-known certificate authority that is likely to already be present on clients.

Notably, however, without server certificate validation, a man-in-the-middle can pretend to be a server and thus intercept TLS sessions from a client. This renders encryption rather pointless.

I'm opening this issue to continue the discussion: Does deployment convenience outweigh strong security? Conversely, is there a secure way to deliver a configuration setting that makes client set-up simpler? Comment below.

If the kernel provides a peer name that's an IP address, tlshd performs a reverse DNS lookup to turn this into a domain name that can be used for checking against the peer's certificate.

In my testing, when handling the server side of a handshake, tlshd always gets an IP address, does a reverse DNS lookup, but doesn't use the result for checking the client certificate. When handling the client side, it may get an IP address or domain name, depending on how the server was specified in the mount attempt. In this case the domain name, possibly the result of a reverse DNS lookup, is used for checking the server certificate.

The problem with doing a reverse DNS lookup is that this is subject to the same sort of spoofing as any DNS lookup, which is part of what TLS certificates are meant to defend against. I think that attempting to mount from an NFS server specified by IP address, with authenticated TLS, would normally be an error and it should fail rather than invoking this insecure behaviour. Also, it is possible to have a certificate for IP addresses, which currently will be rejected by the client and should work.

Petr Pisar mentioned this in the Fedora package review:

FIX: The daemon does not respect distribution-wide crypto policies. It enables algorithms in tlshd_make_priorities_string() based on what Linux supported at build time of this package. Ideally the daemon should consult crypto policy <https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies/> and only enable a disjunction of what Linux offers and what user-space crypto policy mandates. Please contact <[[email protected]](mailto:[email protected])> for help. There is a possibility that Linux already does that in other way. Please get a crypto review from the security team on that mailing list.

Basically we need to only enable ciphers tlshd_make_priorities_string that are supported by the local (runtime) crypto policy.

Could you please share a template of the /etc/tlshd.conf contents?

I know the tlshd.conf details are explained in the respective tlshd.conf man page, but it would be a lot more helpful if you could display this in a proper template and add it to this git repo.

i try the following but then there is error:

./autogen.sh
./configure --with-systemd --> error

./configure: line 5433: syntax error near unexpected token 0.9.0' ./configure: line 5433: PKG_PROG_PKG_CONFIG(0.9.0)'

Then I cannot run "make" command.

It would be grateful if anyone could give a helping hand. Thanks in advance.

Session keys created by a TLS handshake are small and should be thrown out after a while (usually a certain number of payload bytes transferred within the session) to mitigate an attacker's ability to guess them.

The current handshake upcall does not support renegotiation. Instead, it treats a key reneg request as an error that is fatal to a session, then sets up a fresh session. This is typically not a significant problem because RPC connections/sessions are long-lived.

We would like the netlink upcall protocol and tlshd eventually to handle renegotiation. In this case, the upcall would pass a socket that already has a TLS session on it, and tlshd would redirect that to the library so that a reneg handshake can be done. The result should be that a fresh session key is plugged into the socket via setsockopt(3).