Re: how to use the ktls

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.

Thanks for your help, rick

-Ben