CVE-2024-28854: Tmccombs Tls-listener DoS Vulnerability

CVE-2024-28854 Overview

CVE-2024-28854 affects tls-listener, a Rust crate that wraps connection listeners to support Transport Layer Security (TLS). The default configuration exposes services to a slow-loris denial of service (DoS) attack. A remote attacker can open as few as 6.4 TcpStream connections per second, send zero bytes, and exhaust the listener's handshake capacity. Any public service constructed with TlsListener::new() in versions prior to 0.10.0 is affected. The flaw is tracked under [CWE-400: Uncontrolled Resource Consumption].

Critical Impact

Unauthenticated remote attackers can disable TLS-fronted services by holding open a small number of incomplete handshakes, blocking legitimate clients.

Affected Products

• tmccombs/tls-listener Rust crate, all versions prior to 0.10.0
• Any public service that calls TlsListener::new() with default options
• Downstream Rust services that depend on tls-listener for TLS termination

Discovery Timeline

• 2024-03-15 - CVE-2024-28854 published to the National Vulnerability Database (NVD)
• 2025-04-09 - Last updated in NVD database

Technical Details for CVE-2024-28854

Vulnerability Analysis

The vulnerability is a classic slow-loris style resource exhaustion issue against the TLS handshake layer. tls-listener accepts inbound TCP connections and then drives each one through a TLS handshake before yielding a usable stream to the application. The default configuration limits the number of concurrent in-flight handshakes through the max_handshakes parameter. When this limit is reached, the listener stops accepting new TCP connections until pending handshakes complete or time out.

An attacker abuses this design by opening TCP connections and never sending any TLS ClientHello bytes. Each connection occupies a handshake slot indefinitely. Researchers demonstrated that roughly 6.4 connections per second are enough to keep the queue saturated. Legitimate clients then cannot complete handshakes, producing a denial of service condition that requires no authentication.

Root Cause

The root cause is an insecure default value for Builder::max_handshakes. The default cap is small enough that an unauthenticated remote attacker can fill it with idle TCP sockets. There is no aggressive per-connection handshake timeout enforced in the default path, so partial handshakes persist long enough to block new accepts.

Attack Vector

Exploitation requires only network reachability to the TLS endpoint. The attacker does not need credentials, user interaction, or valid TLS material. A trivial script that opens TCP sockets and holds them open is sufficient. The impact is limited to availability — confidentiality and integrity are not affected.

// Patch reference: bump to fixed release
// Source: https://github.com/tmccombs/tls-listener/commit/d5a7655d6ea9e53ab57c3013092c5576da964bc4
[package]
name = "tls-listener"
description = "wrap incoming Stream of connections in TLS"
-version = "0.9.1"
+version = "0.10.0"
authors = ["Thayne McCombs <astrothayne@gmail.com>"]
repository = "https://github.com/tmccombs/tls-listener"
edition = "2018"

Source: GitHub Commit d5a7655

Detection Methods for CVE-2024-28854

Indicators of Compromise

• Spikes in concurrent half-open TCP connections to TLS listener ports that never progress past the handshake.
• TLS endpoints reporting accept queue stalls or rejected connections from legitimate clients while CPU usage stays low.
• Many source IPs or a small set of IPs holding TCP sessions open with zero bytes transmitted after the SYN-ACK.
• Application logs from services using tls-listener showing the handshake limit reached repeatedly.

Detection Strategies

• Inventory Rust projects for Cargo.lock entries containing tls-listener at versions below 0.10.0.
• Monitor TLS endpoints for connections that complete the TCP handshake but never send a ClientHello within a short window.
• Correlate accept-rate drops with sustained low-volume inbound TCP traffic on TLS ports to identify slow-loris behavior.

Monitoring Recommendations

• Track per-source connection counts and connection age on TLS listener sockets, alerting when many sessions remain in a pre-handshake state.
• Emit metrics for handshake queue depth and rejection counts from any service using tls-listener.
• Forward network flow and TLS handshake telemetry to a centralized analytics pipeline for retrospective hunting against slow-loris patterns.

How to Mitigate CVE-2024-28854

Immediate Actions Required

• Upgrade tls-listener to version 0.10.0 or later in all dependent Rust projects and rebuild affected binaries.
• Audit Cargo.lock files across repositories and CI artifacts to confirm no vulnerable transitive dependency remains.
• Place TLS-terminating services behind a reverse proxy or load balancer with its own slow-loris protections until patched builds are deployed.

Patch Information

The fix is released in tls-listener0.10.0. The maintainer's advisory and patch are published as GHSA-2qph-qpvm-2qf7 and applied in commit d5a7655. Background on the attack class is covered in the Wikipedia article on Slowloris.

Workarounds

• If upgrading is not immediately possible, pass a large value such as usize::MAX to Builder::max_handshakes to remove the bottleneck.
• Enforce short per-connection handshake timeouts at the listener or upstream proxy layer.
• Apply per-source-IP connection rate limits at the network edge to blunt single-host slow-loris attempts.

# Update the dependency in Cargo.toml and rebuild
cargo update -p tls-listener --precise 0.10.0
cargo build --release

# Verify the resolved version
cargo tree -p tls-listener