This refactors the name constraints validation in the revocation plugin
so it aligns with what's specified in RFC 5820.
It also expands the subnet/range matching for identities.
Closesstrongswan/strongswan#2114
The previous code was in a way too simple which resulted in it being too
strict. For instance, it enforced that intermediate CA certificates
inherited the name constraints of their parents. That's not required by
RFC 5280 and prevented e.g. adding constraints in an intermediate CA
certificate that's followed by another that doesn't contain any
name constraints. That's perfectly fine as the set of constraints
specified by the parent continue to apply to that CA certificate and
the children it issues.
Name constraints were previously also applied to all identities of a
matching type, which is way too strict except for some very simple
cases. It basically prevented multiple constraints of the same type
as e.g. an intermediate CA certificate that has permitted name constraints
for example.org and example.com couldn't issue acceptable certificates
because any SAN with one domain would get rejected by the other
constraint. According to RFC 5280 matching one constraint is enough.
Also fixed is an issue with name constraints for IP addresses which were
previously only supported for a single level.
AWS-LC is an OpenSSL derivative which can be used with the openssl plugin.
This adds a CI job that resembles the openssl-3 test case. It downloads
the source tarball for an AWS-LC release, builds that source using
CMake/Ninja, and then builds/tests strongSwan using the same technique
used by openssl-3.
References strongswan/strongswan#1907Closesstrongswan/strongswan#2151
Enum arguments (ARG_ENUM with .list != LST_bool) are assumed to be of
type/size int in assign_args() in args.c.
Fixes: 0644ebd3de62 ("implemented IKE_SA uniqueness using ipsec.conf uniqueids paramater additionally supports a "keep" value to keep the old IKE_SA")
Closesstrongswan/strongswan#2148
AWS-LC (and likely BoringSSL) uses thread specific data to store internal
library state which gets freed via a registered destructor when the thread
terminates. If this thread happens to be the main thread, which runs the
leak-detective evaluation, the detective won't observe the corresponding free
of the related memory and erroneously reports it as a leak.
The two places this happens are:
- `RAND_bytes` for storing internal RNG state.
- `ERR_put_error` for storing the per-thread OpenSSL error queue.
References strongswan/strongswan#1907Closesstrongswan/strongswan#2147
OpenSSL stores the serial number for an X509 certificate as an
`ASN1_INTEGER` type. Within BoringSSL (and AWS-LC), the library
represents the value of zero as an empty array [1] which is different
from OpenSSL which represents it as the 1-byte array [0x00]. Though the
value of zero for the certificate serial number is illegal under
X.509 [2], we need to handle/encode it consistently within strongSwan.
From 18082ce2b061 ("certificates: Retrieve serial numbers in canonical
form"), we infer that the canonical representation of the zero serial
is [0x00]. To do this, we introduce `openssl_asn1_int2chunk` to
complement the existing string version that allows us to handle the
special case for zero instead of always returning a reference to the
library-dependent encodings.
References strongswan/strongswan#1907Closesstrongswan/strongswan#2138
[1] bdc35b6361
[2] https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.2
This reverts commit 8b9b11919d92e9738bb52901c9dbcc72e35b9fed.
Since ESN was negotiated via proposal, just configuring the SA without
ESN won't work as the ICV will be incorrect if the peer enabled ESN
on its SA. While the Linux kernel currently doesn't support disabling
replay protection for SAs that use ESN, this at least gets users an
explicit error not just dropped packets, and it will automatically work
if the kernel supports this combination at some point.
References strongswan/strongswan#2117
This is used to install, replace or delete currently installed trusted
certificates based on the app's current managed configuration.
Certificates that are shared between multiple profiles are protected
and not uninstalled if a profile that uses it remains.
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.
