Re: Can In-Kernel TLS (kTLS) work with any OpenSSL Application?

On 1/20/21 12:21 PM, Neel Chauhan wrote:
> Hi freebsd-current_at_,
> 
> I know that In-Kernel TLS was merged into the FreeBSD HEAD tree a while
> back.
> 
> With 13.0-RELEASE around the corner, I'm thinking about upgrading my
> home server, well if I can accelerate any SSL application.
> 
> I'm asking because I have a home server on a symmetrical Gigabit
> connection (Google Fiber/Webpass), and that server runs a Tor relay. If
> you're interested in how Tor works, the EFF has a writeup:
> https://www.eff.org/pages/what-tor-relay
> 
> But the main point for you all is: more-or-less Tor relays deal with
> 1000s TLS connections going into and out of the server.
> 
> Would In-Kernel TLS help with an application like Tor (or even load
> balancers/TLS termination), or is it more for things like web servers
> sending static files via sendfile() (e.g. CDN used by Netflix).

It depends.  Applications with allow OpenSSL to use a socket directly
(e.g. via SSL_set_fd() or via SSL_connect() or the like) will work with
kernel TLS transparently.  This includes things like apache, nginx,
fetch, wget, curl, etc.  However, some applications use OpenSSL purely
as a data transformation library and manage the socket I/O separately
(e.g. OpenVPN).  KTLS will not work with these applications since
OpenSSL doesn't "know" about the socket in question.

> My server could also work with Intel's QuickAssist (since it has an
> Intel Xeon "Scalable" CPU). Would QuickAssist SSL be more helpful here?

You can use this with ktls_ocf.ko and the qat(4) drivers.

I am working, btw, on merging KTLS into base OpenSSL and hope to have
it present in 13.0.

As you noted, applications would need to be changed to use SSL_sendfile()
to get the best performance on TX.  We don't really have an analog on
the receive side in our syscall API.  One might be able to do some
creative things with aio_read(4) perhaps, but I haven't implemented that.

Also, currently RX offload always returns individual records with the
full TLS header via recvmsg().  Linux's RX offload only includes the
message for non-application-data messages so that one could in theory
do bulk read(2) calls larger than a single TLS record.  OpenSSL itself
though always reads a single TLS record at a time, so if I were to change
this (e.g. with a new socket option to toggle headers for application
data), this would only be relevant to software that "knew" it was using
KTLS and would use direct read/write after letting OpenSSL (or a similar
library) handle the handshake.

-- 
John Baldwin