From owner-freebsd-current@freebsd.org Mon Jan 27 23:51:08 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 8C212232B23 for ; Mon, 27 Jan 2020 23:51:08 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 48662h0nygz4MtJ; Mon, 27 Jan 2020 23:51:07 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (c-73-225-95-104.hsd1.wa.comcast.net [73.225.95.104]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id 00RNox8q051017 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 27 Jan 2020 15:51:00 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: how to use the ktls To: Rick Macklem , John Baldwin , "freebsd-current@FreeBSD.org" References: <5be57c87-90fe-fcbe-ea37-bdb1bcff2da8@FreeBSD.org> From: Julian Elischer Message-ID: Date: Mon, 27 Jan 2020 15:50:54 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Rspamd-Queue-Id: 48662h0nygz4MtJ X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.68 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.78)[-0.782,0]; NEURAL_HAM_LONG(-0.90)[-0.899,0]; ASN(0.00)[asn:36236, ipnet:204.109.60.0/22, country:US] 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, 27 Jan 2020 23:51:08 -0000 On 1/9/20 2:53 PM, Rick Macklem wrote: > John Baldwin wrote: >> On 1/7/20 3:02 PM, Rick Macklem wrote: Someone once told me they were working on a netgraph node that did TLS encapsulation of a stream. I can not remember who it was, but I do remember they were dubious about being allowed to give it back.  :-( I only mention this as it MAY be an architectural avenue to investigate. Julian >>> 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. > >> The pseudo-code might look something like: >> >> SSL *s; >> >> s = SSL_new(...); >> >> /* fd is the existing TCP socket */ >> SSL_set_fd(s, fd); >> OpenSSL_connect(s); >> if (BIO_get_ktls_send(SSL_get_wbio(s)) { >> /* Can use KTLS for transmit. */ >> } >> if (BIO_get_ktls_recv(SSL_get_rbio(s)) { >> /* Can use KTLS for receive. */ >> } > Thanks John, rick > > > -- > John Baldwin > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >