From owner-freebsd-current@freebsd.org Mon Jan 13 04:23:17 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 3FB641F6329 for ; Mon, 13 Jan 2020 04:23:17 +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 47x0nc31Q9z3ynZ; Mon, 13 Jan 2020 04:23:16 +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 00D4NBS6017630 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 12 Jan 2020 23:23:13 -0500 Date: Sun, 12 Jan 2020 20:23:10 -0800 From: Benjamin Kaduk To: Rick Macklem Cc: John Baldwin , "freebsd-current@FreeBSD.org" Subject: Re: how to use the ktls Message-ID: <20200113042310.GF27483@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: 47x0nc31Q9z3ynZ 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.38 / 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.88)[ip: (-9.61), ipnet: 18.9.0.0/16(-4.74), asn: 3(-0.01), country: US(-0.05)]; FROM_EQ_ENVFROM(0.00)[]; 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] 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, 13 Jan 2020 04:23:17 -0000 On Thu, Jan 09, 2020 at 10:53:38PM +0000, Rick Macklem wrote: > John Baldwin wrote: > >On 1/7/20 3:02 PM, Rick Macklem wrote: > >> Hi, > >> > >> Now that I've completed NFSv4.2 I'm on to the next project, which is making NFS > >> work over TLS. > >> Of course, I know absolutely nothing about TLS, which will make this an interesting > >> exercise for me. > >> I did find simple server code in the OpenSSL doc. which at least gives me a starting > >> point for the initialization stuff. > >> As I understand it, this initialization must be done in userspace? > >> > >> Then somehow, the ktls takes over and does the encryption of the > >> data being sent on the socket via sosend_generic(). Does that sound right? > >> > >> So, how does the kernel know the stuff that the initialization phase (handshake) > >> figures out, or is it magic I don't have to worry about? > >> > >> Don't waste much time replying to this. A few quick hints will keep me going for > >> now. (From what I've seen sofar, this TLS stuff isn't simple. And I thought Kerberos > >> was a pain.;-) > >> > >> Thanks in advance for any hints, rick > > > >Hmmm, this might be a fair bit of work indeed. > If it was easy, it wouldn't be fun;-) FreeBSD13 is a ways off and if it doesn't make that, oh well.. > > >Right now KTLS only works for transmit (though I have some WIP for receive). > Hopefully your WIP will make progress someday, or I might be able to work on it. > > >KTLS does assumes that the initial handshake and key negotiation is handled by > >OpenSSL. OpenSSL uses custom setockopt() calls to tell the kernel which > >session keys to use. > Yea, I figured I'd need a daemon like the gssd for this. The krpc makes it a little > more fun, since it handles TCP connections in the kernel. > > >I think what you would want to do is use something like OpenSSL_connect() in > >userspace, and then check to see if KTLS "worked". > Thanks (and for the code below). I found the simple server code in the OpenSSL doc, > but the client code gets a web page and is quite involved. > > >If it did, you can tell > >the kernel it can write to the socket directly, otherwise you will have to > >bounce data back out to userspace to run it through SSL_write() and have > >userspace do SSL_read() and then feed data into the kernel. > I don't think bouncing the data up/down to/from userland would work well. > I'd say "if it can't be done in the kernel, too bad". The above could be used for > a NULL RPC to see it is working, for the client. So you're saying that we'd only support rpc-over-tls as an NFS client and not as a server, at least until the WIP for ktls read appears? -Ben