]> git.ipfire.org Git - thirdparty/strongswan.git/commit
tls: Only return EAP MSK if TLS handshake is complete
authorTobias Brunner <tobias@strongswan.org>
Mon, 13 Mar 2023 12:26:25 +0000 (13:26 +0100)
committerTobias Brunner <tobias@strongswan.org>
Tue, 21 Mar 2023 15:11:49 +0000 (16:11 +0100)
commitdb87087fae6b4d1761dfba4eae3bd4880f5d23ab
tree499d10a1e8882a057544c8ee180c0a6650749abd
parent67c73031814c1f44dce0480b5560350265d1b113
tls: Only return EAP MSK if TLS handshake is complete

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.
src/libtls/tls.c