CVE-2024-23744

What it actually does

An unauthenticated remote attacker can send a TLS 1.3 ClientHello message containing no extensions, causing Mbed TLS 3.5.1 to enter a persistent handshake denial state that prevents subsequent legitimate connections from completing.

Why it matters to the business

Disruption of TLS-protected services leads to loss of availability for any application or device relying on the affected library, resulting in downtime until the process is restarted or the flaw is mitigated.

How an attack unfolds

An attacker crafts and transmits a minimal TLS 1.3 ClientHello lacking extensions; the server enters a denial state that blocks further handshakes until the affected process is restarted or the vulnerability is addressed.

How to fix it

Upgrade Mbed TLS to a version that resolves the handshake-denial condition once a fix is released by Trusted Firmware; in the interim apply network-level filtering or rate limiting on anomalous ClientHello messages.

How to confirm the fix worked

Replay a TLS 1.3 ClientHello without extensions against a patched instance and confirm the server continues to accept subsequent valid handshakes without entering a denial state.

Typical attack path

1. Locate services exposing Mbed TLS 3.5.1 over TLS 1.3
2. Send a single TLS 1.3 ClientHello packet with no extensions
3. Observe the server entering persistent handshake denial
4. Repeat as needed to maintain denial of service

How to detect it

Inspect TLS server logs and network captures for repeated handshake failures triggered by ClientHello messages that contain no extensions; correlate with process restarts or availability alerts.

What your security team should do

• Prioritize patching Mbed TLS as soon as fixed versions become available
• Implement ingress filtering or proxy rules that drop ClientHello messages lacking required extensions
• Monitor application and TLS logs for clusters of handshake failures originating from single sources