From owner-freebsd-current@freebsd.org Fri Jan 31 04:18:49 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 579032320A1 for ; Fri, 31 Jan 2020 04:18:49 +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 4883r82Yrbz44b7; Fri, 31 Jan 2020 04:18:47 +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 00V4IhgO009874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 30 Jan 2020 23:18:46 -0500 Date: Thu, 30 Jan 2020 20:18:43 -0800 From: Benjamin Kaduk To: Rick Macklem Cc: John Baldwin , "freebsd-current@FreeBSD.org" Subject: Re: how to use the ktls Message-ID: <20200131041843.GC24@kduck.mit.edu> References: <5be57c87-90fe-fcbe-ea37-bdb1bcff2da8@FreeBSD.org> 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: 4883r82Yrbz44b7 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.39 / 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.89)[ip: (-9.60), ipnet: 18.9.0.0/16(-4.79), 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: Fri, 31 Jan 2020 04:18:49 -0000 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