This was the order before 46a6b06282 ("openssl: Only announce ECDH
groups actually supported by OpenSSL") but that's not really the reason
for this change. It's related to the Android app, where we previously
didn't support these DH groups in BoringSSL and added the curve25519
plugin after the openssl plugin instead. This resulted in the same
order, i.e. ECDH groups before curve25519. With the switch to OpenSSL
and the mentioned commit, this changed and curve25519 was now the first
group that was proposed and used for the KE payload. Not really an
issue you'd think, however, there are apparently Zyxel Firewalls with
older firmware versions (some forum posts mentioned a fix in V5.31) that
can't handle KE payloads with DH groups > 21 (ecp521). So with
curve25519 (31) proposed in the KE payload, they silently dropped the
IKE_SA_INIT request and no connection could be established.
If libcurl is built with MultiSSL support (not the case for e.g.
Debian/Ubuntu, which ship separate, conflicting libraries), this allows
selecting the SSL/TLS backend libcurl uses.
Only older versions of OpenSSL and GnuTLS need special treatment, so we
now accept all other backends (e.g. "(SecureTransport) OpenSSL/1.1.1s"
on macOS).
Whenever we remove support for the affected versions of the mentioned
libraries, we can remove the corresponding *-threading plugin feature
and the code here.
The x509 plugin retrieves serial numbers with two's complement
encoding whereas the openssl plugin partially returns them without
leading zeroes.
Serial numbers in X.509 certificates, X.509 CRL, X.509 attribute
certificates, OCSP Requests and OCSP responses are now returned in
canonical form without prepended zero octets.
The wolfSSL's OpenSSL compatibility layer is not used by the plugin at
all and preventing its inclusion avoids conflicts with ASN1_ constants.
The inclusion of wolfssl/ssl.h is moved to the only file that requires
it as older wolfSSL versions defined a conflicting ASN1_GENERALIZEDTIME.
Other changes address issues with the FIPS use case.
Closesstrongswan/strongswan#1332
Malicious servers could otherwise block the fetching thread indefinitely
after the initial TCP handshake (which has a default timeout of 10s
in the curl and winhttp plugins, the soup plugin actually has a default
overall timeout of 10s).
The pattern currently is to call get_cache(), generate the encoding
if that failed and then store it with cache(). The latter adopts the
passed encoding and frees any stored encoding. However, the latter means
that if two threads concurrently fail to get a cached encoding and then
both generate and store one, one of the threads might use an encoding
that was freed by the other thread.
Since encodings are not expected to change, we can avoid this issue by
not replacing an existing cache entry and instead return that (while
freeing the passed value instead of the cached one).
Closesstrongswan/strongswan#1231
When an X.509 certificate has to be renewed it is helpful to use
the old PKCS#10 certificate request as a template, so that the
distinguishedName (DN), the subjectAlternativeName (SAN) and
a certificate profile name don't have to be typed-in again.
The old public key in the existing certreq is replaced with the
new key and the signature is re-generated using the new private key.
The msCertificateTypeExtension OID (1.3.6.1.4.1.311.20.2) can
be used in a PKCS#10 certificate request to define a certificate
profile. It consists of an UTF8 string.
pki: profile option
Rename `encrypt` methods to avoid the following build failure when wolfSSL
is built with --enable-opensslextra:
In file included from ../../../../src/libstrongswan/utils/utils.h:59,
from ../../../../src/libstrongswan/library.h:101,
from wolfssl_common.h:29,
from wolfssl_aead.c:23:
wolfssl_aead.c:90:16: error: conflicting types for 'encrypt'; have '_Bool(union <anonymous>, chunk_t, chunk_t, chunk_t, chunk_t *)'
90 | METHOD(aead_t, encrypt, bool,
| ^~~~~~~
../../../../src/libstrongswan/utils/utils/object.h:99:20: note: in definition of macro 'METHOD'
99 | static ret name(union {iface *_public; this;} \
| ^~~~
In file included from /home/autobuild/autobuild/instance-5/output-1/host/powerpc64le-buildroot-linux-musl/sysroot/usr/include/wolfssl/wolfcrypt/wc_port.h:573,
from /home/autobuild/autobuild/instance-5/output-1/host/powerpc64le-buildroot-linux-musl/sysroot/usr/include/wolfssl/wolfcrypt/types.h:35,
from /home/autobuild/autobuild/instance-5/output-1/host/powerpc64le-buildroot-linux-musl/sysroot/usr/include/wolfssl/wolfcrypt/logging.h:33,
from /home/autobuild/autobuild/instance-5/output-1/host/powerpc64le-buildroot-linux-musl/sysroot/usr/include/wolfssl/ssl.h:35,
from wolfssl_common.h:64,
from wolfssl_aead.c:23:
/home/autobuild/autobuild/instance-5/output-1/host/powerpc64le-buildroot-linux-musl/sysroot/usr/include/unistd.h:149:6: note: previous declaration of 'encrypt' with type 'void(char *, int)'
149 | void encrypt(char *, int);
| ^~~~~~~
Closesstrongswan/strongswan#1201
The content field of type OCTET STRING of a ContentInfo object
with ContentType Data
ContentInfo ::= SEQUENCE {
contentType ContentType,
content
[0] EXPLICIT OCTET STRING OPTIONAL
is optional and can be missing if no data is available
The 5.4.0 update changed the default bignum implementation to what
could explicitly be enabled via `--enable-sp-math-all`. Since this uses
fixed-sized buffers sufficient for key sizes of SP_INT_BITS, with a default
of 4096, modp6144 and modp8192 didn't work anymore (wc_DhGenerateKeyPair()
returned MP_EXPTMOD_E). So we have to adapt the feature checks for this.
To support the larger DH groups we can either increase the buffer size
via `--with-max-rsa-bits` or add `--enable-heapmath` so buffers get
(re-)allocated as needed. We go with the latter for now.
This avoids the use of a variable length array, which should probably
be avoided in general due to potential performance, portability and
security issues (not in this particular case, though).
Closesstrongswan/strongswan#1095
GCC assumes this->b is zero (or may be zero) and spits out the following
warning (or error with -Werror):
src/libstrongswan/plugins/fips_prf/fips_prf.c:124:12: error: array subscript 18446744073709551615 is above array bounds of ‘uint8_t[<U8090>]’ {aka ‘unsigned char[<U8090>]’} [-Werror=array-bounds]
124 | one[this->b - 1] = 0x01;
| ~~~^~~~~~~~~~~~~
More of this code was already removed with previous commits.
While versions < 1.1.1 are not officially supported anymore, 1.0.2 might
still be in use because before 3.x that was the latest version with
official FIPS support (OpenSSL apparently also provides extended commercial
support for it).
The old API has been deprecated with OpenSSL 3 and direct access to the
state isn't possible via EVP API. In the future we might just remove this
implementation but we'd probably have to implement EAP-AKA' first, which
uses HMAC-SHA-256 with IKEv2's prf+ construct to derive keys instead
of this weird construct (plus what fips-prf builds around it) that's used
by EAP-AKA.
Tobias Brunner