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).
Some third party IKEv2 products expect an RSA-PSS ASN.1
algorithmIdentifier with an explicit trailerField value (CONTEXT3)
instead of the DEFAULT value if the trailerField is missing.
The setting charon.rsa_pss_trailerfield = yes enables the explicit
encoding.
These only apply to the usage reports that are available via
`stroke memusage`, not to leak reports when executables are terminated,
which always include all non-whitelisted leaks.
This should make the DoS limits (cookie_threshold[_ip] and block_threshold)
more accurate so that it won't be possible to create lots of jobs from
spoofed IP addresses before half-open IKE_SAs are actually created from
these jobs to enforce those limits.
Note that retransmits are tracked as half-open SAs until they are
processed/dismissed as the check only happens in checkout_by_message().
Increasing the count in process_message_job_create() avoids issues with
missing calls to track_init() before calling checkout_by_message() (e.g.
when processing fragmented IKEv1 messages, which are reinjected via a
process message job).
Because the global cookie threshold is higher than the per-IP block
threshold, it was previously possible for an attacker to block a legitimate
user by sending spoofed IKE_SA_INIT packets from that user's IP.
The timespan for requiring cookies is now also not extended anymore with
every IKE_SA_INIT received during the calm down period. Because this
allowed an attacker, after initially triggering the global cookie threshold,
to force cookies for all clients by sending just a single spoofed
IKE_SA_INIT every 10 seconds.
We keep track of reaching the per-IP threshold in segments of the hashed
IP addresses, so only a (random, due to chunk_hash()'s random key) subset
of clients will receive cookies, if single IPs are targeted.
The default global threshold is increased a bit.
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
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
Usually, the DNs of all loaded CA certificates are included in the
CertificateRequest messages sent by the server.
Alas, certain EAP-TLS clients fail to process this message if the
list is too long, returning the fatal TLS alert 'illegal parameter'.
This new option allows configuring whether CAs are included or an
empty list is sent (TLS 1.2), or the certificate_authorities extension
is omitted (TLS 1.3). The list only serves as hint/constraint
for clients during certificate selection, they still have to provide
a certificate but are free to select any one they have available.
Closesstrongswan/strongswan#187.
A new global option enables sending this vendor ID to prevent Cisco
devices from narrowing the initiator's local traffic selector to the
requested virtual IP, so e.g. 0.0.0.0/0 can be used instead.
This has been tested with a "tunnel mode ipsec ipv4" Cisco template but
should also work for GRE encapsulation.
Closesstrongswan/strongswan#180.
This is useful on Android where the app might not be able to send
keep-alives if the device is asleep for a while. If the NAT mapping
has been deleted in the mean time, the NAT-D payloads allow detecting
this and connectivity can be restored by doing a MOBIKE update or
recreating the SA if the peer already deleted it because the client
wasn't reachable.
Some peers apparently don't send the notify and still expect to
authenticate with EAP-only authentication. This option allows forcing
the configured use of EAP-only authentication in that scenario.
Charon refuses to make use of algorithms IDs from the private space
for unknown peer implementations [1]. If you chose to ignore and violate
that section of the RFC since you *know* your peers *must* support those
private IDs, there's no way to disable that behavior.
With this commit a strongswan.conf option is introduced which allows to
deliberately ignore parts of section 3.12 from the standard.
[1] http://tools.ietf.org/html/rfc7296#section-3.12
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
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.
Might be useful for users of other daemons too. Note that compared to the
previous implementation in charon-tkm, the mask/label are applied in
network order.
Closesstrongswan/strongswan#134.
