Wrap the functions that require it in PRIVATE_KEY_UNLOCK/PRIVATE_KEY_LOCK.
This can't be done at plugin initialization because it needs to be done
for every thread. strongSwan currently doesn't provide on-thread-create
callbacks for plugins so we need to wrap each direct call. Another reason
to do so is that some functions we call (e.g. wc_EccKeyToDer) internally
call PRIVATE_KEY_UNLOCK/PRIVATE_KEY_LOCK and would leave the keys locked
for that particular thread.
Some implementations enforce a minimum key size (e.g. wolfSSL in FIPS
mode) and in practice, the keys will be longer anyway (e.g. our nonces
are 32 bytes).
When cross-compiling for Windows on Ubuntu, we don't have POSIX regular
expressions available (there does not seem to be any alternative libraries
either), but since the tests are not executed that's OK. On AppVeyor,
MSYS2 has libgnurx installed, which works fine but requires explicit
linking with `-lregex`.
This is loosely based on a patch by Thomas Egerer.
The `crypt` functions defined here conflict with the `crypt` function
defined in `unistd.h` and trigger compilation errors when building
against the latest version of AWS-LC, which introduced a new transitive
include of `unistd.h` via `bio.h`.
This simply renames the function to avoid the error.
Closesstrongswan/strongswan#2786
This allows accepting clients that send proposals with non-optional KE
methods during rekeying, while still accepting clients that use the
previous non-KE default proposals.
If this is used, the functionality to set a private key/value/seed for
key exchange methods is removed (including from the interface to avoid
accidentally forgetting to wrap implementations and uses of set_seed()).
The set_seed() method is assigned outside the INIT() macro to avoid
potentially undefined behavior (preprocessing directives in macro
arguments).
The test done by the crypto tester is a simple functionality test.
So far, the timeout value was only used as connect timeout while a
malicious server could accept the connection and then starve us. So use
the timeout for LDAP_OPT_TIMEOUT, too, which affects all synchronous
calls. In particular, ldap_simple_bind_s(), which has no timeout
argument like ldap_search_st().
Signed-off-by: Thomas Egerer <[email protected]>
As described in the previous commit, GCC 15 uses C23 by default and that
changes the meaning of such argument-less function declarations. So
whenever we assign such a function to a pointer that expects a function
with arguments it causes an incompatible pointer type warning. We
could define dedicated functions/callbacks whenever necessary, but this
seems like the simpler approach for now (especially since most uses of
these functions have already been cast).
Besides being clearer, this fixes issues with GCC 15. The latter uses
C23 by default, which changes the meaning of function declarations
without parameters such as
bool return false();
Instead of "this function takes an unknown number of arguments", this
now equals (void), that is, "this function takes no arguments". So we
run into incompatible pointer type warnings all over when using such
functions. They could be cast to (void*) but this seems the cleaner
solution for this use case.
Synchronization for the additional transforms in the IKE and Child SA
proposals is added. Details of the IKE_SA synchronization are changed
to support IKE_INTERMEDIATE exchanges that cause multiple HA_IKE_ADD
messages and key derivations. The cache has been extended to handle
multiple such messages.
Co-authored-by: Thomas Egerer <[email protected]>
Also enables the `kdf` plugin automatically if building against an older
version of OpenSSL.
Closesstrongswan/strongswan#2602
Co-authored-by: Tobias Brunner <[email protected]>
Useless and causes a compiler warning/error:
error: a function declaration without a prototype is deprecated in all versions of C and is treated as a zero-parameter prototype in C23, conflicting with a subsequent declaration [-Werror,-Wdeprecated-non-prototype]
Self-signed trust anchors are not part of the certificate path validation
according to RFC 8280, section 6.1:
When the trust anchor is provided in the form of a self-signed
certificate, this self-signed certificate is not included as part of
the prospective certification path.
But policies in them could still be used, as stated in section 6.2:
Where a CA distributes self-signed certificates to specify trust
anchor information, certificate extensions can be used to specify
recommended inputs to path validation. For example, a policy
constraints extension could be included in the self-signed
certificate to indicate that paths beginning with this trust anchor
should be trusted only for the specified policies. [...]
Implementations that use self-signed certificates to specify trust
anchor information are free to process or ignore such information.
So unconditionally enforcing that self-signed root certificates contain
the policies is probably too strict. Often they won't contain the
extension at all. With this change, we allow that but still enforce the
policies in case such a certificate contains them. The other
policy-related constraints are also enforced still should they be
contained.
Closesstrongswan/strongswan#2601
These have been discouraged for a long time and there are now more and
more crypto libraries that have them disabled by default. However, for
some we only can detect this at runtime, in particular in FIPS mode, so
tests would fail as the plugins would still announce them. So instead
we just remove the schemes from these tests for now (at least for RSA,
removing signatures with SHA-1 completely isn't an option yet as that's
still the default with some clients).
Closesstrongswan/strongswan#2523
Tobias Brunner