Impact
If a connection limit is set (maxConnections or maxConnectionsPerHost greater than zero), the client leaks one connection permit every time a TLS connection attempt fails before the handshake completes. Permits are never returned on those paths, so they accumulate until the limit is reached, after which later requests are rejected with no connection actually open.
With a per-host limit, enough failed attempts against one host permanently lock the client out of that host, and a transient on-path attacker can inflict a lockout that persists after they leave. With a global limit, which is a common production setting, failing attempts against a single attacker-reachable host, for example a user-supplied webhook or an SSRF-influenced URL that the client retries, drain the shared pool and block the client from reaching every host. With the default connection limit of unlimited there is no leak.
Affected versions
- 3.x: 3.0.8 through 3.0.11
Earlier 3.0.x releases are not affected, and neither is the 2.x line: both bind the permit to the channel close future immediately, before any failure path can run. The regression was introduced with the HTTP/2 multiplexing rework first released in 3.0.8, which moved that binding into the handshake-success branches.
Patches
Fixed in 3.0.12. The permit is bound to the channel as soon as it leaves the request future, and is released exactly once on every exit path.
Workarounds
Leave connection limits at the default (unlimited), or avoid connecting to untrusted hosts that can fail the handshake at will.
Details
NettyConnectListener moved the permit out of the future at the start of onSuccess, but only attached the release listener inside the handshake-success branches. Every failure exit routed to onFailure, which closed the channel and aborted the request; because the permit had already been taken out of the future, the future's own release was a no-op and the permit was orphaned. Reported publicly as issue #2189.
Impact
If a connection limit is set (maxConnections or maxConnectionsPerHost greater than zero), the client leaks one connection permit every time a TLS connection attempt fails before the handshake completes. Permits are never returned on those paths, so they accumulate until the limit is reached, after which later requests are rejected with no connection actually open.
With a per-host limit, enough failed attempts against one host permanently lock the client out of that host, and a transient on-path attacker can inflict a lockout that persists after they leave. With a global limit, which is a common production setting, failing attempts against a single attacker-reachable host, for example a user-supplied webhook or an SSRF-influenced URL that the client retries, drain the shared pool and block the client from reaching every host. With the default connection limit of unlimited there is no leak.
Affected versions
Earlier 3.0.x releases are not affected, and neither is the 2.x line: both bind the permit to the channel close future immediately, before any failure path can run. The regression was introduced with the HTTP/2 multiplexing rework first released in 3.0.8, which moved that binding into the handshake-success branches.
Patches
Fixed in 3.0.12. The permit is bound to the channel as soon as it leaves the request future, and is released exactly once on every exit path.
Workarounds
Leave connection limits at the default (unlimited), or avoid connecting to untrusted hosts that can fail the handshake at will.
Details
NettyConnectListener moved the permit out of the future at the start of onSuccess, but only attached the release listener inside the handshake-success branches. Every failure exit routed to onFailure, which closed the channel and aborted the request; because the permit had already been taken out of the future, the future's own release was a no-op and the permit was orphaned. Reported publicly as issue #2189.