Date: Thu, 30 Jan 2020 20:18:43 -0800 From: Benjamin Kaduk <kaduk@mit.edu> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: John Baldwin <jhb@freebsd.org>, "freebsd-current@FreeBSD.org" <freebsd-current@freebsd.org> Subject: Re: how to use the ktls Message-ID: <20200131041843.GC24@kduck.mit.edu> In-Reply-To: <YQBPR0101MB14277EAB1553C3049B60E763DD0A0@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM> References: <YQBPR0101MB142760894682CA3663CB53BDDD3F0@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM> <5be57c87-90fe-fcbe-ea37-bdb1bcff2da8@FreeBSD.org> <YQBPR0101MB1427F6950084C3CA30713A75DD080@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM> <d29b4343-b8e0-88e7-9076-d2a94eb45386@FreeBSD.org> <YQBPR0101MB14277EAB1553C3049B60E763DD0A0@YQBPR0101MB1427.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200131041843.GC24>