For the legacy schemes with rsaEncryption nothing changes, but if an
actual signature scheme is encoded we use that to find the key and
verify the signature.
The descriptions for the PKCS#7 structure are adapted for CMS.
Some encoders, like those provided by the dnskey and sshkey plugins,
require these separately when encoding keys.
Also fixes the type for the ASN.1 encoding (which is a subjectPublicKeyInfo
structure) depending on the key type. This worked fine for PEM encoding
as the pem plugin doesn't care what the actual type of the key is (which
is encoded in the SPKI structure), but other plugins do (e.g. the sshkey
plugin).
We don't have any information on the issuer of cached OCSP responses, in
particular if the OCSP response is issued by a dedicated OCSP signer,
whose certificate might not be contained in the response or even signed
by the same CA but could just be locally installed. So the only way to
determine if a response applies to the current certificate and its CA
is searching for the response's issuer certificate and verifying that.
However, when using multiple CAs that provide revocation checking via
OCSP, in particular with multi-level CAs (e.g. like the
ikev2-multi-ca/ocsp-signers test scenario), we might have unrelated OCSP
responses in the cache when verifying a particular certificate. In this
case we don't need any confusing
ocsp response verification failed, no signer certificate '...' found
error messages because the response was for a different CA.
Similarly, if lots of clients of the same CA connect there could be lots
of OCSP responses in the cache that, while being applicable to the current
CA, don't have any information on the certificate we are currently
checking. In this case all the
ocsp response correctly signed by "..."
ocsp response contains no status on our certificate
messages don't provide any value.
In the mentioned test scenario, we suppress the
ocsp response verification failed, no signer certificate 'C=CH, O=strongSwan Project, OU=Research OCSP Signing Authority, CN=ocsp.research.strongswan.org' found
message from the cached OCSP response for carol's end-entity certificate
when verifying the "Research" intermediate CA certificate that issued
carol's certificate.
Then the
ocsp response verification failed, no signer certificate 'C=CH, O=strongSwan Project, OU=Research OCSP Signing Authority, CN=ocsp.research.strongswan.org' found
ocsp response verification failed, no signer certificate 'C=CH, O=strongSwan Project, OU=OCSP Signing Authority, CN=ocsp.strongswan.org' found
messages from the cached OCSP responses for carol's end-entity and
intermediate CA certificates when verifying dave's end-entity certificate.
And finally the
ocsp response verification failed, no signer certificate 'C=CH, O=strongSwan Project, OU=Research OCSP Signing Authority, CN=ocsp.research.strongswan.org' found
ocsp response correctly signed by "C=CH, O=strongSwan Project, OU=OCSP Signing Authority, CN=ocsp.strongswan.org"
ocsp response contains no status on our certificate
ocsp response verification failed, no signer certificate 'C=CH, O=strongSwan Project, OU=Sales OCSP Signing Authority, CN=ocsp.sales.strongswan.org' found
messages from the cached OCSP responses for carol's end-entity
certificate, the applicable but unrelated response for carol's "Research"
intermediate CA certificate and the response for dave's end-entity
certificate when verifying dave's "Sales" intermediate CA.
When running as a service, the libraries are initialized/deinitialized
not by the main thread but by a separate thread that runs the registered
main service procedure. When the service is stopped, the libraries are
deinitialized by that thread and the thread lock and hashtable are
destroyed. But afterwards the DllMain callback is also triggered for
that thread so we have to prevent it from accessing these objects again.
References strongswan/strongswan#1567
If no CHILD_SA is initiated, we wait for a state change to IKE_ESTABLISHED
but that will never happen for already established IKE_SAs.
References strongswan/strongswan#1553
Also adds error reporting via VICI for issues with mediation settings.
Fixes: 229cdf6bc8 ("vici: Order auth rounds by optional `round` parameter instead of by position in the request")
References strongswan/strongswan#1569
That method is subject to interface filtering, which isn't ideal for
DHCP traffic that probably uses an internal interface on which the IKE
daemon might be disabled. In that case `giaddr` is set to an incorrect
public IP, which in turn might prevent the plugin from receiving the
DHCP server's unicast response, in particular if the DHCP socket
is bound to the internal interface.
This new approach connects the client socket and thereby determines the
source address to reach the DHCP server.
Closesstrongswan/strongswan#1573
As indicated by the comparisons and the parsing in scep_parse_caps()
this should be a bitmask.
Fixes: 7c7a5a0260 ("pki: Enroll an X.509 certificate with a SCEP server")
Closesstrongswan/strongswan#1607
With 5401a74d36 ("eap-tls: Add support for TLS 1.3") a TLS application
was added to implement TLS 1.3's protected success indication. For
earlier TLS versions, its build() method simply returned SUCCESS as
there was nothing to send. However, that had the unintended side-effect
of also not sending the final TLS handshake messages (ChangeCipherSpec
and Finished).
The reason is that the TLS stack first checks for remaining handshake
messages but then also asks the registered application for data to
piggyback to that response (before the commit there was no application,
so that step was skipped). The problem is that the status returned by
the application is directly forwarded through the TLS stack. So not
returning INVALID_STATE caused the session to get concluded immediately
instead of resulting in ALREADY_DONE that would trigger sending the
final EAP message instead of an EAP-Success.
Fixes: 5401a74d36 ("eap-tls: Add support for TLS 1.3")
The MSK is generated when the keys are derived. For TLS 1.3 that's also
when the handshake is complete. However, for TLS 1.2 it happens when
generating or processing the ClientKeyExchange message, which, on the
client, happens before the final Finished handshake message has been
received from the server. This caused the EAP-TLS client to accept an
EAP-Success message instead of the server's final TLS handshake
messages, unintentionally allowing servers to cut the exchange short by
two EAP messages (in the regular exchange the response to the server's
final handshake messages is an empty EAP-Response, which is then
followed by the server's EAP-Success).
While this is not correct, it does not seem to pose a security issue.
If DH is used as key exchange, the server signs the ServerKeyExchange
message and the client is sure to communicate with a trusted server
before it derives the MSK. If RSA encryption is used as key exchange,
the client sends the premaster secret, on which the MSK is based,
encrypted with the server's public key (as extracted from the trusted
certificate). An attacker won't be able to decrypt this and, therefore,
can't derive the same MSK to generate a valid AUTH payload and the IKE
authentication will fail.
Since 3dd5dc5011 ("Merge branch 'vici-python-timeout'"), any timeout
set directly on the socket is reset by `vici.Transport.receive()` unless
called by `vici.Session.listen()`. This prevents configuring a default
timeout directly on the socket.
However, setting a timeout directly on the socket also had drawbacks
since it can cause `vici.Transport.receive()` to raise a timeout error
while a subset of the data have been received, with no way to recover.
This commit merges both approaches by considering the timeout configured
on the socket by default (when no timeout is explicitly set) and
keeping the switch to blocking receive once the first byte has been
received. When the full expected data have been received, the timeout
configured on the socket is restored.
Co-authored-by: Tobias Brunner <[email protected]>
Signed-off-by: Jean-Tiare Le Bigot <[email protected]>
Closesstrongswan/strongswan#1562
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.
The flags encoded in the PKCS#10 structure (or derived from the encoded
profile name) might not be appropriate in some instances. This allows
overriding them without having to issue a new certificate request.
This allows NM more freedom in regards to how it wants to use the passed
device. In particular, if dnsmasq is used with NM as that binds to the
interface to send requests via VPN.
Installing the VIPs on lo avoids weird address removal/addition events
that happen for IPv6 on the physical interface (which would cause the VIP
to get incorrectly detected as non-VIP address and ignored during
deletion).
We could let NM install routes via XFRM interface, however, that causes
problems with e.g. the bypass-lan plugin (the throw routes in table 220
wouldn't have any effect). We could let it install regular routes in
the main table, but determining the physical interface would be tricky
as the routes installed by NM, also in the main table, would conflict.
So instead we let the kernel-netlink interface install routes via XFRM
interface and to avoid routing the IKE traffic that way, we set a mark
on the IKE socket and exclude traffic with that mark from our routing
table.
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.
The manager will allow charon-nm to create XFRM interfaces if supported
by the kernel instead of creating an unused dummy TUN interface.
The xfrmi tool is mostly obsolete nowadays as iproute2 supports creating
XFRM interfaces since 5.1.0 (2019-05). Older Debians don't ship that and
early versions didn't list the interface IDs. So there might still be
some uses for this tool.
NM doesn't terminate charon-nm after disconnecting, so the TUN device
previously stayed around even if no connection was established. This
might be a bit more what users expect.
As defined in RFC 9190, a "protected success indication" (0x00) is sent
from the server to the client over the TLS connection when using TLS 1.3.
The client responds with an empty EAP message, which is interpreted as
acknowledgement in our stack.
If we ever support session resumption with tunneled methods such as
EAP-TTLS, we'd have to send such an indication there too.
As noted in 121ac4b9e3 ("tls-crypto: Generate MSK for TLS 1.3"), the
calculation was only preliminary. It is now fixed according to RFC 9190
and draft-ietf-emu-tls-eap-types (soon to become an RFC, currently in
the RFC editor queue).
Fixes: 121ac4b9e3 ("tls-crypto: Generate MSK for TLS 1.3")
Has been supported by libipsec for a long time (since 5.1.1). UDP encap
is already enforced via config, this just makes the flags the same as
in kernel-libipsec.
Since 6.2 the Linux kernel updates the last use time per SA. In
previous releases the attribute was only updated and reported for
specific outbound IPv6 SAs.
Using this reduces the number of kernel queries per CHILD_SA: for DPDs
from two policy queries (IN/FWD) to a single query of the inbound SA,
and for status reports the three policy queries (IN/FWD/OUT) can be
omitted and only the two SAs have to be queried. For NAT keepalives the
number of queries doesn't change but a policy query (OUT) is replaced by
a query for the outbound SA.
While we could use the existence of the attribute as indicator for its
support, we don't know this until we queried an SA. By using a version
check we can announce the feature from the start.
Currently supported by libipsec and PF_KEY on macOS (FreeBSD, like Linux,
reports the time the SA was first used in sadb_lifetime_usetime - it also
triggers rekeyings based on that, which Linux doesn't, it also triggers
them if an SA is never used).
Andreas Steffen