From owner-freebsd-current@freebsd.org Sat Sep 5 02:28: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 2B4873D73E5 for ; Sat, 5 Sep 2020 02:28:08 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660049.outbound.protection.outlook.com [40.107.66.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Bjz3q0PHwz4vrP for ; Sat, 5 Sep 2020 02:28:06 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EdB2fINUSvhkzvTlchatjnQdFUIXYUzcdREaKwZFncWv+Jhj9aWanPCWDX8EmqaUat+zFeZSl6RKDmoMxDhVARe9ayuAes0Zeef0Oh8H9zMNotAFld2VZXjVrYJMvF17AmIl3cJikOJMkIjDTw7xTLInWTeqQxOUiQbSYECFe0bks72WKhCQf2ZPEa/9ZvLhoM0cWnk1NuCFnH+KywoX7HEnhdDzYwNwBDLSWszKPuBn2dlQbyz96CqkE7iF1oUJyjbF+Kyjvcf3udp4grIwV2qngzNXla5cbElFFBJOHFp/1SL5h7MP9XoaWsFUUCNvLMnOqO3+gFhVvpQHFx27yw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ckNylttmp2l2p0GUfPghDYNjx/AYRR9YCRVz8gxuy/k=; b=P5uakTriCjoJu+uuDUobVVwNXftd0FMUL2uKFkvajTOwuW6c897fOQ2kfUdF6/bdC8CFyqCZ1BCPqPxi8Jl5GMOC9i++LUgTyV5EflmMhuCeGsrqv+1jR+fXd8nvXvVzcf13BYkt3lp5qzmgpl8+GsLqGkI6GIkxU5oyeIo9kZ8cS4Lmt0Cn+Hqz+0OG8771naKARE8rncm7D4vXmvqnRHvYwrfR7kkCm4jF29q9SFgw4neV2fyp//ZM4db7tnt6SxJ25SEZwfPHO0EHzR/IF+b/bU+NMA+PNwMetNRFy+9atbsPlYbM4/iupC/bzR2AK5N75ExS1nuaf2XLFYarxg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:24::27) by YTBPR01MB3967.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:b01:1e::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3348.15; Sat, 5 Sep 2020 02:28:05 +0000 Received: from YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20]) by YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM ([fe80::687f:d85a:a0a3:bd20%6]) with mapi id 15.20.3348.017; Sat, 5 Sep 2020 02:27:55 +0000 From: Rick Macklem To: John-Mark Gurney CC: "freebsd-current@freebsd.org" Subject: Re: rfc: should extant TLS connections be closed when a CRL is updated? Thread-Topic: rfc: should extant TLS connections be closed when a CRL is updated? Thread-Index: AQHWglkASBYleWH1wEypwb+mRG1+HalZEzsAgAA+IY0= Date: Sat, 5 Sep 2020 02:27:55 +0000 Message-ID: References: , <20200904223726.GK4213@funkthat.com> In-Reply-To: <20200904223726.GK4213@funkthat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4cf0bf11-f0e3-4450-d9da-08d851434c53 x-ms-traffictypediagnostic: YTBPR01MB3967: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 45ogwLWRq0z8J0nECqTzfpsbHsrdOSCYeZBArjJub9kNKtpZuV7udvbwCIR0gukW1Eevv0+5nFYBNXmVsnIv9r3SEht/+JqiAA9RNqNrH5Uv2g+oylaUJQs8Uavluo3qBoPLdVMuYCSluI8h28rsmE5tLDndC6pCuzd34IPmiwIU7ktOvoJfiigqBs4RoeE60ZpqDLh539l9xQviOZKmOZ1k9LuXvIHjPTL1erl4I/N0M/R1ycY2hLiag9lxMA3zezZEgB5HNpdfGTcj0P/iv+4QhfKChAduOFBTRhT8yohUinpj7RyTbz8prrlyONelD5xmcyBfhNOse/QikS16kw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(346002)(136003)(366004)(376002)(396003)(39860400002)(6506007)(9686003)(8676002)(66446008)(186003)(64756008)(91956017)(76116006)(66556008)(33656002)(52536014)(66946007)(15650500001)(66476007)(786003)(316002)(71200400001)(6916009)(55016002)(5660300002)(4326008)(7696005)(83380400001)(478600001)(2906002)(8936002)(86362001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 69xywnWy8XIB5Gn1fmZuHWX6kicIO8o2MhuvC7vJNptIE3pxBvxHWH+aYfQ+0VeVYbFys4ByGnNskjaI+3t8JjoZ3SiBwjy3oC2FGGqt/YxATh25eubt/4P7c6eQ0XEU/cMj09cRBnBJ7llJff2xOnkXB3/iKX1LZariMYXdHSOUlms754lxHTYCjAyeZQBtJnn3yvnUeoLhh0n/lvsu6nKWBv/o4FVisHJWXgUrOXZim5uiEdZWBV5f9qzWSmXrCCDoisEOrl9j93vYMEBGjAQB4pdmfqZnjkecOGDwe2ayR7BRSijyU6/U++FYFjPYRnHrWhLIJaWRJo2SfYCZ7Ta72m85b5Z+GYOFLTrCOoMSdWEgNlQqrz4YpIKQTdpca/gwZgKpvEB36Ef/Y2KLVaHZ8bUjl5uXO5frl/GCS9A//OvbBmROWZ1V3mGyLqypBBr1w871GSEAVAOJbfSgF6E5bZ41pAJV0fcnUBjJuEE1Uxox2HJEMFysan8Mb8WK6JzshXrX/daFHWsytCTbT/rWuClb5D/kewl7uiDMn+LTt1YThppzA4b9yzrF73x6n9SYf3KYqpfuZBI5B25ACStgqD1yzQo16YjzYFJUfk4TdsmZes5ejpfJe+Tww9EQE55758cDv7kh5a86p6m+Ha3/2PqFWwNAr4thVzzroIWIZ0EygLjAj1PBp6d7Tp3+noMqiBaqtSruYEqWfdawVg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 4cf0bf11-f0e3-4450-d9da-08d851434c53 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Sep 2020 02:27:55.7028 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: fmnUlPUf5L3x4/BijapiiOHKB+L5bubmAbiyFz1Bi0XkSqSZoTaKod1Qz0J64CfLirAHKtrtUFDiWTTS8NZI6Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTBPR01MB3967 X-Rspamd-Queue-Id: 4Bjz3q0PHwz4vrP X-Spamd-Bar: ----- X-Spamd-Result: default: False [-5.50 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.95)[-0.954]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; NEURAL_HAM_LONG(-1.02)[-1.017]; MIME_GOOD(-0.10)[text/plain]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[40.107.66.49:from]; NEURAL_HAM_SHORT(-1.53)[-1.534]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; RCVD_TLS_LAST(0.00)[]; MAILMAN_DEST(0.00)[freebsd-current]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.66.49:from] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 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: Sat, 05 Sep 2020 02:28:08 -0000 John-Mark Gurney wrote:=0A= >Rick Macklem wrote this message on Fri, Sep 04, 2020 at 01:20 +0000:=0A= >> The server side NFS over TLS daemon (rpc.tlsservd) can reload an updated= =0A= >> CRL (Certificate Revocation List) when a SIGHUP is posted to it.=0A= >> However, it does not SSL_shutdown()/close() extant TCP connections using= TLS.=0A= >> (Those would only be closed if the daemon is restarted.)=0A= >>=0A= >> I am now thinking that, maybe, an SSL_shutdown()/close() should be done = on=0A= >> all extant TCP connections using NFS over TLS when an updated CRL is loa= ded,=0A= >> since a connection might have used a revoked certificate for its handsha= ke.=0A= >>=0A= >> What do others think?=0A= >=0A= >IMO, this should scan the existing connections, and only shut them=0A= >down if they are using a revoked Cert. This is the correct way to=0A= >do things.=0A= Yes. I agree with you and Stefan that this is the way to go.=0A= (When I test with a single client, I sometimes forget that there might be= =0A= 1000s of connections on a production server.)=0A= =0A= >I do realize that this is likely not possible, and in reality, the=0A= >ssl library in use should do this automatically, but likely does not.=0A= >As the library likely does not, we should probably make this an=0A= >option to close all connections upon CRL reload, with it being well=0A= >documented.=0A= Well, I haven't looked yet, but I suspect that there are lower level OpenSS= L=0A= library functions that can be used to read each entry from the CRL.=0A= =0A= If I can do that, it is just comparing the Issuer and Serial# with the ones= =0A= associated with the connection (captured when the handshake is done).=0A= =0A= So long as the lower level ssl library functions are not internal ones,=0A= I am comfortable doing that. (It might make the code a little harder=0A= to maintain, but I suspect what is in OpenSSL3 will be around for a while,= =0A= API wise?)=0A= =0A= >Now that option should likely be set to default on, but documented=0A= >such that if you do regular/often CRL reloads, that a user may want=0A= >to turn that off if it's disruptive to their server.=0A= I think this is the fallback, if I can't easily read the entries out of the= CRL.=0A= =0A= Thanks for the good comments (Stefan too), rick=0A= =0A= --=0A= John-Mark Gurney Voice: +1 415 225 5579=0A= =0A= "All that I will do, has been done, All that I have, has not."=0A= =0A=