On Mar 3, 2017, at 7:12 AM, Alan DeKok <aland@deployingradius.com> wrote:
On Mar 3, 2017, at 4:34 AM, Stefan Winter <stefan.winter@restena.lu> wrote:
One of the things we observed is that if an authentication uses TLS session resumption, the server does not re-check the OCSP state of the client cert that was used to login initially.
Yes. The OCSP checks are done in an OpenSSL callback when the certificate is first received. During session resumption there's no certificate used, so no OpenSSL callback.
It's fixed in >= v3.1.x. Although the client doesn't provide the certificate, the certificate is still available. Unfortunately the OpenSSL callback infrastructure doesn't allow re-checking the certificate chain, so something had to be hacked together to do that manually (see tls_validate_client_cert_chain).
Looking at the TLS-Client-Cert-* attributes which get restored from session cache, it looks like it could be easy to do that though - the serial number of the cert is saved; and the OCSP responder URL maybe isn't but could be. And with both pieces of information, another OCSP check can be run even on a resumed session.
Yes.
See above.
A related question: how is the cache lifetime determined? When config sets it to 24 hours, is that 24 hours after the initial, full, authentication, or is that lifetime refreshed with every re-auth, meaning the cache expires after 24 hours of non-use?
The cached session information will expire after 24 hours. When a session is resumed, the old information is deleted, and a new entry is created.
Yes.
If the latter, a revoked user could perpetually prolong his account lifetime even if OCSP wouldn't want to let him.
So long as you keep letting him in, yes.
Only in <= v3.0.x.
Also, something we didn't check but that just now comes to my mind: does the server check the expiry time of the cert on a resumed session?
Hmm... I'll have to check that. I'm not sure.
In >= v3.1.x yes, in < v3.1.x probably maybe not. -Arran