We only allow unencrypted change_cipher_spec records (as before), which
are handled by the upper layers accordingly. Without the check, we
also accepted unprotected alerts and handshake records that could
potentially cause state confusion.
Fixes: 7a2b02667c ("libtls: Implement TLS 1.3 handshake on client-side")
In non-blocking mode, the previous code set `in_done` to -1 (SIZE_MAX)
if `recv()` would block and nothing was read yet. If this was followed
by a call to `write()` and `process()` is called and actually processed
application data, the length calculation in the callback underflows and
`memcpy()` would write to `in.ptr + SIZE_MAX`. Since `read()` already
sets `errno` to `EWOULDBLOCK` and returns -1 if `in_done` is 0, the
removed check was redundant anyway.
Also, the buffer from the previous `read()` call might not be valid
anymore when `write()` is called (e.g. `splice()` uses the same buffer
for both, and the buffer could even be defined on a now invalid stack
frame of the function that called `read()` previously). Clearing the
data avoids that and ensures the application data is cached until the
next call to `read()`.
However, triggering this is rather difficult as `write()` should only
reach `recv()` while the handshake isn't complete and until then
`process_application()` doesn't accept application data. But if the
handshake is completed during a call to `write()` that follows a
non-blocking read and data immediately arrives, it's theoretically
imaginable. This scenario is highly unlikely on a TLS server, which
starts the process with a call to `read()` that then basically loops
until the handshake is done. Even if multiple calls are required, the
server will generally not call `write()` before it received application
data. And any calls to `write()` afterwards do not reach `recv()`
anymore (unless no data to send was passed, which would be weird, or
maybe for some weird corner case that lets `build()` fail before all
outbound application data was processed).
If the extension doesn't contain a multiple of two bytes, the previous
code would get stuck in an infinite loop as `remaining()` continued to
return TRUE while `read_uint16()` failed to parse a value. Initiating
several connections with such an extension allows a DoS attack as no
threads would eventually be available to handle packets/events.
Fixes: 7fbe2e27ec ("tls-server: TLS 1.3 support for TLS server implementation")
Fixes: CVE-2026-35328
This prevents a crash due to a null-pointer dereference when processing
an empty ECDH public key.
The previous length check only applied in the `!ec` case, so in the `ec`
case, the access to `pub.ptr[0]` was unguarded. If a crafted TLS
record ends with an empty ClientKeyExchange, then `read_data8` sets
`pub` to `chunk_empty`, causing a null-pointer dereference.
Note that if some data follows the empty ClientKeyExchange, this just
causes a 1-byte out-of-bounds read that has no further effect as the
TLS session is aborted immediately. Either because the read value
doesn't equal TLS_ANSI_UNCOMPRESSED or because the empty public key
is rejected by `set_public_key()`.
The referenced commit that introduced the pointer access, added the
check for `pub.len` specifically to the `!ec` case, while the pointer
access was initially unconditional (probably because the code was just
copied from `tls_peer.c` which processes ECDH public keys in a separate
function, so there was no `ec` flag). The latter was fixed a couple of
days later with 7b3c01845f ("Read the compression type byte for EC
groups, only"). However, that commit didn't change the length check.
Anyway, it's possible that the original intention was to add the check
to the `ec` case on the previous line, or that there was some confusion
with the parenthesis and something like the current code was intended to
begin with.
Fixes: e6cce7ff0d ("Prepend point format to ECDH public key")
Fixes: CVE-2026-35332
The `cipher_suites` field has a 16-bit length field, so up to 32k 2-byte
cipher suites could technically be proposed. With `tls_cipher_suite_t`
typically being 4 bytes wide, the necessary allocation for the temporary
array can be up to 128 KiB. Even though this should be fine on typical
systems, we avoid potentially overflowing the stack by using malloc()
instead of alloca().
If nothing was read from the message, the previous code could result in
a crash depending on where `ext.ptr` pointed to, as determined by the
current stack contents. Since TLS 1.3 is still disabled by default and
this is usually used for TLS-based EAP methods after validating the
IKEv2 server's certificate, the real world impact seems relatively low.
Fixes: 9ef46cfaf9 ("tls-peer: Mutual authentication support for TLS 1.3")
Besides being clearer, this fixes issues with GCC 15. The latter uses
C23 by default, which changes the meaning of function declarations
without parameters such as
bool return false();
Instead of "this function takes an unknown number of arguments", this
now equals (void), that is, "this function takes no arguments". So we
run into incompatible pointer type warnings all over when using such
functions. They could be cast to (void*) but this seems the cleaner
solution for this use case.
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.
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.
Tobias Brunner