crypto/tls vulnerabilities
7 known vulnerabilities in crypto/tls from Go standard library. 7 are rated high or critical. Each entry lists the affected versions and the release that fixes it, where the vendor has published one.
Latest first
- 7.5 High severity
crypto/tls: Asymmetric Resource Consumption (Amplification)
Multiple ECH outer extension references are not permitted under RFC 9849; previously, a client could send a well-crafted packet that could trigger memory exhaustion in the server process by specifying multiple references. We now reject these as malformed and c
- 7.5 High severity
crypto/tls: Allocation of Resources Without Limits or Throttling
Handshake messages, such as KeyUpdate, are always considered as state-advancing, regardless of whether a handshake has been completed or not. As a result, a malicious client can keep sending KeyUpdate messages to force the server to keep performing key derivat
- 7.5 High severity
crypto/tls: Allocation of Resources Without Limits or Throttling
If one side of the TLS connection sends multiple key update messages post-handshake in a single record, the connection can deadlock, causing uncontrolled consumption of resources. This can lead to a denial of service. This only affects TLS 1.3.
- 10.0 Critical severity
crypto/tls: Improper Certificate Validation
During session resumption in crypto/tls, if the underlying Config has its ClientCAs or RootCAs fields mutated between the initial handshake and the resumed handshake, the resumed handshake may succeed when it should have failed. This may happen when a user cal
- 7.5 High severity
crypto/tls: Observable Discrepancy
Before Go 1.20, the RSA based TLS key exchanges used the math/big library, which is not constant time. RSA blinding was applied to prevent timing attacks, but analysis shows this may not have been fully effective. In particular it appears as if the removal of
- 7.5 High severity
crypto/tls: Allocation of Resources Without Limits or Throttling
QUIC connections do not set an upper bound on the amount of data buffered when reading post-handshake messages, allowing a malicious QUIC connection to cause unbounded memory growth. With fix, connections now consistently reject messages larger than 65KiB in s
- 7.5 High severity
crypto/tls: Uncontrolled Resource Consumption
Large handshake records may cause panics in crypto/tls. Both clients and servers may send large TLS handshake records which cause servers and clients, respectively, to panic when attempting to construct responses. This affects all TLS 1.3 clients, TLS 1.2 clie