The previous code had some issues because it handled each child config
separately. Not only was this quite inefficient because all IKE_SAs had
to be enumerated for every config, it also caused problems with the check
for other CHILD_SAs in order to decide whether to delete the IKE_SA or
not. Because CHILD_SAs are deleted with an INFORMATIONAL exchange, they
are not immediately gone. This caused a race condition and with more
than one child config and SAs the IKE_SA could be kept because it
could appear as if other, unrelated CHILD_SAs were still there.
Another race condition, which is fixed by the previous commit, occurred
when only changing child configs. Then it could happen that the code
deemed the IKE_SA empty and a delete for it was queued. If that happened
while the IKE_SA was deleting one of the CHILD_SAs (or was busy with some
other exchange), the IKE_SA was not switched to IKE_DELETING. So it
looked usable and create-child tasks for the updated configs might have
gotten queued. Unfortunately, once the ike-delete task is eventually
executed, these tasks would be gone and the replacement CHILD_SAs never
created. This commit additionally avoids actually deleting the IKE_SA
even if all child configs change or get removed if any new CHILD_SAs are
to be initiated.
The IKE_SA might be busy with a different task while a request to
terminate it is getting queued, we don't want to use such an IKE_SA to
initiate new CHILD_SAs as these tasks will get lost once the IKE_SA is
terminated.
The empty array of rules for `assert_message_empty()` and the resulting
size 0 triggers warnings like these:
allocation of insufficient size '0' for type 'listener_message_rule_t' with size '12'
Using calloc() with `nmemb` set to 0 triggers the same warning.
The number of elements is the first argument, their size the second.
The previous code triggered the following warning:
'calloc' sizes specified with 'sizeof' in the earlier argument and not in the later argument
Instead of just adding the offset internally, this way the reported
base address is always the first assignable address (e.g. for
192.168.0.0/24 vs. 192.168.0.1/24).
Closesstrongswan/strongswan#2264
If the regular daemon is running, it creates an unconditional routing
rule for the routing table. The rule that charon-nm tries to create,
which excludes marked IKE/ESP traffic to avoid a routing loop, then
can't be installed and we'd end up with said loop.
Closesstrongswan/strongswan#2230
As recommended by RFC 2985, section 5.4.1:
ChallengePassword attribute values generated in accordance with this
version of this document SHOULD use the PrintableString encoding
whenever possible. If internationalization issues make this
impossible, the UTF8String alternative SHOULD be used.
Even though the RFC continues with
PKCS #9-attribute processing systems MUST be able to recognize and
process all string types in DirectoryString values.
there might be older SCEP server implementations that don't accept
UTF8String-encoded passwords. In particular because previous versions of
PKCS#9 defined this attribute's type as a CHOICE between PrintableString
and T61String.
References strongswan/strongswan#1831
Can be useful if the CID inside the VM is not known.
The \htmlonly\endhtmlonly hack is used to avoid compiler warnings due
to /* inside a block comment.
These allow, for instance, a vici client on a host to communicate with
an IKE daemon running in a VM.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
If a base address is configured, we don't expect the pool to be empty,
so reject the creation (e.g. with the broadcast address as base).
References strongswan/strongswan#2205
There are definitions of RNG in <wolfssl/wolfcrypt/settings.h> and
<wolfssl/wolfcrypt/random.h> that play havoc with the literal RNG being
used in the expansions of PLUGIN_*(RNG, ...) when ##-concatenated to
build the enum value FEATURE_RNG.
The #undef in wolfssl_cmmon.h only had an effect if wolfSSL was built
with EdDSA or FIPS enabled, otherwise, the headers that define RNG were
not pulled in before it.
Signed-off-by: Philip Prindeville <philipp@redfish-solutions.com>
This is a patch from the OpenWrt package sources necessary to adapt to
changes from 2008 that abstracted the option datatype (added a list
type).
Signed-off-by: Noel Kuntze <noel.kuntze@thermi.consulting>
Reviewed-by: Philip Prindeville <philipp@redfish-solutions.com>
With GCC 13, the compiler apparently applies new aliasing optimizations
when compiled with -O2 and without -fno-strict-aliasing. This caused
the application of the second padding bit, where the state was accessed
via uint8_t[], to be moved before the loop that absorbs the buffer into
the state, where the state is accessed via uint64_t[], resulting in
incorrect output. By only accessing the state via uint64_t[] here the
compiler won't reorder the instructions.
musl's headers define a lot of networking structs. For some, the
definition in the Linux UAPI headers is then suppressed by e.g.
__UAPI_DEF_ETHHDR.
Since we included musl's net/ethernet.h, which includes netinet/if_ether.h
that defines `struct ethhdr` (and the above constant), **after** we
include linux/if_ether.h, there was a compilation error because the
struct was defined multiple times.
However, simply moving that include doesn't fix the problem because for
ARP-specific structs the Linux headers don't provide __UAPI_DEF* checks.
So instead of directly including the linux/ headers, we include those
provided by the C library. For glibc these usually just include the
Linux headers, but for musl this allows them to define the struct
directly. We also need to move if.h and add packet.h, which define
other structs (or include headers that do so) that we use.
Fixes: 187c72d1af ("dhcp: Port the plugin to FreeBSD/macOS")
The previous option caused such requests to be enabled if not explicitly
disabled, which only the vici plugin did, for all other backends requests
would have been sent.
References strongswan/strongswan#2016
Only the vici plugin previously set OCSP_SEND_REPLY explicitly, all other
backends would have defaulted to OCSP_SEND_BOTH.
References strongswan/strongswan#2016
In particular for static code analyzers. The previous nesting of case
statements inside of a while loop that's inside a switch statement and
a wrapping block with declaration was quite weird and Coverity didn't
like it (it figured that `type` was uninitialized even when it assumed
that get_type() returned a known type for which a case statement
existed).
AWS-LC rejects public keys with explicitly encoded parameters but allows
private keys that use explicit encodings of the NIST curves. Since the
more important aspect is that public keys are rejected, this addition to
the warning message points that out.
References strongswan/strongswan#1907
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.
Enum arguments (ARG_ENUM with .list != LST_bool) are assumed to be of
type/size int in assign_args() in args.c.
Fixes: 0644ebd3de ("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 18082ce2b0 ("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] https://github.com/google/boringssl/commit/bdc35b63617f78037768f4897d8835696f02181a
[2] https://datatracker.ietf.org/doc/html/rfc5280#section-4.1.2.2
This reverts commit 8b9b11919d.
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.
Tobias Brunner