This fixes issues with CHILD_SAs getting reestablished concurrently.
We intend to reuse the reqid of the previous CHILD_SA, however, previously
the reqids were released and up for reassignment to any other CHILD_SA
or trap policy. This could cause the reqid to get associated with
completely different traffic selectors, as the reestablished CHILD_SA
would eventually get the requested reqid because the traffic selectors
explicitly don't have to match (to allow narrowing for CHILD_SAs based
on trap policies).
Closesstrongswan/strongswan#1855
Maintaining the reqid when recreating a CHILD_SA from scratch night not
strictly be necessary as we usually don't have to replace any temporary
states in the kernel. However, there could be concurrent acquires that
might actually make it necessary (we use the reqid to keep track of
acquires and it's also part of the duplicate check).
Keeping a reference ensures that if the old SA expires before the new
one is installed, the previous reqid isn't reallocated to a concurrently
established CHILD_SA with different selectors.
The reference is kept until the reqid is either confirmed (i.e.
re-allocated) or replaced by a different reqid, which happens only once
we know the final traffic selectors, or the SA is destroyed without
installing it.
Every reqid is allocated once, we don't store the same reqid with e.g.
different marks or interface IDs that would make it necessary to make
them part of the key in that table (that's different in the other table).
To preserve the current behavior, that is, allocating a new reqid if e.g.
the marks are different, the additional selector values (which will
result in an additional policy in the Linux kernel) are compared after
the initial lookup.
This allows preventing peers from authenticating with certificates
that are locally trusted, in particular, our own local certificate (which
safeguards against accidental reuse of certificates on multiple peers).
On the other hand, if this option is enabled, end-entity certificates
for peers can't be configured anymore explicitly (e.g. via remote.certs
in swanctl.conf).
If we initially selected a group the peer doesn't support (e.g. because
curve25519 is the first ECDH group provided by plugins), then found
a supported curve, we previously still instantiated a DH object for the
original group and might have formatted the parameters incorrectly.
Since the referenced commit, the state switch to IKE_ESTABLISHED doesn't
happen immediately after completing the authentication but only after
the remaining tasks have finished. Due to that redirects during IKE_AUTH
were treated like those during IKE_SA_INIT causing the IKE_SA and task
manager to get reset. However, unlike the ike-init task, the ike-auth
task returned SUCCESS and, therefore, got destroyed, while a different
task was removed from the array that was modified during the reset.
This later caused a dereference of the freed ike-auth task and a crash.
Fixes: 5ce1c91b58a2 ("ikev2: Trigger ike_updown() event after all IKE-specific tasks ran")
There is a relatively recent NIAP requirement to reject certificates with
ECDSA keys that explicitly encode the curve parameters (TD0527, Test 8b).
Since explicit encoding is pretty rare (if used at all and e.g. wolfSSL
already rejects it, by default), we should follow that requirement and
just reject such keys/certificates completely.
This currently can be enforced in all crypto plugins except when using
older versions of OpenSSL (< 1.1.1h) and Botan (< 3.2.0).
Closesstrongswan/strongswan#1949
References strongswan/strongswan#1796
These are not allowed in X.509 certificates according to RFC 5480 and
some newer validations apparently explicitly check for this.
Note that WolfSSL rejects such keys, by default. Only when compiled with
WOLFSSL_NO_ASN_STRICT are they accepted.
The cert-enroll script handles the initial enrollment of an X.509
host certificate with a PKI server via the EST or SCEP protocols.
Run as a systemd timer or via a crontab entry the script daily
checks the expiration date of the host certificate. When a given
deadline is reached, the host certificate is automatically renewed
via EST or SCEP re-enrollment based on the possession of the old
private key and the matching certificate.
This works around an issue that occurs when recreating an IKE_SA with
multiple CHILD_SAs that use dynamically allocated reqids.
We currently try to preserve the reqid when reestablishing, so the
create-child task gets the reqid of the previous CHILD_SA and will try
to reallocate that once the CHILD_SA is installed. Before that, the old
CHILD_SA is destroyed and the reqid is released and added to the array
of reqids to get reused. However, because of the reverse order used here,
the first reqid in the array is the one of the last CHILD_SA.
So it can happen that a newly created CHILD_SA gets a reqid reassigned
that a later CHILD_SA will then also claim for itself and get assigned
because an entry with that reqid exists. So multiple CHILD_SAs with
different traffic selectors could then share the same reqid.
References strongswan/strongswan#1855
Fixes a problem installing policies with source traffic selectors that do
not contain/match any of the local addresses.
When installing a route for a source TS that does contain one or more
local addresses, a preferred source address should be set in the route
(analogous to the `src` option in `ip route add`). This address is used
when the host itself sends traffic via that route (in contrast to
forwarding it).
When the source TS does not encompass any of the local addresses, the
host is not allowed to send traffic via this route and does not need to
set the preferred source address. However, the code would just return a
failure because it could not find a matching local address. This commit
changes this so routes without preferred source IP are installed to
allow non-local traffic to get forwarded via TUN device.
Closesstrongswan/strongswan#1766
This commit fixes auto detection of in6_pktinfo.
When negotiating an IPv6 IKE session charon reported an error
"Jun 30 16:42:49 03[NET] error reading IP header"
The cause of error was missing in6_pktinfo declaration, which is
auto detected. This auto detection may fail with an error depending
on compiler flags:
configure:19850: checking for in6_pktinfo
configure:19870: gcc -c -g -O0 -Wall -Wno-format -Wno-format-security
-Wno-pointer-sign -Werror -Wfatal-errors -Wno-error=stringop-truncation
conftest.c >&5
conftest.c: In function 'main':
conftest.c:73:11: error: 'pi.ipi6_ifindex' is used uninitialized in this
function [-Werror=uninitialized]
73 | if (pi.ipi6_ifindex)
| ~~^~~~~~~~~~~~~
compilation terminated due to -Wfatal-errors.
cc1: all warnings being treated as errors
Signed-off-by: Antony Antony <antony.antony@secunet.com>
socket.connect() takes a single argument with the address that depends
on the address family, for TCP it's a tuple with IP and port.
Fixes: 00a75e332f29 ("vici: Create default TCP socket on Windows in Python bindings")
Closesstrongswan/strongswan#1874
Note that displaying the notification for the background service is
apparently not strictly necessary. So it's fine if the user wants to
hide it. That the service is running can still be seen in the task
manager (pull down the status drawer twice, there is a bullet with a number
at the bottom if the service is running).
Simply use the system dialog. If the user denies it twice, it won't show
up again. The explanation dialog would not show up the first time (i.e.
shouldShowRequestPermissionRationale() returns false), only once the user
denied the permission once. Currently seems like a bit much work
as we don't need the user to allow notifications.
Particularly on Samsung devices, the connect() call to dissolve the
previous connection on an existing socket via AF_UNSPEC does fail in
some situations with ECONNREFUSED:
[KNL] failed to disconnect socket: Connection refused
While creating a new socket is potentially a bit more overhead, this
should avoid the issue.
Closesstrongswan/strongswan#1691
When adding a virtual IP on a TUN interface, the interface might get
activated (in terms of receiving the event) after we've already set the
virtual flag for the added address. As the activation repopulates the
addresses on the interface, this cleared the flag and the address would
no longer be treated as virtual IP when installing routes for CHILD_SAs
that reference it in their local traffic selectors.
Closesstrongswan/strongswan#1807
Fixes an infinite loop if e.g. Netlink event sockets get too many
packets queued and poll() just returns POLLERR for the socket. Also
increases the default receive buffer size for Netlink sockets to better
support systems with lots of route updates.
Closesstrongswan/strongswan#1757
We can't actually explicitly listen for errors by passing POLLERR in
`events` (the man page for poll() clearly states it's ignored). On the
other hand, POLLERR can be returned for any FD and, even worse, it might
be the only event indicated.
The latter caused an infinite loop as we didn't notify the callback nor
clear the error by calling `getsockopt(..., SOL_SOCKET, SO_ERROR, ...)`.
And while the latter would be able to reset the state to break the loop,
it seems to leave the FD in a defunct state where no further events will
be returned by poll(). Notifying the callback works better (the error
is then reported by e.g. recvfrom()) and automatically happened already
if POLLERR was returned together with e.g. POLLIN.
So we now treat POLLERR like the other error indicators we handle (POLLHUP
and POLLINVAL) and just notify the callbacks.
Also simplify how we try to exceed the system-wide maximum. We basically
just try to force the value and simply fall back to the regular call.
The kernel actually won't let the latter fail if the value is too big,
it just caps it at the internal maximum.
