Adds support for multiple OCSP responders in `pki --ocsp` and one that
is based on OpenSSL-style index.txt files. The parser for these files
also accepts simplified files that only specify the status, serial number
and optional revocation date/reason. The OCSP test scenarios are also
updated to use this OCSP responder including one that shows the multi-CA
capabilities of the --ocsp command and the --index option.
The only exception is the ikev2/ocsp-no-signer-cert scenario as the
pki command won't sign an OCSP response with a certificate that isn't
the CA certificate or marked as an OCSP signer.
Registered OCSP responders should return VALIDATION_SKIPPED for issuer
certificates they are not responsible for. However, VALIDATION_FAILED is
currently treated the same way, so that's fine as well.
Implements a new --ocsp command for the pki tool that can produce OCSP
responses based on information provided by a plugin. A first plugin
that accesses the OpenXPKI database is also added.
Closesstrongswan/strongswan#1958
The kernel includes the XFRMA_REPLAY_ESN_VAL attribute when dumping
SAs since it was added with 2.6.39. So we basically added this attribute
twice to the message sent to the kernel, potentially exceeding the
message buffer if the window size is large.
The XFRMA_REPLAY_VAL attribute is only dumped since 3.19, so that might
still be relevant (Google seems to maintain a 3.18 kernel) and since we
have to query the current lifetime stats anyway, we can just avoid adding
this attribute twice.
Closesstrongswan/strongswan#1967
Adds support to encode SANs of type uniformResourceIdentifier in
certificates. They currently don't have any use in strongSwan, but
might be required for other applications.
Closesstrongswan/strongswan#1983
Instead of just generating an authorityKeyIdentifier based on the
issuer's public key, this allows CA certificates to be issued by a
different tool that doesn't use a SHA-1 hash of the subjectPublicKey
for the subjectKeyIdentifier.
Closesstrongswan/strongswan#1992
References strongswan/strongswan#1975
This adds support for password-less PKCS#12 containers and PKCS#8 files.
A new option for charon-cmd also allows loading private keys of any
type (previously only RSA keys were supported).
References strongswan/strongswan#1955
Adds support for nameConstraints of type iPAddress, which represent a
subnet, to the x509, openssl and constraints plugins. SANs of type
iPAddress are matched against such constraints.
Closesstrongswan/strongswan#1991
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: 5ce1c91b58 ("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.
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
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: 00a75e332f ("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.
We track all IKE_SA_INIT requests as half-open IKE_SAs but didn't
correctly untrack them if their message ID or responder SPI was non-zero.
References strongswan/strongswan#1775
Fixes: b866ee88bf ("ike: Track unprocessed initial IKE messages like half-open IKE_SAs")
As specified in RFC 7296, section 2.25:
The SA that the initiator attempted to rekey is indicated by the SPI
field in the Notify payload, which is copied from the SPI field in
the REKEY_SA notification.
So we copy that and the protocol verbatim.
The get_spi_data() method is currently not used, so that has been
simplified so it can be used for any protocol type and any SPI length.
Same for set_spi_data(), which is currently used for IKEv1 to encode
two SPIs.
The created XFRM interface was not actually used (no interface IDs on the
SAs, no routes via interface). It was basically treated like the dummy
TUN device. To actually install the routes via XFRM interface, we have
to create it before we install the SAs and policies, signal_ip_config()
happens too late. We also have to mark the ESP packets the same as IKE
the packets to avoid a routing loop if the server's IP is included in
the remote traffic selector (in particular if it's 0.0.0.0/0 or ::/0).
Fixes: 58f278f932 ("charon-nm: Use an XFRM interface if available")
The all-zero Ed25519 public key is rejected by botan_pubkey_check_key()
when the key is loaded.
Note that Botan 3 requires GCC 11 or CLANG 14, i.e. can't easily be built
on Debian bullseye or Ubuntu 20.04.
The thread-local storage function gets flagged via various botan FFI
functions when using Botan 3, whitelist that instead of all of them.
The services running on alice seem to require a bit more memory with
Debian bookworm, so increase the memory allocation. But at the same
time reduce winnetou's allocation by the same amount as it really doesn't
require that much memory.
The unit change makes it easier to read.
Because do-tests runs the restore-defaults script, fstab would get reset
to the default version and the mount point wouldn't be available anymore
after stopping and restarting the guests (unless the guest images were
rebuilt in between).
By default, rsyslog is not installed anymore to avoid storing everything
twice (since journald is the default). If this becomes an issue, we
could delete /var/log/journal to only log via rsyslog.
System-wide installation via pip isn't easily possible anymore on Debian
bookworm, so just use the Debian package for this (is available in old
releases as well).
Because libcrypto and libssl are measured, we need a new group for Debian
versions with OpenSSL 3 (I've rather added a suffix to the old group as
that could eventually get removed, although we might need a 3.1 variant
in the future - maybe we should measure some other files?).
OOM-killer is now already triggered with `import daemon`, so set the
limit before that. Also some PEP8 fixes (including an exclusion for
the above fix as that causes imports to not be at the beginning of the
file).
Without this, Git refuses to operate on the build dirs that are mounted
with weird ownership. When running as root in the chroot, Git checks
SUDO_UID, which won't match.
This is necessary because TKM can't read PKCS#8 files and in some
scenarios we don't have the pkcs8 plugin loaded that would be required
to read/decrypt the non-traditional files.
Tobias Brunner