On Mar 7, 2017, at 2:45 AM, Stefan Winter <stefan.winter@restena.lu> wrote:
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.
Technically yes.
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.
Indeed. I think however, that there'd be more value in convincing OpenSSL that there current system of validation callbacks is inadequate, rather than attempting to backport the OCSP validation-on-resumption logic to v3.0.x.
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.
In v4.0.x the validity of the OCSP response is controlled by the nextUpdate field in the OCSP response. Or more precisely, the OCSP response can be cached, and the contents of the nextUpdate field is made available to control the lifetime of that cache entry. If the OCSP response isn't cached then a full OCSP validity check will take place on each resumption.
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.
Agreed. You're welcome to try and convince someone to backport the code to v3.0.x, but my backlog is already quite sizeable. -Arran Arran Cudbard-Bell FreeRADIUS Core Developer FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2