From nobody Sat Jun 24 13:09:07 2023 X-Original-To: freebsd-fs@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4QpDvz6c1rz4hJpd for ; Sat, 24 Jun 2023 13:09:19 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Received: from mail-oo1-xc33.google.com (mail-oo1-xc33.google.com [IPv6:2607:f8b0:4864:20::c33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QpDvz4pLFz3n4W; Sat, 24 Jun 2023 13:09:19 +0000 (UTC) (envelope-from rick.macklem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-oo1-xc33.google.com with SMTP id 006d021491bc7-562fc14c4f6so1126747eaf.1; Sat, 24 Jun 2023 06:09:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687612158; x=1690204158; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=f0n5dpaTOHY9Hx+St3K97ueyuRe5bsyU72KMwebkL9c=; b=Cdk7CUYsHsdCnSMWEd6j3BCbk0qThQYXSvPISedFiBy1YxkB2NjnRwuxlPQJf76xxT bBfO3RJKh0wW6MaKOMUPpXp9ESbDDVARZg0dktQcqTbFN3JUd+7sMymc7BVoUBcrTaBZ 8t6uafNDGoOY58s6mEhCq5M84oWLpQKsk+6Sp74caOuAoaTMO+lbKlhzEp0JOhyLdzCM NHYgJUfaconTZAyid5RxvFQKt7YelKKatAigD6adf7IDpO6cO88VIrTrEutExBaX/u1q OWwRCQiCMmlFbW8++vuqiLpslBuiRgkI9lVho9wICK9G1TsDb7B14fRY3mCgbrhffhd4 7zQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687612158; x=1690204158; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=f0n5dpaTOHY9Hx+St3K97ueyuRe5bsyU72KMwebkL9c=; b=eroHXiKt+hSjNAb+T+40MdqtN/pQibxxuUs6NYMlzJC8Iq2pblqanJFnVIOdQYglGZ 9c18Gl36jSo2INNI9KyLWFsTYYbeis0ntjprJCsaMMfkyiyTz6BsZjeXpYJNWvGlw2Xd kdZmp7g89X6mLL2o2IKKN6OWMGiv/e26FqVEpMZEqmTZay/kLFzF15Tp0YoH/AwGZ19C M3ELfsFv1ld/65Ps6Sf92paj8bCMilLpienPUE3BH/ai6BLueQKoOGOnVrYIvm0CriDN wF60X9gfQ9Bzv4lVMbJz/EkxmYIinYWbc/MRM8mYaXnnzv0EV9Miw+sND2ENjJgrF7pl I44g== X-Gm-Message-State: AC+VfDz1/pJmbsEy+z1iz8kZgzQJEHKcU3hFkXb5UrGFlV/B702f30ML 51tCij02QERBCUORi1tUexMZYZGIoj3Fsuulqs49lZ0= X-Google-Smtp-Source: ACHHUZ4OJOBfkIpSOAAQeJ3oSptWh54cVU0Os/rZ8JmewjVQerm70b5+U5sRHTRkx2IHtWpBQZpDkXoINQladaLzE50= X-Received: by 2002:a05:6808:138e:b0:3a0:662a:e0c1 with SMTP id c14-20020a056808138e00b003a0662ae0c1mr8486575oiw.31.1687612158102; Sat, 24 Jun 2023 06:09:18 -0700 (PDT) List-Id: Filesystems List-Archive: https://lists.freebsd.org/archives/freebsd-fs List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-fs@freebsd.org MIME-Version: 1.0 References: In-Reply-To: From: Rick Macklem Date: Sat, 24 Jun 2023 06:09:07 -0700 Message-ID: Subject: Re: Verifying NFS over TLS To: Peter Jeremy Cc: freebsd-fs@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4QpDvz4pLFz3n4W X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Sat, Jun 24, 2023 at 1:52=E2=80=AFAM Peter Jeremy w= rote: > > I've recently been configuring NFS over TLS[*] and one issue that came > up was how to verify that it's actually using using TLS. > * "mount -v" doesn't provide any indication of mount options. > * Various kern.ipc.tls sysctls can confirm that *something* is using > ktls but not that a specific NFS mount is using TLS. > * tcpdump's inability to decode traffic on port 2049 is a fairly good > indication but isn't as direct as I'd like. > > What is the recommended way to distinguish TLS from non-TLS mounts? "nfsstat -m" on the client shows what mount options are actually being used= . (If "tls" is in the list, it should be happening.) You can capture packets via tcpdump and then look at them in wireshark and you should be able to see that TLS application data records are what is going on the wire. If you attempt an NFS mount with the "tls" option against a server not configured to do NFS-over-TLS (the original authors use RPC-with-TLS, which is more accurate but, to me, less informative), the mount should fail= . rick > > [*] Thanks very much rmacklem@ for your work. > -- > Peter Jeremy