Such routes with a gateway that equals the peer's address are problematic
on FreeBSD. And since there is most likely a narrow route for the local
subnet anyway, the exclude routes would be redundant.
When installing routes based on remote traffic selectors, it can be
necessary to install an exclude route for the remote peer to avoid a
routing loop and continue to be able to reach it via IKE/ESP.
However, such routes are only necessary, if the routes we install don't
go via outbound interface. That's the case when using VIPs and routing
via TUN devices, or when using internal source IPs and routing via
their interfaces.
Installing such exclude routes if not necessary can cause issues on
FreeBSD (EINVAL when sending packets to the peer).
There is a conflict between atexit() handlers registered by OpenSSL and
some executables (e.g. swanctl or pki) to deinitialize libstrongswan.
Because plugins are usually loaded after atexit() has been called, the
handler registered by OpenSSL will run before our handler. So when the
latter destroys the plugins it's a bad idea to try to access any OpenSSL
objects as they might already be invalid.
Fixes: f556fce16b ("openssl: Load "legacy" provider in OpenSSL 3 for algorithms like MD4, DES etc.")
Closesstrongswan/strongswan#921
has_subject() already matches the identity against the subject DN and
all the SANs (it actually already did when this check was added with
c811479986 ("Strictly check if the server certificate matches the TLS
server identity")).
The client already enforces that the server identity is contained in the
received certificate. But on the server, the referenced commit changed
the lookup from the configured (or adopted if %any was configured) client
identity to the subject DN of the received client certificate. So any
client with a trusted certificate was accepted.
Fixes: d2fc9b0961 ("tls-server: Mutual authentication support for TLS 1.3")
Closesstrongswan/strongswan#873
This can happen if an IKE_SA is initiated to a static IP before DHCP is
done. Instead of failing the initiation, we either fake a NAT situation
(for IPv4) or disable NAT-D (for IPv6 where NATs and UDP-encap are not
widely used or supported).
This also removes the old fallbacks to determine the source address(es).
A source address lookup is done in ike_sa_t::resolve_hosts() (wasn't the
case initially) and enumerating local IPs (which was added even earlier)
could still lead to issues if e.g. LAN addresses are available but the
WAN address that's later used is not yet (in which case only the responder
would detect a NAT and UDP-encap would be configured asymmetrically).
To force UDP-encap locally in case there is no actual NAT, we store this
as COND_NAT_HERE instead of COND_NAT_FAKE. This ensures DPDs will contain
NAT-D notifies and we can later remove the state via MOBIKE. We trigger
a MOBIKE update after such a DPD by registering a changed NAT mapping after
checking for a disappearing local NAT, which is very unlikely to happen
outside of a MOBIKE update (where that flag is not checked).
The commit mentioned below adds an AES-GCM default proposal for ESP. That
proposal does not include any ESN or non-ESN transform to indicate if
extended sequence numbers are supported.
A standards-compliant peer will include one or more ESN support transforms,
and will be unable to select this proposal due to a proposal mismatch.
Fix the default AES-GCM proposal by adding a NO_ESN algorithm. While ESN has
been supported in the Linux kernel for a while, having it in the default
proposal can be problematic with kernel-libipsec or on other platforms.
Fixes: c7bef954ee ("proposal: Add AES-GCM to the ESP default AEAD proposal")
Closesstrongswan/strongswan#868
strongSwan logs all syslog messages using LOG_INFO for historical reasons,
regardless of the strongSwan loglevel used producing the log message.
In some setups with advanced logging infrastructure, it may be feasible
to be more verbose when logging in strongSwan, but then filter messages
on the syslog server. While this may be possible by custom syslog filtering
rules matching the log level included with the log_level setting, this is
not super convenient.
So add a new map_level setting, which can map strongSwan loglevels to
syslog loglevels. By default this is disabled, keeping the existing
behavior. If enabled, it maps strongSwan loglevels to syslog loglevels
at a given syslog loglevel offset.
Closesstrongswan/strongswan#859
RFC3779 requires to validate the addrblocks of issuer certificates strictly,
that is, they must contain the extension and the claimed addrblock, up to
the root CA.
When working with third party root CAs that do not have the extension,
this makes using the plugin impossible. So add a depth setting that limits
the number of issuer certificates to check bottom-up towards the root CA.
A depth value of 0 disables any issuer check, the default value of -1
checks all issuers in the chain, keeping the existing behavior.
Closesstrongswan/strongswan#860
Without this, the authentication succeeded if the server sent an early
EAP-Success message for mutual, key-generating EAP methods like EAP-TLS,
which may be used in EAP-only scenarios but would complete without server
or client authentication. For clients configured for such EAP-only
scenarios, a rogue server could capture traffic after the tunnel is
established or even access hosts behind the client. For non-mutual EAP
methods, public key server authentication has been enforced for a while.
A server previously could also crash a client by sending an EAP-Success
immediately without initiating an actual EAP method.
Fixes: 0706c39cda ("added support for EAP methods not establishing an MSK")
Fixes: CVE-2021-45079
The logrotate function causes the apt history to be split into
several parts at arbitrary points in time. If history.log only
is parsed then some package installation changes stored in
zipped backup history files might get lost.
Thus sw-collector now searches all backup history files until
a date older than the current event stored in the collector.db
database is found, so that no entries get overlooked.
Using the trusted RSA or ECC Endorsement Key of the TPM 2.0 a
secure session is established via RSA public key encryption or
an ephemeral ECDH key exchange, respectively.
The session allows HMAC-based authenticated communication with
the TPM 2.0 and the exchanged parameters can be encrypted where
necessary to guarantee confidentiality.
We still require these algorithms for e.g. EAP-MSCHAPv2, so the option is
enabled, by default. To use other providers (e.g. fips or even custom
ones), the option can be disabled and the providers to load/activate can
be configured in openssl.cnf. For instance, the following has the same
effect as enabling the option:
openssl_conf = openssl_init
[openssl_init]
providers = providers
[providers]
default = activate
legacy = activate
[activate]
activate = yes
Determined by whether the library provides curves for it or not.
For instance, in the OpenSSL 3 FIPS provider the Brainpool curves are
not included. And in the Fedora package several weak curves are
explicitly patched out and the Brainpool curves are omitted even in
non-FIPS mode.
In particular as server, the previous code might cause it to hang in
recv() if this case wasn't triggered by a close notify (followed by a
shutdown of the socket) but it e.g. failed processing a ServerHello and
responded with a fatal alert.
Fixes: 09fbaad6bd ("tls-socket: Don't fail reading if sending data failed")
This is useful for kernel implementations where the ordering of SAs
is unpredictable and the new SA might otherwise not be used until the
DELETE response has been received, which is not ideal as the responder
might not keep the old SA around that long. On Linux, it makes no
difference as we switch to the new outbound SA immediately because the
updated outbound policy references its SPI.
This way we can run many unit tests without having to run the TKM in the
background and as regular user. To run the other tests, TESTS_TKM can
optionally be defined when running `make check`.
Tobias Brunner