Re: how to use the ktls

John Baldwin wrote:
[stuff snipped]
>Hmmm, this might be a fair bit of work indeed.
>
>Right now KTLS only works for transmit (though I have some WIP for receive).
>
>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.
>
>I think what you would want to do is use something like OpenSSL_connect() in
>userspace, and then check to see if KTLS "worked".  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.
>
>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. */
>}

So, I've been making some progress. The first stab at the daemons that do the
handshake are now on svn in base/projects/nfs-over-tls/usr.sbin/rpctlscd and
rpctlssd.

A couple of questions...
1 - I haven't found BIO_get_ktls_send() or BIO_get_ktls_recv(). Are they in some
      different library?
2 - After a successful SSL_connect(), the receive queue for the socket has 478bytes
     of stuff in it. SSL_read() seems to know how to skip over it, but I haven't
     figured out a good way to do this. (I currently just do a recv(..478,0) on the
     socket.)
     Any idea what to do with this? (Or will the receive side of the ktls figure out
     how to skip over it?)

I'm currently testing with a kernel that doesn't have options KERN_TLS and
(so long as I get rid of the 478 bytes), it then just does unencrypted RPCs.

So, I guess the big question is.... can I get access to your WIP code for KTLS
receive? (I have no idea if I can make progress on it, but I can't do a lot more
before I have that.)

Oh, and for anyone out there...
What is the easiest freebie way to test signed certificates?
(I currently am using a self-signed certificate, but I need to test the "real" version
 at some point soon.)

Thanks, rick


--
John Baldwin