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 _______________________________________________ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
