TLS 1.3 vulnerabilities

During the TLS 1.3 handshake, if multiple messages are sent in records that span encryption level boundaries (e.g., Client Hello and Encrypted Extensions), subsequent messages may be processed before the encryption level changes. This can cause minor information disclosure.

In TLS 1.3, the actual record type is embedded as the last non-zero byte of the decrypted payload, optionally followed by zero padding. The code which searches for the inner record type had an off-by-one bug which could be triggered by an invalid frame, leading to an underflow followed by an unconditional NULL pointer dereference, causing a kernel panic. A remote TLS 1.3 peer can send a specially crafted record to trigger a kernel panic, resulting in a Denial of Service (DoS).

A TCP client can perform a TLS handshake and present the server name extension with a server name accepted by a server wildcard name, e.g. if the server is configured with a certificate accepting *.example.com, any XYZ.example.com where XYZ is a valid name can be used. The description does not identify a specific product or version.

If one side of the TLS connection sends multiple key update messages post-handshake in a single record, the connection can deadlock, causing uncontrolled resource consumption. This leads to denial of service. This only affects TLS 1.3.

With TLS 1.2 connections, a client can use any supported digest, including a weaker one, instead of those specified in the CertificateRequest. This may weaken the security of the connection handshake.

With TLS 1.3 pre-shared key (PSK), a malicious or faulty server could ignore the request for PFS (perfect forward secrecy) and the client would continue the connection using PSK without PFS. This occurs when a server responds to a ClientHello containing psk_dhe_ke without a key_share extension, reducing connection security.