Date: Sun, 26 Jan 2020 20:08:25 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: John Baldwin <jhb@FreeBSD.org>, "freebsd-current@FreeBSD.org" <freebsd-current@FreeBSD.org> Subject: Re: how to use the ktls Message-ID: <YQBPR0101MB1427F6950084C3CA30713A75DD080@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <5be57c87-90fe-fcbe-ea37-bdb1bcff2da8@FreeBSD.org> References: <YQBPR0101MB142760894682CA3663CB53BDDD3F0@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM>, <5be57c87-90fe-fcbe-ea37-bdb1bcff2da8@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John Baldwin wrote:=0A=
[stuff snipped]=0A=
>Hmmm, this might be a fair bit of work indeed.=0A=
>=0A=
>Right now KTLS only works for transmit (though I have some WIP for receive=
).=0A=
>=0A=
>KTLS does assumes that the initial handshake and key negotiation is handle=
d by=0A=
>OpenSSL. OpenSSL uses custom setockopt() calls to tell the kernel which=
=0A=
>session keys to use.=0A=
>=0A=
>I think what you would want to do is use something like OpenSSL_connect() =
in=0A=
>userspace, and then check to see if KTLS "worked". If it did, you can tel=
l=0A=
>the kernel it can write to the socket directly, otherwise you will have to=
=0A=
>bounce data back out to userspace to run it through SSL_write() and have=
=0A=
>userspace do SSL_read() and then feed data into the kernel.=0A=
>=0A=
>The pseudo-code might look something like:=0A=
>=0A=
>SSL *s;=0A=
>=0A=
>s =3D SSL_new(...);=0A=
>=0A=
>/* fd is the existing TCP socket */=0A=
>SSL_set_fd(s, fd);=0A=
>OpenSSL_connect(s);=0A=
>if (BIO_get_ktls_send(SSL_get_wbio(s)) {=0A=
> /* Can use KTLS for transmit. */=0A=
>}=0A=
>if (BIO_get_ktls_recv(SSL_get_rbio(s)) {=0A=
> /* Can use KTLS for receive. */=0A=
>}=0A=
=0A=
So, I've been making some progress. The first stab at the daemons that do t=
he=0A=
handshake are now on svn in base/projects/nfs-over-tls/usr.sbin/rpctlscd an=
d=0A=
rpctlssd.=0A=
=0A=
A couple of questions...=0A=
1 - I haven't found BIO_get_ktls_send() or BIO_get_ktls_recv(). Are they in=
some=0A=
different library?=0A=
2 - After a successful SSL_connect(), the receive queue for the socket has =
478bytes=0A=
of stuff in it. SSL_read() seems to know how to skip over it, but I ha=
ven't=0A=
figured out a good way to do this. (I currently just do a recv(..478,0=
) on the=0A=
socket.)=0A=
Any idea what to do with this? (Or will the receive side of the ktls f=
igure out=0A=
how to skip over it?)=0A=
=0A=
I'm currently testing with a kernel that doesn't have options KERN_TLS and=
=0A=
(so long as I get rid of the 478 bytes), it then just does unencrypted RPCs=
.=0A=
=0A=
So, I guess the big question is.... can I get access to your WIP code for K=
TLS=0A=
receive? (I have no idea if I can make progress on it, but I can't do a lot=
more=0A=
before I have that.)=0A=
=0A=
Oh, and for anyone out there...=0A=
What is the easiest freebie way to test signed certificates?=0A=
(I currently am using a self-signed certificate, but I need to test the "re=
al" version=0A=
at some point soon.)=0A=
=0A=
Thanks, rick=0A=
=0A=
=0A=
--=0A=
John Baldwin=0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YQBPR0101MB1427F6950084C3CA30713A75DD080>