Re: [strongSwan] Strongswan caching CRL's when setting is set to "no"

[Tobias Brunner]

Hi Eric,


Does ".reauth_time” and leaving “break_before_make” alone force a reauth 
and certificate validity check on IKE/ISAKMP from non-cached crl’s?


Could you please clarify your question (e.g. why do you mention 
break_before_make in this context?


make_before_break defaults to no.  1) no interruptions in link 2) impact on CRL 
test


It does add a delay to the online certificate validation (via OCSP/CRL) 
on the client, but not change the basic functionality.  Instead of 
validating the certificate while the SA is created, the client waits 
until the new SA is fully established (and tears down the SA if the 
certificate is not valid).



what do you mean with "from non-cached CRLs”?


This was testing to see if it would pull the CRL on each wreath.  In my mind, 
if the CRL is hosted and changes and the CRL is never reloaded from its source, 
a revoked certificate can be used up until a start/restart occurs


It can be used as long as there is no CRL available that revokes it (or 
a negative OCSP response).  If a cached CRL (or OCSP response) is still 
valid, that's what will be used without fetching anything (if the fetch 
fails, the cached status will be accepted unless strict revocation 
checking is enabled).  A restart or purging CRLs/OCSP responses at 
runtime (e.g. via a cron job) will affect the in-memory cache (which 
could also be disabled completely), if CRLs are also cached on disk, 
they have to be removed manually.


As mentioned before, relatively short-lived delta CRLs can be used to 
trigger more frequent fetches (or use OCSP for even more current status 
reports).



are you considering setting reath_time on the client or the server -


Yes.  No effect on reload CRL


No, it does not affect how/when CRLs are fetched.  But without 
reauthentication, certificates are currently not re-checked at all (i.e. 
a client could keep the IKE_SA alive indefinitely).  If you configure it 
on the server, it either initiates a reauthentication itself, if it can 
due to the config, or it requests the client to reauthenticate (the 
IKE_SA is deleted if the client does not reauthenticate in time).



and with what type of authentication/config?


Certs for auth


OK, unless you use virtual IPs, then both peers can initiate a 
reauthentication.



why do you mention ISAKMP, are you actually considering using IKEv1?).


Not considering IKEv1


OK, good.


Looks like if the server cert is revoked, I will need to reach out to all spoke 
instances to bounce so they’ll find out it’s revoked.


They won't find out until (1) they reauthenticate/reestablish the IKE_SA 
and (2) they use a CRL that actually revokes the certificate.  Depending 
on how long the CRL is valid and the caching behavior (as discussed 
before) this can take a while.


Regards,
Tobias

Re: [strongSwan] Strongswan caching CRL's when setting is set to "no"

[Eric Germann]

> On Jun 2, 2022, at 3:50 AM, Tobias Brunner  wrote:
> 
> Hi Eric,
> 
>> Does ".reauth_time” and leaving “break_before_make” alone force a 
>> reauth and certificate validity check on IKE/ISAKMP from non-cached crl’s?
> 
> Could you please clarify your question (e.g. why do you mention 
> break_before_make in this context?

make_before_break defaults to no.  1) no interruptions in link 2) impact on CRL 
test

> what do you mean with "from non-cached CRLs”?

This was testing to see if it would pull the CRL on each wreath.  In my mind, 
if the CRL is hosted and changes and the CRL is never reloaded from its source, 
a revoked certificate can be used up until a start/restart occurs

> are you considering setting reath_time on the client or the server -

Yes.  No effect on reload CRL

> and with what type of authentication/config?

Certs for auth

> why do you mention ISAKMP, are you actually considering using IKEv1?).

Not considering IKEv1

Looks like if the server cert is revoked, I will need to reach out to all spoke 
instances to bounce so they’ll find out it’s revoked.


> 
> Regards,
> Tobias

Re: [strongSwan] Strongswan caching CRL's when setting is set to "no"

[Tobias Brunner]

Hi Eric,

Does ".reauth_time” and leaving “break_before_make” alone force a 
reauth and certificate validity check on IKE/ISAKMP from non-cached crl’s?


Could you please clarify your question (e.g. why do you mention 
break_before_make in this context? what do you mean with "from 
non-cached CRLs"? are you considering setting reath_time on the client 
or the server - and with what type of authentication/config? why do you 
mention ISAKMP, are you actually considering using IKEv1?).


Regards,
Tobias

Re: [strongSwan] Strongswan caching CRL's when setting is set to "no"

[Eric Germann]

Does ".reauth_time” and leaving “break_before_make” alone force a reauth 
and certificate validity check on IKE/ISAKMP from non-cached crl’s?

Apologies for all the questions.

Eric


> On Jun 1, 2022, at 10:43 AM, Tobias Brunner  wrote:
> 
> Hi Eric,
> 
>> 16[IKE] received end entity cert "CN=pfsense.semperen.net 
>> , C=US, ST=OH, L=Van Wert, O=The Semperen 
>> Group, OU=Network Operations"
>> 16[CFG]   using certificate "CN=pfsense.semperen.net 
>> , C=US, ST=OH, L=Van Wert, O=The Semperen 
>> Group, OU=Network Operations"
>> 16[CFG]   using trusted ca certificate "CN=semperen-ipsec-ca, C=US, ST=OH, 
>> L=Van Wert, O=The Semperen Group, OU=Network Operations"
>> 16[CFG] checking certificate status of "CN=pfsense.semperen.net 
>> , C=US, ST=OH, L=Van Wert, O=The Semperen 
>> Group, OU=Network Operations"
>> > 16[CFG]   fetching crl from 
>> > 'https://ipsec-crl.s3.us-east-2.amazonaws.com/Semperen%2BIPSec%2BSigning%2BAuthority%2BCRL.crl
>> >  
>> > '
>> >  … 
>> 16[CFG]   using trusted certificate "CN=semperen-ipsec-ca, C=US, ST=OH, 
>> L=Van Wert, O=The Semperen Group, OU=Network Operations"
>> 16[CFG]   crl correctly signed by "CN=semperen-ipsec-ca, C=US, ST=OH, L=Van 
>> Wert, O=The Semperen Group, OU=Network Operations"
>> 16[CFG]   crl is valid: until Oct 13 19:33:11 2049
>> 16[CFG] certificate status is good
>> 16[CFG]   reached self-signed root ca with a path length of 0
> 
> This happens on demand when the peer certificate is verified, not when the 
> daemon is started.
> 
> Regards,
> Tobias

Re: [strongSwan] Strongswan caching CRL's when setting is set to "no"

[Tobias Brunner]

Hi Eric,

16[IKE] received end entity cert "CN=pfsense.semperen.net 
, C=US, ST=OH, L=Van Wert, O=The Semperen 
Group, OU=Network Operations"
16[CFG]   using certificate "CN=pfsense.semperen.net 
, C=US, ST=OH, L=Van Wert, O=The Semperen 
Group, OU=Network Operations"
16[CFG]   using trusted ca certificate "CN=semperen-ipsec-ca, C=US, 
ST=OH, L=Van Wert, O=The Semperen Group, OU=Network Operations"
16[CFG] checking certificate status of "CN=pfsense.semperen.net 
, C=US, ST=OH, L=Van Wert, O=The Semperen 
Group, OU=Network Operations"
 > 16[CFG]   fetching crl from 
'https://ipsec-crl.s3.us-east-2.amazonaws.com/Semperen%2BIPSec%2BSigning%2BAuthority%2BCRL.crl 
' 
… 
16[CFG]   using trusted certificate "CN=semperen-ipsec-ca, C=US, ST=OH, 
L=Van Wert, O=The Semperen Group, OU=Network Operations"
16[CFG]   crl correctly signed by "CN=semperen-ipsec-ca, C=US, ST=OH, 
L=Van Wert, O=The Semperen Group, OU=Network Operations"

16[CFG]   crl is valid: until Oct 13 19:33:11 2049
16[CFG] certificate status is good
16[CFG]   reached self-signed root ca with a path length of 0


This happens on demand when the peer certificate is verified, not when 
the daemon is started.


Regards,
Tobias

Re: [strongSwan] Strongswan caching CRL's when setting is set to "no"

[Eric Germann]

crluri  = 
"https://ipsec-crl.s3.us-east-2.amazonaws.com/Semperen%2BIPSec%2BSigning%2BAuthority%2BCRL.crl;




16[IKE] received end entity cert "CN=pfsense.semperen.net, C=US, ST=OH, L=Van 
Wert, O=The Semperen Group, OU=Network Operations"
16[CFG]   using certificate "CN=pfsense.semperen.net, C=US, ST=OH, L=Van Wert, 
O=The Semperen Group, OU=Network Operations"
16[CFG]   using trusted ca certificate "CN=semperen-ipsec-ca, C=US, ST=OH, 
L=Van Wert, O=The Semperen Group, OU=Network Operations"
16[CFG] checking certificate status of "CN=pfsense.semperen.net, C=US, ST=OH, 
L=Van Wert, O=The Semperen Group, OU=Network Operations"
> 16[CFG]   fetching crl from 
> 'https://ipsec-crl.s3.us-east-2.amazonaws.com/Semperen%2BIPSec%2BSigning%2BAuthority%2BCRL.crl'
>  … 
16[CFG]   using trusted certificate "CN=semperen-ipsec-ca, C=US, ST=OH, L=Van 
Wert, O=The Semperen Group, OU=Network Operations"
16[CFG]   crl correctly signed by "CN=semperen-ipsec-ca, C=US, ST=OH, L=Van 
Wert, O=The Semperen Group, OU=Network Operations"
16[CFG]   crl is valid: until Oct 13 19:33:11 2049
16[CFG] certificate status is good
16[CFG]   reached self-signed root ca with a path length of 0
16

---
Eric Germann
ekgermann {at} semperen {dot} com || ekgermann {at} gmail {dot} com
LinkedIn: https://www.linkedin.com/in/ericgermann 

Medium: https://ekgermann.medium.com  
Twitter: @ekgermann
Telegram || Signal || Skype || Phone +1 {dash} 419 {dash} 513 {dash} 0712

GPG Fingerprint: 89ED 36B3 515A 211B 6390  60A9 E30D 9B9B 3EBF F1A1







> On Jun 1, 2022, at 3:39 AM, Tobias Brunner  wrote:
> 
> Hi Eric,
> 
>> What's the point of SS having an option to auto fetch a CRL at startup 
> 
> There is no such option.
> 
> Regards,
> Tobias

Re: [strongSwan] Strongswan caching CRL's when setting is set to "no"

[Tobias Brunner]

Hi Eric,

What's the point of SS having an option to auto fetch a CRL at startup 


There is no such option.

Regards,
Tobias

Re: [strongSwan] Strongswan caching CRL's when setting is set to "no"

[Eric K Germann]

I would concur with Harri's point of adding an option to periodically 
reread the CRL's from whatever source they came from.


What's the point of SS having an option to auto fetch a CRL at startup 
but then either having to create an outside-SS workflow to update it or 
do it by hand?  If you do it by hand you might as do the init by hand 
also.


On 2022-05-30 06:02, Tobias Brunner wrote:


Hi Eric,

When IKE reauthenticates the log says it is loading crl from the 
directory (which has nothing in it).


What exactly are you referring to here?  Logs?

Also forcing "rereadcrls" doesn't cause a new fetch.  "files" and 
"curl" plugins are loaded.


If there is a cached CRL (note that `cachecrls` refers to caching CRLs 
persistently in /etc/ipsec.d/crls, not the in-memory cache) that's 
still valid, there won't be a new fetch.  And the `rereadcrls` command 
has no effect on this as it only triggers a reload of CRLs from 
/etc/ipsec.d/crls, it does not purge any in-memory caches (try 
`purgecrls` for that).  Also see this thread [1 [1]].


Regards,
Tobias

[1] https://lists.strongswan.org/pipermail/users/2022-April/015291.html



Links:
--
[1] https://lists.strongswan.org/pipermail/users/2022-April/015291.html

Re: [strongSwan] Strongswan caching CRL's when setting is set to "no"

[Tobias Brunner]

Hi Eric,

  When IKE reauthenticates the log says it is loading crl from the 
directory (which has nothing in it).


What exactly are you referring to here?  Logs?

 Also forcing “rereadcrls” doesn’t 
cause a new fetch.  “files” and “curl” plugins are loaded.


If there is a cached CRL (note that `cachecrls` refers to caching CRLs 
persistently in /etc/ipsec.d/crls, not the in-memory cache) that's still 
valid, there won't be a new fetch.  And the `rereadcrls` command has no 
effect on this as it only triggers a reload of CRLs from 
/etc/ipsec.d/crls, it does not purge any in-memory caches (try 
`purgecrls` for that).  Also see this thread [1].


Regards,
Tobias

[1] https://lists.strongswan.org/pipermail/users/2022-April/015291.html