11

I would like to better understand the implications of maintaining a long lived (hours, days) TLS connection with respect to certificate revocation. As I understand TLS, the client verifies the server's certificate during the handshake and then never again for the duration of the connection.

After establishing a long lived connection, if the server's certificate were to be revoked, I expect that a client which uses OCSP to check revocation would not discover that the server's certificate has been revoked until the next time it establishes a new connection to that server. I suppose the client could periodically check the server's certificate status in a background thread while the connection is open, but I am not familiar with any guidance that recommends checking revocation this way.

Generally, how do TLS clients with long lived connections mitigate the risk of certificate revocation? Do they periodically reestablish connections to force a new handshake?

jdgilday
  • 211
  • 1
  • 2
  • 1
    Note you can do a new TLS handshake, including cert checking, without a new connection; this is called renegotiation. It is usually recommended (though not always implemented) to do this if the amount of data exceeds good-practice limit for the data cipher (e.g. 'sweet32'); I haven't seen it recommended for cert validity but there's no reason not to use it for that also. OTOH many of the systems and networks I've used _couldn't_ reliably hold a single connection more than a day and sometimes much less; especially many firewalls love to kill any long-lasting connection. ... – dave_thompson_085 May 31 '18 at 02:29
  • ... And many (though not all) servers need to handle many clients, and don't like wasting resources on connections that are idle more than some limited period of time like a few minutes. – dave_thompson_085 May 31 '18 at 02:30
  • OK, so connections usually aren't long enough to warrant renegotiation for cert validation. A TLS connection from an application server to a database is an example of a connection that one expects to be sustained, but renegotiation may be advisable in this case due to the amount of data passed over this connection - right? Also, I suppose the application server could keep a pool of TLS connections to the database and recycle connections without interrupting service – jdgilday May 31 '18 at 12:30

1 Answers1

1

One place to look for more information about this could be VPNs that use SSL/TLS.

For example with OpenVPN you have to explicitly kill the client connection if it is active:

"...and have the new CRL take effect immediately for newly connecting clients. If the client whose certificate you are revoking is already connected, you can restart the server via a signal (SIGUSR1 or SIGHUP) and flush all clients, or you can telnet to the management interface and explicitly kill the specific client..."

https://openvpn.net/community-resources/revoking-certificates/

I'm not finding anything on clients checking server certs unfortunately.

montjoy
  • 111
  • 2