CVE-2023-3817 is a medium severity vulnerability in OpenSSL affecting versions 1.0.2, 1.1.1, 3.0.0, and 3.1.0. The issue arises from unchecked input used as a loop condition within the Diffie-Hellman (DH) parameter validation functions DH_check(), DH_check_ex(), and EVP_PKEY_param_check(). Specifically, these functions perform various checks on DH parameters, including the q parameter, which should never be larger than the modulus p parameter. However, if q is excessively large, the validation logic can enter an overly long computation loop, leading to significant delays. This behavior can be exploited by an attacker supplying maliciously crafted DH keys or parameters from an untrusted source, causing a Denial of Service (DoS) by exhausting CPU resources and delaying or halting the application. The vulnerability does not affect the OpenSSL SSL/TLS implementation itself nor the OpenSSL 3.0 and 3.1 FIPS providers. Additionally, the OpenSSL command line tools dhparam and pkeyparam are vulnerable when used with the "-check" option. The vulnerability stems from CWE-606 (Unchecked Input for Loop Condition), where input controlling loop iterations is not properly validated, allowing excessive computation. The CVSS v3.1 base score is 5.3 (medium), reflecting network attack vector, low attack complexity, no privileges or user interaction required, and impact limited to availability (DoS). No known exploits are reported in the wild at this time.

For European organizations, this vulnerability poses a risk primarily to applications and services that perform DH parameter validation using the affected OpenSSL functions on untrusted input. The impact is a potential Denial of Service, which could disrupt critical cryptographic operations, key management, or security validation processes. This could degrade service availability, especially in environments relying on custom or third-party software that validates DH parameters or uses OpenSSL command line tools for parameter checks. While the core SSL/TLS functionality is unaffected, any bespoke cryptographic workflows or automated security checks involving DH parameters could be targeted. This may affect sectors with high cryptographic usage such as finance, telecommunications, government, and critical infrastructure. The DoS could be leveraged in multi-stage attacks to weaken defenses or cause operational disruptions. Given the medium severity and absence of known exploits, the immediate risk is moderate but should not be underestimated in high-security environments.

1. Update OpenSSL to the latest patched versions where this vulnerability is fixed, as relying on older versions (1.0.2, 1.1.1, 3.0.0, 3.1.0) leaves systems exposed. 2. Audit applications and scripts that invoke DH_check(), DH_check_ex(), EVP_PKEY_param_check(), or use the dhparam and pkeyparam command line tools with the "-check" option, especially when processing untrusted input. 3. Implement input validation controls upstream to reject or sanitize DH parameters before passing them to OpenSSL functions, ensuring q parameters are not larger than p. 4. Where possible, restrict or sandbox the processing of DH parameters from untrusted sources to limit resource consumption and prevent DoS escalation. 5. Monitor application logs and system performance metrics for unusual delays or CPU spikes during DH parameter validation operations. 6. Consider deploying rate limiting or input size restrictions on interfaces accepting DH parameters to reduce attack surface. 7. For critical environments, isolate cryptographic validation services and apply strict access controls to minimize exposure to untrusted inputs.