Re: [strongSwan] strongSwan reuses stale OCSP responses

2017-11-15 Thread Ander Juaristi
Well, looking at the source code (5.6.0 release tarball), the "offending 
line" is at revocation_validator.c:264:


if (revoked)
{   /* revoked always counts, even if stale */
*valid = VALIDATION_REVOKED;
}

So two questions now come to my mind:

1. What's the reason for this? I might well have missed some detail in 
the specs or maybe it's just a strongSwan-specific design decision. In 
either case (for my own education), what's that line there for?


2. I've seen the stale OCSP responses are deleted from the cache on a 
'ipsec restart'. Could you please point me to the piece of code where 
that cache purge is done?


Regards,
- AJ

El 2017-11-15 13:23, Ander Juaristi escribió:

Hi,

I'm trying to set up a use case where user certificates are revoked
temporarily and then re-activated (think of a user being banned from
accessing the server at set times, according to a policy). So I've got
an OCSP server that returns either "good" or "revoked" responses
according to such policy.

Once my OCSP responder sends a "revoked" answer, strongSwan caches
that answer forever and reuses it over and over again even after it
becoming stale. I would expect strongSwan to query the OCSP responder
again once the cached response becomes stale, but it is not happening.

I don't want to be manually purging the OCSP cache with 'ipsec 
purgeocsp'.


Is there a way to tell strongSwan to remove the expired responses 
automatically?


This looks like the same use case that is described at [0].

Here [1] it says:

A valid OCSP response that revokes a particular certificate will
be used even if it is stale.

but it doesn't say why, specifically, why the response keeps on being
used even if certificateHold was specified as the revoke reason.

Thanks.

Details
===

My OCSP responder is sending revoked responses with a certificateHold
(6) CRLReason, and a next update value of 1 minute later than the
current time:

Cert Status: revoked
Revocation Time: Nov 15 12:00:55 2017 GMT
Revocation Reason: certificateHold (0x6)
This Update: Nov 15 12:00:55 2017 GMT
Next Update: Nov 15 12:01:55 2017 GMT

According to the spec [2], the certificateHold CRLReason means a
certificate has been revoked temporarily:

The "revoked" state indicates that the certificate has been 
revoked,

either temporarily (the revocation reason is certificateHold) or
permanently.

I would expect strongSwan to query the OCSP responder again when the
time expires, but it's not happening so. It keeps on using cached OCSP
responses even though these are stale:

charon: 06[CFG]ocsp response correctly signed by "C=ES,
ST=, L=, O=, CN=ocsp.localhost"
charon: 06[CFG] certificate was revoked on Nov 15 12:00:55 UTC
2017, reason: certificate hold
charon: 06[CFG]   ocsp response is stale: since Nov 15 12:01:55 
2017

charon: 06[CFG]   using cached ocsp response

I can clearly verify, with 'ipsec listocsp' that the response is stale:

List of OCSP responses:

  signer:   "C=ES, ST=, L=, O=, CN=ocsp.localhost"
  validity:  produced at Nov 15 12:00:55 2017
 usable till Nov 15 12:01:55 2017, expired (101 seconds 
ago)


References
==

[0] [strongSwan] OCSP and CRL -
https://lists.strongswan.org/pipermail/users/2015-December/009049.html
[1] Issue #1238 - https://wiki.strongswan.org/issues/1238
[2] RFC 6960 - https://tools.ietf.org/html/rfc6960#section-2.2


[strongSwan] strongSwan reuses stale OCSP responses

2017-11-15 Thread Ander Juaristi

Hi,

I'm trying to set up a use case where user certificates are revoked 
temporarily and then re-activated (think of a user being banned from 
accessing the server at set times, according to a policy). So I've got 
an OCSP server that returns either "good" or "revoked" responses 
according to such policy.


Once my OCSP responder sends a "revoked" answer, strongSwan caches that 
answer forever and reuses it over and over again even after it becoming 
stale. I would expect strongSwan to query the OCSP responder again once 
the cached response becomes stale, but it is not happening.


I don't want to be manually purging the OCSP cache with 'ipsec 
purgeocsp'.


Is there a way to tell strongSwan to remove the expired responses 
automatically?


This looks like the same use case that is described at [0].

Here [1] it says:

A valid OCSP response that revokes a particular certificate will be 
used even if it is stale.


but it doesn't say why, specifically, why the response keeps on being 
used even if certificateHold was specified as the revoke reason.


Thanks.

Details
===

My OCSP responder is sending revoked responses with a certificateHold 
(6) CRLReason, and a next update value of 1 minute later than the 
current time:


Cert Status: revoked
Revocation Time: Nov 15 12:00:55 2017 GMT
Revocation Reason: certificateHold (0x6)
This Update: Nov 15 12:00:55 2017 GMT
Next Update: Nov 15 12:01:55 2017 GMT

According to the spec [2], the certificateHold CRLReason means a 
certificate has been revoked temporarily:


The "revoked" state indicates that the certificate has been revoked,
either temporarily (the revocation reason is certificateHold) or
permanently.

I would expect strongSwan to query the OCSP responder again when the 
time expires, but it's not happening so. It keeps on using cached OCSP 
responses even though these are stale:


charon: 06[CFG]ocsp response correctly signed by "C=ES, ST=, 
L=, O=, CN=ocsp.localhost"
charon: 06[CFG] certificate was revoked on Nov 15 12:00:55 UTC 2017, 
reason: certificate hold

charon: 06[CFG]   ocsp response is stale: since Nov 15 12:01:55 2017
charon: 06[CFG]   using cached ocsp response

I can clearly verify, with 'ipsec listocsp' that the response is stale:

List of OCSP responses:

  signer:   "C=ES, ST=, L=, O=, CN=ocsp.localhost"
  validity:  produced at Nov 15 12:00:55 2017
 usable till Nov 15 12:01:55 2017, expired (101 seconds 
ago)


References
==

[0] [strongSwan] OCSP and CRL - 
https://lists.strongswan.org/pipermail/users/2015-December/009049.html

[1] Issue #1238 - https://wiki.strongswan.org/issues/1238
[2] RFC 6960 - https://tools.ietf.org/html/rfc6960#section-2.2