Date: Thu, 9 Jan 2020 22:53:38 +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: <YQBPR0101MB14276B495EF90AD4CCE04F9ADD390@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=
>On 1/7/20 3:02 PM, Rick Macklem wrote:=0A=
>> Hi,=0A=
>>=0A=
>> Now that I've completed NFSv4.2 I'm on to the next project, which is mak=
ing NFS=0A=
>> work over TLS.=0A=
>> Of course, I know absolutely nothing about TLS, which will make this an =
interesting=0A=
>> exercise for me.=0A=
>> I did find simple server code in the OpenSSL doc. which at least gives m=
e a starting=0A=
>> point for the initialization stuff.=0A=
>> As I understand it, this initialization must be done in userspace?=0A=
>>=0A=
>> Then somehow, the ktls takes over and does the encryption of the=0A=
>> data being sent on the socket via sosend_generic(). Does that sound righ=
t?=0A=
>>=0A=
>> So, how does the kernel know the stuff that the initialization phase (ha=
ndshake)=0A=
>> figures out, or is it magic I don't have to worry about?=0A=
>>=0A=
>> Don't waste much time replying to this. A few quick hints will keep me g=
oing for=0A=
>> now. (From what I've seen sofar, this TLS stuff isn't simple. And I thou=
ght Kerberos=0A=
>> was a pain.;-)=0A=
>>=0A=
>> Thanks in advance for any hints, rick=0A=
>=0A=
>Hmmm, this might be a fair bit of work indeed.=0A=
If it was easy, it wouldn't be fun;-) FreeBSD13 is a ways off and if it do=
esn't make that, oh well..=0A=
=0A=
>Right now KTLS only works for transmit (though I have some WIP for receive=
).=0A=
Hopefully your WIP will make progress someday, or I might be able to work o=
n it.=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=
Yea, I figured I'd need a daemon like the gssd for this. The krpc makes it =
a little=0A=
more fun, since it handles TCP connections in the kernel.=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".=0A=
Thanks (and for the code below). I found the simple server code in the Open=
SSL doc,=0A=
but the client code gets a web page and is quite involved.=0A=
=0A=
>If it did, you can tell=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=
I don't think bouncing the data up/down to/from userland would work well.=
=0A=
I'd say "if it can't be done in the kernel, too bad". The above could be us=
ed for=0A=
a NULL RPC to see it is working, for the client.=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=
Thanks John, 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?YQBPR0101MB14276B495EF90AD4CCE04F9ADD390>