Andreas Steffen [Mon, 4 Nov 2019 21:22:47 +0000 (22:22 +0100)]
key-exchange: Joint ke_test_vector format for DH and KEM
Both Diffie-Hellman (DH) and Key Encapsulation Mechanism (KEM) based
key exchange methods use a common ke_test_vector format. The
set_seed() function is used to provide deterministic private key
material for the crypto tests.
unit-tests: Ensure listeners can track SAs via ike/child_updown/rekey()
Previously, it could happen that child_rekey() was triggered twice for
the same "old" SA. For listeners that would mean they'd loose track as
they'd be tracking a new SA that wasn't relevant anymore and for which
no updown event would ever get triggered (it was the redundant SA in a
collision). This new assert ensures that events are triggered in a
predictable way and listeners can track SAs properly.
Tobias Brunner [Mon, 22 Aug 2022 13:43:16 +0000 (15:43 +0200)]
ikev2: Make CHILD_SAs properly trackable during rekey collisions
As the winner of a rekey collision, we previously always triggered the
child_rekey() event once when creating the redundant SA on behalf of the
peer in the passive child-rekey task and then a second time when
creating the winning SA in the active task. However, both calls passed
the replaced CHILD_SA as "old". This made tracking CHILD_SAs impossible
because there was no transition from the redundant, "new" SA of the
first event to the "new", winning SA of the second. Of course, when the
second event was triggered, the redundant SA might not have existed
anymore because the peer is expected to delete it, which could happen
before the CREATE_CHILD_SA response arrives at the initiator.
This refactoring ensures that the child_rekey() event is triggered in
a way that makes the CHILD_SAs trackable in all reasonable (and even
some unreasonable) scenarios. The event is generally only triggered
once after installing the outbound SA for the new/winning CHILD_SA.
This can be when processing the CREATE_CHILD_SA in the active child-rekey
task, or when processing the DELETE for the old SA in a passive
child-delete task. There are some cases where the event is still
triggered twice, but it is now ensured that listeners can properly
transition to the winning SA.
Some corner cases are now also handled correctly, e.g. if a responder's
DELETE for the new CHILD_SA arrives before its CREATE_CHILD_SA response
that actually creates it on the initiator. Also handled properly are
responders of rekeyings that incorrectly send a DELETE for the old
CHILD_SA (previously this caused both, the new and the old SA, to get
deleted).
Tobias Brunner [Thu, 25 Jun 2020 08:26:38 +0000 (10:26 +0200)]
child-create: Add support for multiple key exchanges
It also changes that payloads are built before installing the CHILD_SA on
the responder, that is, the KE payload is generated before keys are derived,
so that key_exchange_t::get_public_key() is called before get_shared_secret(),
or it's internal equivalent, which could be relevant for KE implementations
that want to ensure that the key can't be used again after the key
derivation.
Tobias Brunner [Thu, 31 Oct 2019 16:16:44 +0000 (17:16 +0100)]
ike-init: Add support for multiple key exchanges
Initially, this is handled with a key derivation for each
IKE_INTERMEDIATE exchange. When rekeying the keys are derived only when
all IKE_FOLLOWUP_KE exchanges are done.
Tobias Brunner [Tue, 20 Aug 2019 15:07:55 +0000 (17:07 +0200)]
ike-auth: Calculate and collect IntAuth for IKE_INTERMEDIATE exchanges
The message ID of the first IKE_AUTH exchange is a safe-guard against
potential truncation attacks if IKE_INTERMEDIATE exchanges are not used
for multiple key exchanges but some other future use where the number of
exchanges might not depend on the selected proposal.
Tobias Brunner [Tue, 8 Feb 2022 13:23:37 +0000 (14:23 +0100)]
ikev2: Reject IKE_INTERMEDIATE requests after IKE_AUTH
We currently only support these exchanges for additional key exchanges,
so once we have the final keys derived and the ike-init task is removed,
we don't expect any more of them.
revocation: Enforce a (configurable) timeout when fetching OCSP/CRL
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).
credential-manager: Do online revocation checks only after basic trust chain validation
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.
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,
));
github: Prefer third-party crypto lib's implementations over ours
If e.g. the hmac plugin is loaded before the third-party crypto lib
plugin, we might not use the latter's HMAC implementation in some
cases (e.g. in the libtls tests).
ikev2: Trigger ike_updown() event after all IKE-specific tasks ran
This makes sure the event is only triggered after the IKE_SA is fully
established and e.g. virtual IPs, additional peer addresses or
a modified reauth time (on the initiator) are assigned to it. This was
e.g. a problem for the selinux plugin if virtual IPs are used.
We use a separate task to trigger the event that's queued before the
child-create task so the event is triggered before the child_updown()
event. Same goes for the state change to IKE_ESTABLISHED.
A new condition is used to indicate the successful completion of all
authentication rounds, so we don't have to set the IKE_ESTABLISHED state
in the ike-auth task (it was used as condition in other tasks).
Since set_state() also sets the rekey and reauth times, this required
some minor changes in regards to how AUTH_LIFETIME notifies are handled.
ikev2: The ike-me task does not have to run before the ike-auth task
Since e334bd46b184 ("ike-auth: Move packet collection to post_build()
method") tasks and plugins can modify the IKE_SA_INIT message independent
of the ike-auth task.
socket-default: Use IPv6-only mode for IPv6 sockets
Otherwise, we can't open a dedicated IPv4 socket on the same port as the
IPv6 socket already is set up do receive IPv4 packets (unless we'd again
enable SO_REUSEADDR).
Fixes: 83da13371292 ("socket-default: Don't set SO_REUSEADDR on IKE sockets anymore")
The default is apparently "Connection: keep-alive", which somehow keeps
the socket around, which leaks file descriptors with every connection
that fetches OCSP and/or CRLs. Over time that could result in the number
of FDs reaching a limit e.g. imposed by FD_SET().
projects / thirdparty / strongswan.git / log
