Date: Sat, 5 Sep 2020 02:27:55 +0000 From: Rick Macklem <rmacklem@uoguelph.ca> To: John-Mark Gurney <jmg@funkthat.com> Cc: "freebsd-current@freebsd.org" <freebsd-current@freebsd.org> Subject: Re: rfc: should extant TLS connections be closed when a CRL is updated? Message-ID: <YTBPR01MB3966214FB5F67A68F1350706DD2A0@YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM> In-Reply-To: <20200904223726.GK4213@funkthat.com> References: <YTBPR01MB39668EB1E7D4B42DFC5F50A6DD2D0@YTBPR01MB3966.CANPRD01.PROD.OUTLOOK.COM>, <20200904223726.GK4213@funkthat.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YTBPR01MB3966214FB5F67A68F1350706DD2A0>