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 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.
`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")
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
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.
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.
This way the client also properly considers the TLS version and the signature
schemes supported by the server.
Co-authored-by: Tobias Brunner <tobias@strongswan.org>
This commit also addresses the side effect that additional messages have
an influence on the derivation of the application traffic secrets. Therefore,
key derivation is relocated after the server finished message has been sent,
so the additional messages from the client (Certificate, CertificateVerify)
don't affect the key derivation. Only the outbound key is switched there, the
inbound key remains in use until the client's finished message has been
processed.
This change mainly affects legacy TLS versions because TLS 1.3
connections are terminated by the server once the peer does not send a
CertificateVerify message next to its empty Certificate message.
This won't work if the client doesn't send a `signature_algorithms`
extension. But since the default is SHA1/RSA, most will send it to at
least announce stronger hash algorithms if not ECDSA.
A client can send one or multiple key shares from which the server picks
one it supports (checked in its preferred order). A retry is requested if
none of the key shares are supported.
Adds support to request and handle retries with a different DH group.
Only the first key share extension sent by the client is currently
considered, so this might result in protocol errors if the server requests
a group for which the client already sent a key share.
If we don't do this, we might negotiate a TLS version for which we don't
have any suites configured, so that the cipher suite negotiation
subsequently fails.
PKCS#1 v1.5 signatures are not defined for use with TLS 1.3 (they can
only appear in certificates, we now send a signature_algorithms_cert
extension to indicate support for them). So for RSA certificates, we
must support RSA-PSS signatures.
There are two sets of schemes, that are differentiated by the type of
RSA key used for the signature, one is for classic RSA keys (rsaEncryption
OID), which can also be used with PKCS#1 when using TLS 1.2, the other
is for RSA-PSS keys (RSASSA-PSS OID), which are not yet commonly
used (and can't be generated by our pki tool). According to the RFC,
PSS must also be supported for TLS 1.2 if the schemes are included in
the signature_algorithms extension (e.g. OpenSSL does not use PKCS#1 v1.5
anymore if PSS is proposed).
This changes how these schemes are stored and enumerated (they are not
treated as combination of hash algo and key type anymore).
Legacy schemes (MD5/SHA-1) are removed.
The code is a minimal handshake with the HelloRetryRequest message
implementation missing.
Can be tested with an OpenSSL server running TLS 1.3. The server must
be at least version 1.1.1 (September 2018).
Co-authored-by: ryru <pascal.knecht@hsr.ch>
Tobias Brunner