From owner-freebsd-current@freebsd.org Fri Mar 20 01:44:45 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 B5527276ED8 for ; Fri, 20 Mar 2020 01:44:45 +0000 (UTC) (envelope-from rcarter@pinyon.org) Received: from h2.pinyon.org (h2.pinyon.org [65.101.20.170]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48k65l6kqmz4Q7D for ; Fri, 20 Mar 2020 01:44:43 +0000 (UTC) (envelope-from rcarter@pinyon.org) Received: by h2.pinyon.org (Postfix, from userid 58) id 12C3119C2; Thu, 19 Mar 2020 18:44:40 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pinyon.org; s=DKIM; t=1584668680; bh=8cwhEnEEMegmxEQs9YAKUzL0iB2bLeuZhF+T4d28050=; h=Subject:To:References:From:Date:In-Reply-To; b=lo8bIgVs/RtSHGYRgczwaOdBsrBDTSAfLmRIUfOAJM3yfuyUW3oV2fd1eAk3VlFsV 9tfmsPwYkZeWL5fAF2Dw6pO0VoXBE5ZsltVU0nJ1NVuZuPE99twSW148xZdE+dwlW7 aTMiakKLmUyDAgp5Hpj8fs2hoL8USIAKi3pca2O8= X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on h2.n1.pinyon.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU shortcircuit=no autolearn=ham autolearn_force=no version=3.4.4 Received: from [10.0.10.15] (unknown [10.0.10.15]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by h2.pinyon.org (Postfix) with ESMTPSA id 06DFC19B3 for ; Thu, 19 Mar 2020 18:44:38 -0700 (MST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=pinyon.org; s=DKIM; t=1584668678; bh=8cwhEnEEMegmxEQs9YAKUzL0iB2bLeuZhF+T4d28050=; h=Subject:To:References:From:Date:In-Reply-To; b=W2+Os81o5GkqJiyWxqF3eCMXKxIckOEP6CzB+E/Dh7IMX9T+/KmUlQ8uKyPIvKFw9 SRspxlhEdh72XuoNZRRWeO65Wd7tUSHVxTTPMVIGkRISVXEy8VJsafg0LvxsAscciN 6Iy+wFoK8GcyLvMjaXg7h8K9N7TmjRkhBZ9bg+wY= Subject: Re: TLS certificates for NFS-over-TLS floating client To: freebsd-current@freebsd.org References: <20200319191605.GJ4213@funkthat.com> From: "Russell L. Carter" Message-ID: Date: Thu, 19 Mar 2020 18:44:37 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 48k65l6kqmz4Q7D X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=pinyon.org header.s=DKIM header.b=lo8bIgVs; dkim=pass header.d=pinyon.org header.s=DKIM header.b=W2+Os81o; dmarc=none; spf=pass (mx1.freebsd.org: domain of rcarter@pinyon.org designates 65.101.20.170 as permitted sender) smtp.mailfrom=rcarter@pinyon.org X-Spamd-Result: default: False [-5.12 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[pinyon.org:s=DKIM]; NEURAL_HAM_MEDIUM(-0.93)[-0.934,0]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.997,0]; DMARC_NA(0.00)[pinyon.org]; DKIM_TRACE(0.00)[pinyon.org:+]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; IP_SCORE(-2.69)[ip: (-9.27), ipnet: 65.101.0.0/18(-4.00), asn: 209(-0.10), country: US(-0.05)]; ASN(0.00)[asn:209, ipnet:65.101.0.0/18, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; 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: Fri, 20 Mar 2020 01:44:45 -0000 So ok, it's good to code to RFCs. OTOH, state actors are a thing now. Alice & Bob's protocols need to be perfect. State actors watch for mistakes. Here I commit heresy, by A) top posting, and B) by just saying, why not make it easy, first, to tunnel NFSv4 sessions through e.g. net/wireguard or sysutils/spiped? NFS is point to point. Security infrastructure that actually works understands the shared secret model. Not going to argue further. I'm a grateful letsencrypt consumer. Rick is a hero for his NFS work. I use his code every day. Best, Russell On 2020-03-19 16:41, Rick Macklem wrote: > John-Mark Gurney wrote: >> Rick Macklem wrote this message on Wed, Mar 04, 2020 at 03:15 >> +0000: >>> I am slowly trying to understand TLS certificates and am trying >>> to figure >>> out how to do the following: -> For an /etc/exports file with... >>> /home -tls -network 192.168.1.0 -mask 255.255.255.0 /home >>> -tlscert >> >> Are you looking at implementing draft-cel-nfsv4-rpc-tls? > Yes. The 2 week out of date (I can only do commits once in a while these days) can > be found in FreeBSD's subversion under base/projects/nfs-over-tls. > >>> This syntax isn't implemented yet, but the thinking is that >>> clients on the >>> 192.168.1 subnet would use TLS, but would not require a >>> certificate. For access from anywhere else, the client(s) would >>> be required to have a certificate. >>> >>> A typical client mounting from outside of the subnet might be my >>> laptop, which is using wifi and has no fixed IP/DNS name. --> How >>> do you create a certificate that the laptop can use, which the NFS >>> server can trust enough to allow the mount? My thinking is that a >>> "secret" value can be put in the certificate that the NFS >>> server can check for. The simplest way would be a fairly long >>> list of random characters in the organizationName and/or >>> organizationUnitName field(s) of the subject name. >>> Alternately, it could be a newly defined extension for X509v3, I >>> think? >>> >>> Now, I'm not sure, but I don't think this certificate can be >>> created via a trust authority such that it would "verify". >>> However, the server can look for the "secret" in the certificate >>> and allow the mount based on that. >>> >>> Does this sound reasonable? >> >> Without a problem statement or what you're trying to accomplish, >> it's hard to say if it is. > The problem I was/am trying to solve was a way for NFS clients > without a fixed IP/DNS name could have a certificate to allow access > to the NFS server. > As suggested by others, having a site local CA created by the NFS admin. seemed > to be the best solution. The server can verify that the certificate was issued by > the local CA. Unfortunately, if the client is compromised and the certificate is copied > to another client, that client would gain access. --> I've thought of > having the client keep the certificate encrypted in a file and > require the "user" of the client type in a passphrase to unencrypt the certificate > so that it can be used by the daemon in the client that handles the client side > of the TLS handshake, but I have not implemented this. --> This would > at least subvert the simple case of the certificate file being copied > to a different client and being used to mount the NFS server, but if the > client is compromised, then the passphrase could be captured and... > >>> Also, even if the NFS client/server have fixed IP addresses with well known >>> DNS names, it isn't obvious to me how signed certificates can be acquired >>> for them? (Lets Encrypt expects the Acme protocol to work and >>> that seems to be web site/http specific?) >> >> There is DNS challenges that can be used. I use them to obtain >> certs for SMTP and SIP servers... using nsupdate, this is >> relatively easy to automate pushing the challenges to a DNS server, >> and I now use DNS challenges for everything, including https. > Since my internet connection is a single dynamically assigned IP > from the phone > company, I doubt this would work for me (which I why I say I don't know how > to do this). I suspect there are ways and it would be nice if you could document > this, so I can put it in a howto document. - An actual example using > the nsupdate command would be nice. Thanks, rick > >> Thanks for any help with this, rick > > Let me know if you'd like to hop on a call about this. > > -- John-Mark Gurney Voice: +1 415 225 > 5579 > > "All that I will do, has been done, All that I have, has not." > _______________________________________________ > 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" >