CVE-2025-66199

*** Pendiente de traducción *** Issue summary: A TLS 1.3 connection using certificate compression can be<br /> forced to allocate a large buffer before decompression without checking<br /> against the configured certificate size limit.<br /> <br /> Impact summary: An attacker can cause per-connection memory allocations of<br /> up to approximately 22 MiB and extra CPU work, potentially leading to<br /> service degradation or resource exhaustion (Denial of Service).<br /> <br /> In affected configurations, the peer-supplied uncompressed certificate<br /> length from a CompressedCertificate message is used to grow a heap buffer<br /> prior to decompression. This length is not bounded by the max_cert_list<br /> setting, which otherwise constrains certificate message sizes. An attacker<br /> can exploit this to cause large per-connection allocations followed by<br /> handshake failure. No memory corruption or information disclosure occurs.<br /> <br /> This issue only affects builds where TLS 1.3 certificate compression is<br /> compiled in (i.e., not OPENSSL_NO_COMP_ALG) and at least one compression<br /> algorithm (brotli, zlib, or zstd) is available, and where the compression<br /> extension is negotiated. Both clients receiving a server CompressedCertificate<br /> and servers in mutual TLS scenarios receiving a client CompressedCertificate<br /> are affected. Servers that do not request client certificates are not<br /> vulnerable to client-initiated attacks.<br /> <br /> Users can mitigate this issue by setting SSL_OP_NO_RX_CERTIFICATE_COMPRESSION<br /> to disable receiving compressed certificates.<br /> <br /> The FIPS modules in 3.6, 3.5, 3.4 and 3.3 are not affected by this issue,<br /> as the TLS implementation is outside the OpenSSL FIPS module boundary.<br /> <br /> OpenSSL 3.6, 3.5, 3.4 and 3.3 are vulnerable to this issue.<br /> <br /> OpenSSL 3.0, 1.1.1 and 1.0.2 are not affected by this issue.