Hi,
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.
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.
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.
So, as long as the user keeps re-authing in intervals < cache duration, he will have *perpetual* access? No CRL, OCSP or cert expiry would have an effect on the TLS session resumption? I would consider that a bug really. TLS 1.2 has a Security Considerations text on session resumption (RFC5246 section F.1.4): "Sessions cannot be resumed unless both the client and server agree. If either party suspects that the session may have been compromised, or that certificates may have expired or been revoked, it should force a full handshake. An upper limit of 24 hours is suggested for session ID lifetimes, [...]" The text leaves *slight* amounts of room for interpretation, but I for one read those 24 hours as an *absolute* time limit and not a sliding window since last use. (The RFCs reason for that time is the rather abstract risk of a third party obtaining a master_secret in the meanwhile; the risk of perpetual authentication is a much more concrete one IMHO). Also, granted that if a software never checks for OCSP states / expiry then it will never have the above "suspicion" that the certificate may have been revoked or expired, and will keep letting the user in. However, I somehow think that security-relevant software should have higher amibitions and take a more active role in developing such suspicions about stale state over time. At the very least, the cache could continue to work in non-verify mode until the TTL of the *original* cache entry expires. As soon as that time expires, maybe it's okay to still resume the session as always, but do a one-off OCSP + expiration check (and then keep going until the next original TTL period is over again). That way, the revocation and expiry states would get checked at least every 24h (default config value). Alternatively, a second config param absolute_max_lifetime could control when to kill the cache even if it's kept updated. For me, I tend to think that the current risk of perpetual users is too high; I'd rather disable session caches completely to avoid that risk. Even if that means more crypto workload for the server :-/ That's because 3.1.x or 4 is not currently an option. Greetings, Stefan Winter -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 2, avenue de l'Université L-4365 Esch-sur-Alzette Tel: +352 424409 1 Fax: +352 422473 PGP key updated to 4096 Bit RSA - I will encrypt all mails if the recipient's key is known to me http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC0DE6A358A39DC66