Project

General

Profile

Issue #354

TLS certificcate CRL is not validated with strictcrlpolicy=yes

Added by tn6Rsnnugz0KEI7WktcN t54DkwcNDM0oTKkIX24p about 7 years ago. Updated about 6 years ago.

Status:
Assigned
Priority:
High
Assignee:
Category:
-
Affected version:
5.0.4
Resolution:

Description

When connecting with EAP-TLS the TLS certificate CRL is not enforced when strictcrlpolicy=yes is defined.

So for example, if a user connects with a certificate that is revoked, and the CRL server is offline and the configuration strictcrlpolicy=yes is set, the connection still continues even though the CRL validation fails!

I have only tested this in 5.0.4

History

#1 Updated by John Doe about 6 years ago

A quick patch to force the expected behavior is as follows:

--- src/libstrongswan/plugins/revocation/revocation_validator.c    2014-08-26 17:20:39.838062752 +1000
+++ src/libstrongswan/plugins/revocation/revocation_validator.c    2014-08-26 17:20:46.310062813 +1000
@@ -765,6 +765,10 @@
                 DBG1(DBG_CFG, "certificate status is unknown, crl is stale");
                 break;
         }
+        lib->credmgr->call_hook(lib->credmgr, CRED_HOOK_REVOKED,
+                                        subject);
+        return FALSE;
+
-         lib->credmgr->call_hook(lib->credmgr, CRED_HOOK_VALIDATION_FAILED,
-                                 subject);
     }

#2 Updated by Martin Willi about 6 years ago

  • Status changed from New to Assigned
  • Assignee set to Martin Willi

Hi,

When connecting with EAP-TLS the TLS certificate CRL is not enforced when strictcrlpolicy=yes is defined.

Yes, none of the connection certificate authentication constraints are currently supported when using EAP-TLS. That information is currently just not propagated from the EAP layer down to IKE.

A quick patch to force the expected behavior is as follows:

While this patch lets authentication fail in that case, the authentication also fails when having a strictcrlpolicy=no. This is not the excepted behavior, and will probably break many setups.

The CRL policy is internally a connection specific option. So instead, we have to add the CRL_VALIDATION property to the EAP authentication round, propagate the result from the EAP layer, and then evaluate the result and accept or reject the currently selected configuration.

This has been on my TODO list for a while, but is not trivial to implement.

Regards
Martin

Also available in: Atom PDF