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>