ocsp timeout and server failure

Matthew Newton mcn4 at leicester.ac.uk
Mon Jan 16 22:47:42 CET 2012


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/56d6093828839ece191dadec45f734224dd9fc54


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/119ac969d8c658934d86deb6788d300eb8d21827

Comments?

Cheers,

Matthew


-- 
Matthew Newton, Ph.D. <mcn4 at 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 at le.ac.uk>



More information about the Freeradius-Devel mailing list