On 1/9/20 2:53 PM, Rick Macklem wrote:
John Baldwin wrote:
On 1/7/20 3:02 PM, Rick Macklem wrote:
Someone once told me they were working on a netgraph node that did TLS
encapsulation of a stream.
I can not remember who it was, but I do remember they were dubious
about being allowed to give it back. :-(
I only mention this as it MAY be an architectural avenue to investigate.
Julian
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
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
