From owner-freebsd-current@freebsd.org Mon Feb 3 22:59:27 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9632B231F1A for ; Mon, 3 Feb 2020 22:59:27 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48BNYp4YFWz4GSN; Mon, 3 Feb 2020 22:59:26 +0000 (UTC) (envelope-from kaduk@mit.edu) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 013MxLJ3018919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 3 Feb 2020 17:59:24 -0500 Date: Mon, 3 Feb 2020 14:59:21 -0800 From: Benjamin Kaduk To: Rick Macklem Cc: John Baldwin , "freebsd-current@FreeBSD.org" Subject: Re: how to use the ktls Message-ID: <20200203225921.GA53329@kduck.mit.edu> References: <5be57c87-90fe-fcbe-ea37-bdb1bcff2da8@FreeBSD.org> <20200131041843.GC24@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.12.1 (2019-06-15) X-Rspamd-Queue-Id: 48BNYp4YFWz4GSN X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of kaduk@mit.edu designates 18.9.28.11 as permitted sender) smtp.mailfrom=kaduk@mit.edu X-Spamd-Result: default: False [-5.40 / 15.00]; ARC_NA(0.00)[]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:18.9.28.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[mit.edu]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[11.28.9.18.list.dnswl.org : 127.0.11.2]; IP_SCORE(-2.90)[ip: (-9.61), ipnet: 18.9.0.0/16(-4.80), asn: 3(-0.03), country: US(-0.05)]; RWL_MAILSPIKE_POSSIBLE(0.00)[11.28.9.18.rep.mailspike.net : 127.0.0.17]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:3, ipnet:18.9.0.0/16, country:US]; RCVD_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Feb 2020 22:59:27 -0000 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