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.
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")
`public` is returned, but previously only if a trusted key was found.
We obviously don't want to return untrusted keys and since the reference
was correctly destroyed after determining the key type, this later caused
a double-free.
Fixes: 63fd718915 ("libtls: call create_public_enumerator() with key_type")
Closing the socket from the main thread, while the server thread is
still in accept() (or is just about to enter it), seems to
occasionally cause a deadlock on macOS.
Seems to be required on macOS (libtls tests didn't run before the recent
implicit enabling via pki). Other platforms apparently let accept() fail
if the socket is shutdown/closed in teardown_creds(), macOS apparently
doesn't do that.
The gcm plugin has been added to the default plugins and all
certificate types are loaded to allow the libtls socket unit
tests to run with the strongSwan default plugins.
Currently when a TLS client doesn't have a certificate, it doesn't
send a certficiate payload upon receiving a certificate request
from the TLS server. According to the TLS 1.2 and 1.3 RFCs an
empty certificate payload must be sent.
has_subject() already matches the identity against the subject DN and
all the SANs (it actually already did when this check was added with
c811479986 ("Strictly check if the server certificate matches the TLS
server identity")).
The client already enforces that the server identity is contained in the
received certificate. But on the server, the referenced commit changed
the lookup from the configured (or adopted if %any was configured) client
identity to the subject DN of the received client certificate. So any
client with a trusted certificate was accepted.
Fixes: d2fc9b0961 ("tls-server: Mutual authentication support for TLS 1.3")
Closesstrongswan/strongswan#873
In particular as server, the previous code might cause it to hang in
recv() if this case wasn't triggered by a close notify (followed by a
shutdown of the socket) but it e.g. failed processing a ServerHello and
responded with a fatal alert.
Fixes: 09fbaad6bd ("tls-socket: Don't fail reading if sending data failed")
This allows clients to send an empty certificate payload if the server
sent a certificate request. If an identity was set previously, it will
be reset so get_peer_id() may be used to check if the client was
authenticated.
To request client authentication if we don't know the client's identity,
it's possible to use ID_ANY. However, if we don't change the identity
get_peer_id() would still report ID_ANY after the authentication.
As client with older TLS versions, we have to ack the receipt of the server's
Finished message instead.
Fixes: 083f38259c ("tls-eap: Conclude EAP method also after processing packets")
If the default group listed in the cipher suite is not supported, we try
to use any other supported group (the groups are negotiated separately
so we are not locked in to a specific group).
Since DH groups (or with TLS < 1.3 curves) are negotiated separately,
it doesn't matter which one is listed in the cipher suite as any one could
be used.
This was previously treated like a resumption, which it is clearly not.
Also added a check that verifies that the same cipher suite is selected
during the retry, as per RFC 8446, section 4.1.4.
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.
With TLS 1.3, the server sends its Finished message first, so the
session is complete after processing the client's Finished message,
without having to send anything else (in particular no acknowledgement
as the last message from the client is no fragment).
ECDSA support is currently required to run the tests because ECDSA
cipher suites are not filtered when determining the supported cipher
suites. Also required are ECDH groups.
If no cipher suites are available, the new versions are the previous
values but reversed (i.e. the versions were not changed but we still
ended up with a log message saying "TLS min/max TLS 1.3/TLS 1.0 ...").
Also switched to using the numeric version names to avoid the repeated
"TLS" prefix.
Tobias Brunner