This installs the configured user certificate into Android's key store
using the DevicePolicyManager.
This is only accessible if the app is installed on an enrolled device and
has been granted the CERT_INSTALL delegate scope.
While it seems to be possible to cast Context.getApplicationContext()
to the application class, there really is no documented reason why that
should actually be the same object.
Triggers a broadcast if the configuration changed and updates the
profile list accordingly (previously only handled removal of multiple
profiles).
If the app resumes, the configuration is also loaded and listeners are
notified in case the config was updated while the app was in the
background.
AWS-LC lacks support for a number of elliptic curve algorithms so this
adds some conditional macros to avoid registering the related plugin
features. Support for curves ed448 and x448 is completely absent and are
not planned for implementation as they are no longer recommended for use.
While ed25519 is supported by the library, a single missing API for
ASN.1 DER encoding of its private keys is missing which prevents its
use in strongSwan. Future work may remove this limitation, but for now
we will disable the functionality.
Closesstrongswan/strongswan#2109
AWS-LC is a BoringSSL-based libcrypto implementation. SHA_CTX is declared with
the hash data specified as an array rather than as a field in upstream OpenSSL.
Since AWS-LC builds against C99, we are unable to handle this with anonymous
unions like BoringSSL. The workaround I propose is to add these conditional
macros around the accessors within openssl_sha1_prf. After this change,
everything builds successfully with AWS-LC headers.
Closesstrongswan/strongswan#2103
This also refactors the BPF handling so it can be shared between the
dhcp and farp plugins. The latter is adapted accordingly.
Closesstrongswan/strongswan#2047
Co-authored-by: Tobias Brunner <tobias@strongswan.org>
Different users in the strongSwan code base use the refcount helpers to
allocate incrementing unique values. So far the risk of overflows for
these unsigned 32-bit values has been considered mostly theoretical, as
it requires a longer uptime and a lot of activity to hit such an overflow.
At least for the Netlink sequence numbers, this is not only theoretical,
though, and an overflow has been hit on a productive setup. Unfortunately,
the consequences are rather unpleasant, as the response with a zero
sequence number can't be matched to the request. This results in the
offending thread to block indefinitely while holding the Netlink mutex.
So add a helper to allocate incrementing unique identifiers that checks
for overflows and never returns 0. Use it for Netlink sequence numbers
and some other potential users affected, namely those allocating
IKE_SA/CHILD_SA unique identifiers, marks and interface identifiers.
Closesstrongswan/strongswan#2062
The refcount_t for allocating unique marks and interface IDs may overflow or
hit the special value for unique marks/if_ids, in the worst case not setting it
on CHILD_SAs that should have one.
As (potentially two) marks/if_ids are allocated only for newly created CHILD_SAs,
but not for rekeying, this not very likely. Still, if a setup uses
aggressive re-authentication and or re-creates CHILD_SAs every minute,
a gateway with 100'000 tunnels may hit the overflow within a month uptime.
CHILD_SA unique identifier allocation starts at 1. If the counter overflows,
a unique ID of 0 is assigned to an CHILD_SA, which may have unclear
consequences.
Overflowing the unique ID counter is theoretical for most setups, but on
a Gateway terminating 100'000 tunnels and rekeying CHILD_SAs every 60s
overflows the counter after a month uptime. So avoid a 0 unique identifier
by using ref_get_nonzero().
