Before TLS 1.3, the server sent the last handshake message and had the
option to piggyback the EAP-Identity request directly onto the packet
with the TLS Finished message, or wait for the empty message by the
client that acknowledges the completion of the handshake. With TLS 1.3,
the client finishes the handshake after the server. So this option
is irrelevant there and we immediately start with Phase 2.
Since these might conflict with IKE traffic, this requires special care.
One option is to install bypass policies for the peer, which install
appropriate (throw) routes. However, that won't work if the traffic to
the gateway itself should be protected, in particular, for host-to-host
tunnels. So an alternative is to set a mark for the IKE socket and then
exclude that traffic from table 220 via the kernel-netlink plugin's
fwmark option.
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.
The resolvconf implementation provided by systemd via resolvectl strips
everything after the interface name, so each additional server that's
installed replaces the previous one. And even for other resolvconf
implementations installing them individually doesn't seem necessary as
we track and refcount them anyway.
Closesstrongswan/strongswan#1353
Newer releases of systemd contain a change that removes not the part
after the first dot but the part after the last when determining the
interface name (apparently some interface names actually contain a dot).
This changes the default prefix to only contain one dot and avoids the
dots added by IPv4 addresses to create a unique interface/protocol for
each DNS server (it also replaces the `:` in IPv6 addresses with
something that might cause less conflicts).
References strongswan/strongswan#1353
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).
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
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
The default MTU of 1500 is too high if kernel-libipsec is used (considering
the overhead of UDP-encapsulated ESP), but might also have an effect if
a TUN device is only used to install a virtual IP (the route points to it,
so the system might use its MTU and 1500 would still be too high).
This also works around an issue on macOS 12 where no RTM_IFINFO event
is sent for the newly created TUN device (neither for the creation,
setting it "up", nor adding the address). Changing the MTU, however,
triggers such an event and we can detect the virtual IP.
Closesstrongswan/strongswan#707
The main fixes are
* the generation of fingerprints for RSA, ECDSA, and EdDSA
* the encoding of ECDSA private keys
* calculating p and q for RSA private keys
* deriving the public key for raw Ed25519 private keys
Also, instead of numeric literals for buffer lengths ASN.1 related
constants are used.
The client identifier serves as unique identifier just like a unique MAC
address would, so even with identity_leases disabled some DHCP servers
might assign unique leases per identity.
With IKEv1 we transmit both public DH factors (used to derive the initial
IV) besides the shared secret. So these messages could get significantly
larger than 1024 bytes, depending on the DH group (modp2048 just about
fits into it). The new default of 2048 bytes should be fine up to modp4096
and for larger groups the buffer size may be increased (an error is
logged should this happen).
This can be useful if routing rules (instead of e.g. route metrics) are used
to switch from one to another interface (i.e. from one to another
routing table). Since we currently don't evaluate routing rules when
doing the route lookup this is only useful if the kernel-based route
lookup is used.
Resolvesstrongswan/strongswan#88.
If enabled, add the RADIUS Class attributes received in Access-Accept messages
to RADIUS accounting messages as suggested by RFC 2865 section 5.25.
Fixes#2451.
