Date: Mon, 3 Feb 2020 22:49:38 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: Benjamin Kaduk <kaduk@mit.edu> Cc: John Baldwin <jhb@FreeBSD.org>, "freebsd-current@FreeBSD.org" <freebsd-current@FreeBSD.org> Subject: Re: how to use the ktls Message-ID: <YTBPR01MB337462ED70ABB1851C1B8663DD000@YTBPR01MB3374.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <20200131041843.GC24@kduck.mit.edu> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Benjamin Kaduk wrote:=0A= >On Tue, Jan 28, 2020 at 11:01:31PM +0000, Rick Macklem wrote:=0A= >> John Baldwin wrote:=0A= >> [stuff snipped]=0A= >> >I don't know yet. :-/ With the TOE-based TLS I had been testing with, = this doesn't=0A= >> >happen because the NIC blocks the data until it gets the key and then i= t's always=0A= >> >available via KTLS. With software-based KTLS for RX (which I'm going t= o start=0A= >> >working on soon), this won't be the case and you will potentially have = some data=0A= >> >already ready by OpenSSL that needs to be drained from OpenSSL before y= ou can=0A= >> >depend on KTLS. It's probably only the first few messsages, but I will= need to figure=0A= >> >out a way that you can tell how much pending data in userland you need = to read via=0A= >> >SSL_read() and then pass back into the kernel before relying on KTLS (i= t would just=0A= >> >be a single chunk of data after SSL_connect you would have to do this f= or).=0A= >> I think SSL_read() ends up calling ssl3_read_bytes(..APPLICATION..) and = then it throws=0A= >> away non-application data records. (Not sure, ssl3_read_bytes() gets pre= tty convoluted at=0A= >> a glance.;-)=0A= >=0A= >Yes, SSL_read() interprets the TLS record type and only passes application= =0A= >data records through to the application. It doesn't exactly "throw away"= =0A= >the other records, though -- they still get processed, just internally to= =0A= >libssl :)=0A= >I expect based on heuristics that the 485 bytes are a NewSessionTicket=0A= >message, but that actual length is very much not a protocol constant and i= s=0A= >an implementation detail of the TLS server. (That said, an openssl server= =0A= >is going to be producing the same length every time, for a given version o= f=0A= >openssl, unless you configure it otherwise.)=0A= Well, I looked at the data and it appears to be two application data record= s,=0A= both of length 234. (These are in the receive queue before the other end do= es=0A= an SSL_write() and the only data returned by SSL_read() is what a subsequen= t=0A= SSL_write() has written.)=0A= =0A= My hunch is that, once they are unencrypted, they are just padding.=0A= Anyhow, since they are "application data" the receive side of KERN_TLS=0A= should be able to handle them.=0A= --> I don't think I need to do anything after the SSL_connect() in userland= =0A= to deal with these.=0A= =0A= Thanks for your help, rick=0A= =0A= -Ben=0A=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTBPR01MB337462ED70ABB1851C1B8663DD000>