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.
