Date: Mon, 13 Jan 2020 08:42:42 -0800 From: John Baldwin <jhb@FreeBSD.org> To: Benjamin Kaduk <kaduk@mit.edu>, Rick Macklem <rmacklem@uoguelph.ca> Cc: "freebsd-current@FreeBSD.org" <freebsd-current@freebsd.org> Subject: Re: how to use the ktls Message-ID: <c1039245-5574-3279-956d-26cf378c71e5@FreeBSD.org> In-Reply-To: <20200113042310.GF27483@kduck.mit.edu> References: <YQBPR0101MB142760894682CA3663CB53BDDD3F0@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM> <5be57c87-90fe-fcbe-ea37-bdb1bcff2da8@FreeBSD.org> <YQBPR0101MB14276B495EF90AD4CCE04F9ADD390@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM> <20200113042310.GF27483@kduck.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/12/20 8:23 PM, Benjamin Kaduk wrote: > On Thu, Jan 09, 2020 at 10:53:38PM +0000, Rick Macklem wrote: >> John Baldwin wrote: >>> On 1/7/20 3:02 PM, Rick Macklem wrote: >>>> Hi, >>>> >>>> Now that I've completed NFSv4.2 I'm on to the next project, which is making NFS >>>> work over TLS. >>>> Of course, I know absolutely nothing about TLS, which will make this an interesting >>>> exercise for me. >>>> I did find simple server code in the OpenSSL doc. which at least gives me a starting >>>> point for the initialization stuff. >>>> As I understand it, this initialization must be done in userspace? >>>> >>>> Then somehow, the ktls takes over and does the encryption of the >>>> data being sent on the socket via sosend_generic(). Does that sound right? >>>> >>>> So, how does the kernel know the stuff that the initialization phase (handshake) >>>> figures out, or is it magic I don't have to worry about? >>>> >>>> Don't waste much time replying to this. A few quick hints will keep me going for >>>> now. (From what I've seen sofar, this TLS stuff isn't simple. And I thought Kerberos >>>> was a pain.;-) >>>> >>>> Thanks in advance for any hints, rick >>> >>> Hmmm, this might be a fair bit of work indeed. >> If it was easy, it wouldn't be fun;-) FreeBSD13 is a ways off and if it doesn't make that, oh well.. >> >>> Right now KTLS only works for transmit (though I have some WIP for receive). >> Hopefully your WIP will make progress someday, or I might be able to work on it. >> >>> KTLS does assumes that the initial handshake and key negotiation is handled by >>> OpenSSL. OpenSSL uses custom setockopt() calls to tell the kernel which >>> session keys to use. >> Yea, I figured I'd need a daemon like the gssd for this. The krpc makes it a little >> more fun, since it handles TCP connections in the kernel. >> >>> I think what you would want to do is use something like OpenSSL_connect() in >>> userspace, and then check to see if KTLS "worked". >> Thanks (and for the code below). I found the simple server code in the OpenSSL doc, >> but the client code gets a web page and is quite involved. >> >>> If it did, you can tell >>> the kernel it can write to the socket directly, otherwise you will have to >>> bounce data back out to userspace to run it through SSL_write() and have >>> userspace do SSL_read() and then feed data into the kernel. >> I don't think bouncing the data up/down to/from userland would work well. >> I'd say "if it can't be done in the kernel, too bad". The above could be used for >> a NULL RPC to see it is working, for the client. > > So you're saying that we'd only support rpc-over-tls as an NFS client and > not as a server, at least until the WIP for ktls read appears? To be clear, I have KTLS RX working with TOE right now. I have a design in my head for KTLS RX that would use software and co-processor engines via OCF such as aesni(4) and ccr(4) that I hope to implement in the next few months, so KTLS RX isn't too far off. OpenSSL already supports KTLS RX on Linux and the FreeBSD patches I already have use the same API. (Each received TLS frame is read via recvmsg() with the TLS header fields in a cmsg.) -- John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?c1039245-5574-3279-956d-26cf378c71e5>