ocsp timeout and server failure
Hi, If freeradius tries to talk to an OCSP responder, and the server is not available for some reason, the ocsp check gets stuck for a while, then bombs out with (as expected) a verification failure. The two problems are that it takes quite a while for the client to be told it can't connect, and clients with good certificates can't connect. The obvious solution is to make the ocsp server more resilient, but that's not always going to be possible. The easy solution to the problem of the server temporarily going away seems to be to add a "soft-fail" option, whereby the server will accept the certificate if it can't talk to the OCSP responder. This obviously has some security implications so can't be done unless it's been thought through properly. However, even adding this feature doesn't solve the problem, as the whole client access request fails because the OCSP takes so long to timeout (depending on failure mode). I'm guessing a reasonable solution, apart from high availability OCSP, is to have a short timeout on the ocsp query, then enable success if the server fails to respond (e.g. the certificate can't be checked), and to also use CRLs that are updated frequently. OCSP can then be used as an 'immediate' solution, whereas the CRL is the more permanent in case OCSP isn't available. I've written two smallish patches against v2.1.x - the first adds a 'timeout' option to the ocsp section. This gives up checking after the set number of seconds. I've tested this code through several different scenarios and it seems to all behave as expected (setting timeout=0, the default, has the same behaviour as before): https://github.com/mcnewton/freeradius-server/commit/56d6093828839ece191dade... The second option adds the option 'softfail', which by default is "no" (the safer option). In the case it's set to yes, a failure to query the server (or get a response) is treated as a success in terms of validation. There are warnings in the eap.conf file that this is not entirely secure, so needs to be assessed according to the risk. It's a simpler patch from the above, and applies on top: https://github.com/mcnewton/freeradius-server/commit/119ac969d8c658934d86deb... Comments? Cheers, Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
Matthew Newton wrote:
If freeradius tries to talk to an OCSP responder, and the server is not available for some reason, the ocsp check gets stuck for a while, then bombs out with (as expected) a verification failure. The two problems are that it takes quite a while for the client to be told it can't connect, and clients with good certificates can't connect.
Yeah, there's no real perfect solution.
The obvious solution is to make the ocsp server more resilient, but that's not always going to be possible.
Yup.
I've written two smallish patches against v2.1.x - ... Comments?
Committed. :) See the v2.1.x && master branches. Alan DeKok.
Hi, On Mon, Jan 23, 2012 at 03:49:26PM +0100, Alan DeKok wrote:
Matthew Newton wrote:
If freeradius tries to talk to an OCSP responder, and the server is not available for some reason, the ocsp check gets stuck for a ...
Committed. :)
See the v2.1.x && master branches.
Thanks - looks like I've caused trouble already :) Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Architect (UNIX and Networks), Network Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
participants (2)
-
Alan DeKok -
Matthew Newton