Date: Mon, 3 Feb 2020 14:59:21 -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: <20200203225921.GA53329@kduck.mit.edu> In-Reply-To: <YTBPR01MB337462ED70ABB1851C1B8663DD000@YTBPR01MB3374.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> <20200131041843.GC24@kduck.mit.edu> <YTBPR01MB337462ED70ABB1851C1B8663DD000@YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200203225921.GA53329>