If there are many CHILD_SAs, the time between initiating the new IKE_SA
and checking it in might be longer (depending on what else is going on
in the daemon) than the retransmission timeout and no retransmits might
be sent afterwards for this SA (it will just linger around dead).
Calling initiate() last should avoid that (we do this similarly for MBB
reauthentication).
If we are using make-before-break reauthentication, this could lead to
duplicates as the new IKE_SA wouldn't be able to delete the previous
one if it was replaced by a rekeying.
If we initiated a make-before-break reauthentication and the peer
concurrently deletes the IKE_SA (e.g. because it uses break-before-make
reauthentication), we would create a duplicate IKE_SA (the condition forces
a recreation of all existing CHILD_SAs because reestablish() is also called
to complete a break-before-make reauthentication).
Previously, only the tpm plugin initialized the library, so in order
to use a TPM 2.0 (a required TCTI library is loaded via init), it was
necessary to load it even if none of its actual features were used.
OpenSSL enforces a minimum of 14 bytes (112 bits) on the key size when
used in FIPS-mode (as required by SP 800-131A). So by using an empty
string, instantiation always failed. 32 bytes (256 bits) should be safe
for now.
Closesstrongswan/strongswan#557
This is required when targeting Android 11 (API 30) in order to see all
packages, which we use to allow selecting apps ex-/included from VPN
profiles and for the EAP-TNC use case.
As suggested by the Android docs, we use a global thread pool and handler
to avoid recreating them repeatedly. Four threads should be more than
enough as we only use this to load CA certificates when the app starts
initially and to load user certs when editing a profile.
This will be mandatory for new apps in August and for existing apps
in November. However, several classes like AsyncTask are now deprecated
so this needs some work to avoid warnings and problems in the future.
The addresses observed by the client behind the NAT are exactly the same if
the NAT router gets restarted.
Fixes: 2b255f01af ("ike-mobike: Use ike_sa_t::update_hosts() to trigger events")
If two threads are waiting in find_entry() and remove_entry(),
respectively, and the former is woken first, the latter remains stuck
as it won't get signaled.
If there are threads waiting in find_entry() and one in remove_entry()
and the latter is woken first by a thread calling put_entry(), the
former threads would remain stuck as they get never signaled.
This can happen if an IKE_SA is terminated forcefully shortly before
terminating the daemon. The thread that handles the terminate command
will call checkin_and_destroy(), which unregisters the IKE_SA from the
manager before destroying it. The main thread that calls flush() on the
IKE_SA manager won't wait for this SA (its entry is already gone), so
the processor and in turn the watcher job/thread might get canceled
before the first thread started deleting the VIP. It would then wait
indefinitely for a signal that can never be sent.
There is still a small chance the thread hangs in wait() if the state check
happens right before the watcher is canceled and it wasn't yet able to
deliver the event from the kernel, we counter that by rechecking the state
after a while.
If a PKCS#11 library/token doesn't provide one or more attributes via
C_GetAttributeValue(), we get back CKR_ATTRIBUTE_TYPE_INVALID (similar
for protected attributes where CKR_ATTRIBUTE_SENSITIVE is returned).
This is not an error as the spec demands that all attributes have been
processed with the unavailable attributes having set their length
field to CK_UNAVAILABLE_INFORMATION.
We use this to handle the CKA_TRUSTED attribute, which some tokens
apparently don't support. We previously used a version check to remove
the attribute from the call but even the latest spec doesn't make the
attribute mandatory (it's just in a list of "common" attributes for
CKO_CERTIFICATE objects, without a default value), so there are current
tokens that don't support it and prevent us from enumerating certificates.
Depending on how CLOCK_MONOTONIC is implemented, time_monotonic() might
return 0 within 1 second after the system is started. If that's the
case, we just default to 0 for now to avoid a crash (doesn't "hide" the
system time, but it's only the uptime anyway in this case).
Closesstrongswan/strongswan#435.
This now includes all key material derived for IKE_SAs in the order
defined in the RFC:
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr}
= prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr)
Signed-off-by: Thomas Egerer <[email protected]>
Andreas Steffen