rfc: should extant TLS connections be closed when a CRL is updated?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

rfc: should extant TLS connections be closed when a CRL is updated?

Rick Macklem
Hi,

The server side NFS over TLS daemon (rpc.tlsservd) can reload an updated
CRL (Certificate Revocation List) when a SIGHUP is posted to it.
However, it does not SSL_shutdown()/close() extant TCP connections using TLS.
(Those would only be closed if the daemon is restarted.)

I am now thinking that, maybe, an SSL_shutdown()/close() should be done on
all extant TCP connections using NFS over TLS when an updated CRL is loaded,
since a connection might have used a revoked certificate for its handshake.

What do others think?

Thanks, rick
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: rfc: should extant TLS connections be closed when a CRL is updated?

John-Mark Gurney-2
Rick Macklem wrote this message on Fri, Sep 04, 2020 at 01:20 +0000:

> The server side NFS over TLS daemon (rpc.tlsservd) can reload an updated
> CRL (Certificate Revocation List) when a SIGHUP is posted to it.
> However, it does not SSL_shutdown()/close() extant TCP connections using TLS.
> (Those would only be closed if the daemon is restarted.)
>
> I am now thinking that, maybe, an SSL_shutdown()/close() should be done on
> all extant TCP connections using NFS over TLS when an updated CRL is loaded,
> since a connection might have used a revoked certificate for its handshake.
>
> What do others think?

IMO, this should scan the existing connections, and only shut them
down if they are using a revoked Cert.  This is the correct way to
do things.

I do realize that this is likely not possible, and in reality, the
ssl library in use should do this automatically, but likely does not.
As the library likely does not, we should probably make this an
option to close all connections upon CRL reload, with it being well
documented.

Now that option should likely be set to default on, but documented
such that if you do regular/often CRL reloads, that a user may want
to turn that off if it's disruptive to their server.

--
  John-Mark Gurney Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: rfc: should extant TLS connections be closed when a CRL is updated?

Rick Macklem
John-Mark Gurney wrote:

>Rick Macklem wrote this message on Fri, Sep 04, 2020 at 01:20 +0000:
>> The server side NFS over TLS daemon (rpc.tlsservd) can reload an updated
>> CRL (Certificate Revocation List) when a SIGHUP is posted to it.
>> However, it does not SSL_shutdown()/close() extant TCP connections using TLS.
>> (Those would only be closed if the daemon is restarted.)
>>
>> I am now thinking that, maybe, an SSL_shutdown()/close() should be done on
>> all extant TCP connections using NFS over TLS when an updated CRL is loaded,
>> since a connection might have used a revoked certificate for its handshake.
>>
>> What do others think?
>
>IMO, this should scan the existing connections, and only shut them
>down if they are using a revoked Cert.  This is the correct way to
>do things.
Yes. I agree with you and Stefan that this is the way to go.
(When I test with a single client, I sometimes forget that there might be
 1000s of connections on a production server.)

>I do realize that this is likely not possible, and in reality, the
>ssl library in use should do this automatically, but likely does not.
>As the library likely does not, we should probably make this an
>option to close all connections upon CRL reload, with it being well
>documented.
Well, I haven't looked yet, but I suspect that there are lower level OpenSSL
library functions that can be used to read each entry from the CRL.

If I can do that, it is just comparing the Issuer and Serial# with the ones
associated with the connection (captured when the handshake is done).

So long as the lower level ssl library functions are not internal ones,
I am comfortable doing that. (It might make the code a little harder
to maintain, but I suspect what is in OpenSSL3 will be around for a while,
API wise?)

>Now that option should likely be set to default on, but documented
>such that if you do regular/often CRL reloads, that a user may want
>to turn that off if it's disruptive to their server.
I think this is the fallback, if I can't easily read the entries out of the CRL.

Thanks for the good comments (Stefan too), rick

--
  John-Mark Gurney                              Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: rfc: should extant TLS connections be closed when a CRL is updated?

Rick Macklem
In reply to this post by John-Mark Gurney-2
John-Mark Gurney wrote:

>Rick Macklem wrote this message on Fri, Sep 04, 2020 at 01:20 +0000:
>> The server side NFS over TLS daemon (rpc.tlsservd) can reload an updated
>> CRL (Certificate Revocation List) when a SIGHUP is posted to it.
>> However, it does not SSL_shutdown()/close() extant TCP connections using TLS.
>> (Those would only be closed if the daemon is restarted.)
>>
>> I am now thinking that, maybe, an SSL_shutdown()/close() should be done on
>> all extant TCP connections using NFS over TLS when an updated CRL is loaded,
>> since a connection might have used a revoked certificate for its handshake.
>>
>> What do others think?
>
>IMO, this should scan the existing connections, and only shut them
>down if they are using a revoked Cert.  This is the correct way to
>do things.
>
>I do realize that this is likely not possible, and in reality, the
>ssl library in use should do this automatically, but likely does not.
Well, not exactly "automatically, but X509_CRL_get0_by_ccert() checks
to see if a certificate is revoked, so all the code needed to do was
read the CRL file and then loop through the certificates, checking
each one.

>As the library likely does not, we should probably make this an
>option to close all connections upon CRL reload, with it being well
>documented.
>
>Now that option should likely be set to default on, but documented
>such that if you do regular/often CRL reloads, that a user may want
>to turn that off if it's disruptive to their server.
Not necessary, since doing just the revoked ones seems to work.

If you are curious, you can look at the recent commits or code
under head/projects/nfs-over-tls.

If anyone is interested in testing it, you can look at:
https://people.freebsd.org/~rmacklem/nfs-over-tls-setup.txt

Thanks for the useful suggestion, rick

--
  John-Mark Gurney                              Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."

_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"