Re: how to use the ktls

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.

>The pseudo-code might look something like:
>
>SSL *s;
>
>s = SSL_new(...);
>
>/* fd is the existing TCP socket */
>SSL_set_fd(s, fd);
>OpenSSL_connect(s);
>if (BIO_get_ktls_send(SSL_get_wbio(s)) {
>  /* Can use KTLS for transmit. */
>}
>if (BIO_get_ktls_recv(SSL_get_rbio(s)) {
>   /* Can use KTLS for receive. */
>}

Thanks John, rick


--
John Baldwin