Re: how to use the ktls

On Tue, Jan 28, 2020 at 11:01:31PM +0000, Rick Macklem wrote:
> John Baldwin wrote:
> [stuff snipped]
> >I don't know yet. :-/  With the TOE-based TLS I had been testing with, this doesn't
> >happen because the NIC blocks the data until it gets the key and then it's always
> >available via KTLS.  With software-based KTLS for RX (which I'm going to start
> >working on soon), this won't be the case and you will potentially have some data
> >already ready by OpenSSL that needs to be drained from OpenSSL before you can
> >depend on KTLS.  It's probably only the first few messsages, but I will need to figure
> >out a way that you can tell how much pending data in userland you need to read via
> >SSL_read() and then pass back into the kernel before relying on KTLS (it would just
> >be a single chunk of data after SSL_connect you would have to do this for).
> I think SSL_read() ends up calling ssl3_read_bytes(..APPLICATION..) and then it throws
> away non-application data records. (Not sure, ssl3_read_bytes() gets pretty convoluted at
> a glance.;-)

Yes, SSL_read() interprets the TLS record type and only passes application
data records through to the application.  It doesn't exactly "throw away"
the other records, though -- they still get processed, just internally to
libssl :)
I expect based on heuristics that the 485 bytes are a NewSessionTicket
message, but that actual length is very much not a protocol constant and is
an implementation detail of the TLS server.  (That said, an openssl server
is going to be producing the same length every time, for a given version of
openssl, unless you configure it otherwise.)

-Ben