Re: how to use the ktls

On Mon, Feb 03, 2020 at 10:49:38PM +0000, Rick Macklem wrote:
> Benjamin Kaduk wrote:
> >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.)
> Well, I looked at the data and it appears to be two application data records,
> both of length 234. (These are in the receive queue before the other end does
> an SSL_write() and the only data returned by SSL_read() is what a subsequent
> SSL_write() has written.)
> 
> My hunch is that, once they are unencrypted, they are just padding.
> Anyhow, since they are "application data" the receive side of KERN_TLS
> should be able to handle them.
> --> I don't think I need to do anything after the SSL_connect() in userland
>       to deal with these.

All wire-visible TLS 1.3 records after the initial handshake will appear
with the content type of "application data"; there's an inner content type
to indicate what is actually being conveyed:
https://tools.ietf.org/html/rfc8446#section-5.2 .  Two same-length records
would match up with openssl sending two session tickets by default on a new
connection.

-Ben