This could be problematic in case loggers in some way rely on watcher_t
themselves. This particular log message should rarely occur if at all,
but still avoid holding the mutex.
For the legacy schemes with rsaEncryption nothing changes, but if an
actual signature scheme is encoded we use that to find the key and
verify the signature.
The descriptions for the PKCS#7 structure are adapted for CMS.
Some encoders, like those provided by the dnskey and sshkey plugins,
require these separately when encoding keys.
Also fixes the type for the ASN.1 encoding (which is a subjectPublicKeyInfo
structure) depending on the key type. This worked fine for PEM encoding
as the pem plugin doesn't care what the actual type of the key is (which
is encoded in the SPKI structure), but other plugins do (e.g. the sshkey
plugin).
We don't have any information on the issuer of cached OCSP responses, in
particular if the OCSP response is issued by a dedicated OCSP signer,
whose certificate might not be contained in the response or even signed
by the same CA but could just be locally installed. So the only way to
determine if a response applies to the current certificate and its CA
is searching for the response's issuer certificate and verifying that.
However, when using multiple CAs that provide revocation checking via
OCSP, in particular with multi-level CAs (e.g. like the
ikev2-multi-ca/ocsp-signers test scenario), we might have unrelated OCSP
responses in the cache when verifying a particular certificate. In this
case we don't need any confusing
ocsp response verification failed, no signer certificate '...' found
error messages because the response was for a different CA.
Similarly, if lots of clients of the same CA connect there could be lots
of OCSP responses in the cache that, while being applicable to the current
CA, don't have any information on the certificate we are currently
checking. In this case all the
ocsp response correctly signed by "..."
ocsp response contains no status on our certificate
messages don't provide any value.
In the mentioned test scenario, we suppress the
ocsp response verification failed, no signer certificate 'C=CH, O=strongSwan Project, OU=Research OCSP Signing Authority, CN=ocsp.research.strongswan.org' found
message from the cached OCSP response for carol's end-entity certificate
when verifying the "Research" intermediate CA certificate that issued
carol's certificate.
Then the
ocsp response verification failed, no signer certificate 'C=CH, O=strongSwan Project, OU=Research OCSP Signing Authority, CN=ocsp.research.strongswan.org' found
ocsp response verification failed, no signer certificate 'C=CH, O=strongSwan Project, OU=OCSP Signing Authority, CN=ocsp.strongswan.org' found
messages from the cached OCSP responses for carol's end-entity and
intermediate CA certificates when verifying dave's end-entity certificate.
And finally the
ocsp response verification failed, no signer certificate 'C=CH, O=strongSwan Project, OU=Research OCSP Signing Authority, CN=ocsp.research.strongswan.org' found
ocsp response correctly signed by "C=CH, O=strongSwan Project, OU=OCSP Signing Authority, CN=ocsp.strongswan.org"
ocsp response contains no status on our certificate
ocsp response verification failed, no signer certificate 'C=CH, O=strongSwan Project, OU=Sales OCSP Signing Authority, CN=ocsp.sales.strongswan.org' found
messages from the cached OCSP responses for carol's end-entity
certificate, the applicable but unrelated response for carol's "Research"
intermediate CA certificate and the response for dave's end-entity
certificate when verifying dave's "Sales" intermediate CA.
When running as a service, the libraries are initialized/deinitialized
not by the main thread but by a separate thread that runs the registered
main service procedure. When the service is stopped, the libraries are
deinitialized by that thread and the thread lock and hashtable are
destroyed. But afterwards the DllMain callback is also triggered for
that thread so we have to prevent it from accessing these objects again.
References strongswan/strongswan#1567
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.
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.
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
This forces the use of a semicolon after INIT() and makes existing ones,
which was the case for basically all instances, necessary so e.g.
sonarcloud won't complain about an empty statement after every one of
them.
By evaluating to the allocated object, it would theoretically also allow
constructs like this:
struct_t *this;
return INIT(this,
.a = x,
.b = y,
);
or this:
array_insert(a, ARRAY_TAIL, INIT(this,
.a = x,
.b = y,
));
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
Only the second was reported by the compiler (depending on the version
and similarly to the previous commit only with AddressSanitizer active).
The strncpy() call for UTUN_CONTROL_NAME was simply wrong.
Tobias Brunner