This registers support for the ML_KEM_{512,768,1024} key exchange
algorithms in the `openssl` plugin when built using AWS-LC as the
libcrypto. To do this, we introduce the `openssl_kem` source files
which implement the key exchange algorithm using the Key Encapsulation
Mechanism (KEM) API. Future KEM algorithms can be implemented
generically using this interface by substituting the appropriate NIDs.
It also supports both seeded (via DRBG) and unseeded modes depending
on the user's requirements for KATs or entropy sources.
It should be noted that this does not add support for KEM algorithms
within upstream OpenSSL and is API incompatible. Future work will need
to condition out the incompatibilities as-appropriate. However, the
high-level logic should be the same for all KEMs and KEM APIs.
References strongswan/strongswan#2228Closesstrongswan/strongswan#2490
Both Diffie-Hellman (DH) and Key Encapsulation Mechanism (KEM) based
key exchange methods use a common ke_test_vector format. The
set_seed() function is used to provide deterministic private key
material for the crypto tests.
struct ifreq can't be used for IPv6 as the ifr_addr member is not large
enough. Actually, configuring an IPv6 address via an AF_INET socket won't
work anyway. And unfortunately, it's not standardized how IPv6 addresses
are installed, so we have to do this quite differently on Linux and on BSD.
However, we already use SIOCAIFADDR for IPv4 on newer FreeBSD systems,
which wasn't the case when this patch was originally created in 2014.
The behavior of realloc(3) with zero size was apparently implementation
defined. While glibc documents the behavior as equivalent to free(3),
that might not apply to other C libraries. With C17, this behavior has
been deprecated, and with C23, the behavior is now undefined. It's also
why valgrind warns about this use.
Hence, when array_compress() would call realloc() with a zero size, we
now call free() explicitly and set the pointer to NULL.
Signed-off-by: Thomas Egerer <[email protected]>
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.
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 <[email protected]>
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.
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.
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
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
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.
Andreas Steffen