Forum Discussion
AltocumulusCRL Validator
EmployeeOCSP does indeed have a few advantages over CRL:
- CRLs are often large, so they would have to be downloaded in entirety before parsing. That could cause some initial connections to fail while that's happening. Or you have to go out of your way to pre-fetch and cache all known CRLs. Not everyone is so lucky to know what those CRLs are and where to get them from (until the client arrives). OCSP requests are small, discreet transactions, usually on the order of 1-2K tops. An OCSP responder does the pre-fetching and caching, and the OCSP client simply makes a request for some specific piece of information. In that respect, OCSP can be highly performant. Plus it doesn't put any additional burden on the BIG-IP to store and manage large CRLs.
- You have the same issue with OCSP that you'd have with CRLs if the remote service becomes unavailable. But then a local OCSP responder is easy to build, and many options are free. I worked for many years with US DoD and CRLs were never really an option for client cert revocation given the immense size of the CRLs. A local OCSP responder not only alleviates that, but you can also usually configure a responder to respond past the expiration of the CRL. That was sometimes a problem too, where the CRL would go stale before a new one could be fetched. With the local responder we could set it to return the last status of a cert in the previous copy of the CRL. I don't think that's possible with pure CRLs.
As to the CRL refresh script option, the more I think about it, this probably wouldn't work in your scenario. The idea would be to have a script that perdiodically queries the site and passes a client cert, forcing the client SSL profile to fetch the CRL if it's not in cache. The issue here is that your script would need a client cert for each respective CRL. I imagine you could spoof this, but I'd have to test that to know for sure.
AltocumulusCheers again for the reply 😊
I agree in ‘normal’ operation OCSP has clear benefits over CRL. However in my scenario I see clear advantages to pre-fetching the CRLs. I can’t go into the finer specifics of my scenario, but I know it will apply to many others. The key general concepts are:
- Known CRLDPs (allows for pre-fetching on a regular basis, i.e. updated in background)
- CRLs are small – they are many magnitudes smaller than the permissible sizes referenced by K10054 (even if concatenated into a single file – although I realise they will only grow over time, so concatenating gains more potential for issues over time)
Unfortunately there doesn’t seem to be an option to pre-fetch the files natively in the F5 arsenal. APM comes closest in that you can use an ‘Update Interval’ so as to continually refresh CRLs based on a timeframe of your choosing (unlike CRL Validator which relies on the nextupdate filed), but APM has downsides:
- CRL only downloaded at point that client cert received (connections held up and as you say it’s for the whole CRL)
- If multiple certs received at essentially the same time then I believe multiple CRL downloads are kicked off until one of them completes and the CRL is actually cached
- I _believe_ (welcome to hear otherwise 😊 ) if the CRL download has been started based on the Update Interval then if that download fails the client connection is dropped – i.e. even though the CRL nextupdate hasn’t expired, the existing CRL is seen as invalid because the Update Interval has passed, so there is no kind of ‘fallback’ (whereas if CRL was pre-fetched in the background there would be no impact to current client connections if a CRL download fails – the system just waits for the next download to trigger and in the meantime the existing CRL is used).
Regarding expired CRL – the SSL profiles allow for that option, but it is on a single CRL (unless trying to use concatenated CRLs).
Local OCSP responder sounds interesting, but it will still hold up connections rather than just making a check against a local file. A local OCSP connection should be very quick, but surely it would still be longer than a local compare on the F5 against a CRL? You then also have to manage something separate to the F5, which is a headache for companies when they have bought the F5 to do all of this work (e.g. keeping on top of security issues and applying patches, more devices to bring under a support model and to manage alerts from etc. etc.).
Regarding forcing a refresh by presenting various client certs (one per CRL) - having the certs to present would be no problem at all in my scenario – test certs are available and constantly refreshed. However it wouldn’t really do what I need – I want the CRL to be refreshed in the background. There is sufficient load that real traffic would likely trigger a CRL download long before the automated script did.
Unfortunately there just doesn’t appear to be a method to do what I need (other than possibly concatenated CRL if we can get round the support issues) so I will look into the alternatives. CRL Validator won’t be one of them based on the cache being for nextupdate (would be simply too long between refreshes). APM is a potential but with those downsides I mentioned.
