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_at_freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org" >Received on Mon Jan 27 2020 - 22:51:08 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:22 UTC