Depending on the configured hard lifetime the default soft lifetime
might not make sense and could even cause rekeying to get disabled.
To avoid that, derive the soft lifetime from the hard lifetime so it's
10% higher than the soft lifetime.
References strongswan/strongswan#1414
Also avoid returning 0 and disabling rekeying in the rare case of
`jitter = rekey` and the `1/jitter` chance of that happening (returning
1 at least doesn't disable rekeying).
Co-authored-by: Tobias Brunner <tobias@strongswan.org>
Closesstrongswan/strongswan#1414
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.
Ubuntu 22.04 ships OpenSSL 3, which requires debug symbols so we can
whitelist leaks because we don't deinitialize the library. And because
the shipped library is not built with `-fno-omit-frame-pointer`, the
build with AddressSanitizer can't use its fast stack unwind method.
However, the previous workaround for DTLS handling with glibc apparently
isn't necessary anymore.
In the custom OpenSSL build we drop no-stdio as that lets the configure
check for libldns fail because ERR_print_errors_fp@OPENSSL_3.0.0 is not
found.
For ccache, the default path to the cache directory has changed.
Also simplified the NM tests as there is only one build since
085daf474330 ("nm: Remove old libnm-glib compat stuff").
At least since Ubuntu 22.04 there are lots of (apparently non-fatal)
"DWARF error: could not find variable specification" errors generated
by bfd_find_nearest_line(). This also happens with addr2line, which
internally uses libbfd. No idea what the actual issue is (it still
happens with binutils 2.39 in Ubuntu 22.10), but since it doesn't seem
to affect the functionality we need this avoids filling the test logs
with useless messages.
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
A recent change added CALLBACK to PENUM_PAGE_FILE_CALLBACKW/A in psapi.h,
which conflicts with our own macro of the same name. Our compat/windows.h
header undefs the Windows definition, but that only works if Windows
headers are included before ours, which wasn't the case for psapi.h.
This avoids a conflicts as mysql80-client has a dependency on either
openldap24-client (FreeBSD 12) or openldap26-client (FreeBSD 13) so e.g.
installing openldap24-client on FreeBSD 13 causes
openldap26-client-2.6.3 conflicts with openldap24-client-2.4.59_4 on /usr/local/bin/ldapadd
Similarly, when installing openldap26-client on FreeBSD 12. So just let
the mysql80-client package decide which version is installed.
There are spurious crashes after test runs (during the reporting phase
of LeakSanitizer) that are triggered by seemingly unrelated code changes.
It seems to be related to how glibc handles dynamic TLS allocations.
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).
This avoids querying URLs of potentially untrusted certificates, e.g. if
an attacker sends a specially crafted end-entity and intermediate CA
certificate with a CDP that points to a server that completes the
TCP handshake but then does not send any further data, which will block
the fetcher thread (depending on the plugin) for as long as the default
timeout for TCP. Doing that multiple times will block all worker threads,
leading to a DoS attack.
The logging during the certificate verification obviously changes. The
following example shows the output of `pki --verify` for the current
strongswan.org certificate:
new:
using certificate "CN=www.strongswan.org"
using trusted intermediate ca certificate "C=US, O=Let's Encrypt, CN=R3"
using trusted ca certificate "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
reached self-signed root ca with a path length of 1
checking certificate status of "CN=www.strongswan.org"
requesting ocsp status from 'http://r3.o.lencr.org' ...
ocsp response correctly signed by "C=US, O=Let's Encrypt, CN=R3"
ocsp response is valid: until Jul 27 12:59:58 2022
certificate status is good
checking certificate status of "C=US, O=Let's Encrypt, CN=R3"
ocsp response verification failed, no signer certificate 'C=US, O=Let's Encrypt, CN=R3' found
fetching crl from 'http://x1.c.lencr.org/' ...
using trusted certificate "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
crl correctly signed by "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
crl is valid: until Apr 18 01:59:59 2023
certificate status is good
certificate trusted, lifetimes valid, certificate not revoked
old:
using certificate "CN=www.strongswan.org"
using trusted intermediate ca certificate "C=US, O=Let's Encrypt, CN=R3"
checking certificate status of "CN=www.strongswan.org"
requesting ocsp status from 'http://r3.o.lencr.org' ...
ocsp response correctly signed by "C=US, O=Let's Encrypt, CN=R3"
ocsp response is valid: until Jul 27 12:59:58 2022
certificate status is good
using trusted ca certificate "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
checking certificate status of "C=US, O=Let's Encrypt, CN=R3"
ocsp response verification failed, no signer certificate 'C=US, O=Let's Encrypt, CN=R3' found
fetching crl from 'http://x1.c.lencr.org/' ...
using trusted certificate "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
crl correctly signed by "C=US, O=Internet Security Research Group, CN=ISRG Root X1"
crl is valid: until Apr 18 01:59:59 2023
certificate status is good
reached self-signed root ca with a path length of 1
certificate trusted, lifetimes valid, certificate not revoked
Note that this also fixes an issue with the previous dual-use of the
`trusted` flag. It not only indicated whether the chain is trusted but
also whether the current issuer is the root anchor (the corresponding
flag in the `cert_validator_t` interface is called `anchor`). This was
a problem when building multi-level trust chains for pre-trusted
end-entity certificates (i.e. where `trusted` is TRUE from the start).
This caused the main loop to get aborted after the first intermediate CA
certificate and the mentioned `anchor` flag wasn't correct in any calls
to `cert_validator_t` implementations.
Fixes: CVE-2022-40617
