Rapid Reset breaks the link between streams and server work

A concurrency limit only bounds the work that it actually counts. In an HTTP/2 server, a client can open a request stream and then cancel it. If cancellation releases the stream slot while the server is still doing work for the request, the client can immediately start another request without waiting for that earlier work to finish. A limit on open streams can then coexist with excessive server activity.

The October 11 Istio security advisory covers HTTP/2 denial of service in Envoy and Go under CVE-2023-44487 and CVE-2023-39325. It identifies accepting HTTP/2 from untrusted sources as the exposure, especially at an internet-facing Gateway. The attack concerns protocol handling and resource consumption before a successful application transaction is necessary.

I value the policy consistency a mesh can provide across applications. That consistency depends on the proxy remaining available to process legitimate requests. A protocol-level resource exhaustion attack therefore belongs in the mesh's operating model even when application-level identity and authorisation policies are otherwise correct.

A reset does not synchronously finish a handler

The Go vulnerability report explains the concurrency mismatch directly. A malicious HTTP/2 client rapidly creates requests and resets them. Although MaxConcurrentStreams bounds request streams, resetting an in-progress request permits another stream while the previous handler is still executing. The protocol's available slot and the server's running work no longer have the same lifetime.

That distinction explains why a concurrency setting can appear present without providing the expected protection. The server is enforcing a stream count. The resource it needs to bound is executing request work. Cancellation changes the former sooner than it necessarily changes the latter, letting a client repeat the operation while previous work remains active.

The corrected Go implementation bounds simultaneously executing handler goroutines to the stream concurrency limit. A new request arriving at that bound is queued until a handler exits. If the queue becomes too large, the server terminates the connection. The fix therefore tracks execution separately from the client's ability to reset a stream.

That gives the limit a stronger relationship to the resource being protected. A reset can still express client cancellation, but it cannot create unlimited additional handler execution merely by freeing a protocol slot. The server also bounds the pending work behind the active handlers instead of permitting an unlimited queue to replace an unlimited execution problem.

Go's fix covers more than one integration path

The Go report identifies fixes in Go 1.20.10 and 1.21.3. It also identifies golang.org/x/net/http2 version 0.17.0 for users configuring HTTP/2 through that package. Those are distinct integration paths through which a Go server can obtain HTTP/2 support.

The report gives a default stream concurrency limit of 250 requests per connection and explains that it can be adjusted through the HTTP/2 package's server setting. That number describes the default limit associated with the implementation. It should not be read as an acceptable workload size for every application handler or a universal capacity recommendation.

The important correction is the lifetime used in enforcement. A smaller stream count alone would still leave the mismatch if completed protocol cancellation were treated as completed execution. By counting handlers and bounding the queue, the fix connects admission of additional work to actual progress in finishing earlier work.

That distinction is applicable beyond HTTP/2 without requiring any claim about another implementation. A resource bound needs a defined release condition. If a client-controlled event releases the bound before the protected resource is reclaimed, repeated cancellation can create more simultaneous resource consumption than the bound appears to allow.

Envoy addresses its own HTTP/2 processing path

Envoy's Rapid Reset advisory describes CPU exhaustion from crafted sequences of request headers and resets. Its mitigation includes budgeting prematurely reset streams and disconnecting a connection after that budget is exceeded. It also documents additional fairness-related mitigation with separate activation and risk qualifications.

Those implementation details should remain distinct from Go's handler-goroutine correction. Istio's advisory includes both dependencies because the release contains software using different request-processing implementations. A fix in one library does not alter the other implementation merely because both speak HTTP/2.

For a mesh operator, this makes version inventory a component-level question. The proxy receiving downstream traffic and a Go server accepting requests are different executables. The security release brings corrected dependencies into the delivered software, while the deployment determines which executable handles a particular exposed path.

The Envoy advisory identifies disabling downstream HTTP/2 as the workaround it offers outside upgrading. That is a protocol-availability tradeoff, not a transparent equivalent of installing the corrected implementation. A service using HTTP/2 needs its compatibility requirements considered separately from the presence of a network listener.

The public Istio patch is 1.19.3

The Istio 1.19.3 announcement says it fixes the October 11 vulnerabilities. It also explains why the public version skips 1.19.2. That release was published only internally and was superseded so additional security fixes could be included in 1.19.3.

This detail matters when mapping version numbers to a public remediation. Assuming the missing number is the expected patch would point readers at a release they cannot obtain through the normal public path. The maintainers explicitly identify 1.19.3 as the published update and describe its changes relative to 1.19.1.

The security advisory lists affected releases through 1.17.6, 1.18.3, and 1.19.1, as well as releases older than 1.17. Those ranges identify the vulnerable Istio distributions. They do not establish that an installation has finished updating every relevant component simply because its intended target version has been selected.

A deployment record should distinguish the requested version from the software currently processing traffic. That is especially relevant in a mesh where proxies can be updated through workload replacement and control-plane revisions can coexist. An advisory names corrected software, while the installation's actual component versions establish where that software is running.

It is also useful to identify the endpoint where the downstream HTTP/2 connection ends. An application reached through a Gateway is not necessarily the component parsing the client's frames. The dependency report needs to follow the actual protocol-processing path, because that is where the relevant stream and execution limits operate.

This does not require treating every internal hop as equivalent to a public listener. The advisory's exposure condition supplies the starting point, accepting HTTP/2 from an untrusted source. Following that connection to its handling implementation connects the deployment inventory to the particular vulnerability report instead of relying only on the application's externally visible hostname.

Internet exposure changes which trust assumption matters

Istio's advisory says most users are affected by accepting HTTP/2 from untrusted sources and emphasises public Gateways. The relevant trust question is whether the downstream peer can exercise the protocol behaviour. It does not require the peer to complete a useful application operation before sending cancellation.

This makes an application-level account of requests incomplete for resource management. A cancelled request may never produce a normal successful transaction, while parsing and scheduling it can still consume server work. Counting only business operations that completed would omit activity relevant to the denial-of-service mechanism.

I find the execution-bound explanation useful because it identifies what the correction must preserve. The system needs a limit tied to unfinished work and a bounded response when further requests arrive. Cancellation remains useful protocol behaviour, but it cannot be treated as evidence that every resource allocated to a request has already been released.

The protected resource determines the right bound

The Go fix offers a concrete before-and-after account. Previously, a reset made room for another protocol stream while an older handler could continue running. With the correction, handler concurrency remains bounded independently of that reset, and queued requests have a termination threshold. The release repairs that specific relationship between request admission and execution.

The two CVEs in Istio's advisory therefore need implementation-specific updates even though they share the Rapid Reset context. Envoy's downstream processing and Go's HTTP/2 server each need their own corrected limits. Istio 1.19.3 packages the public security update, with the advisory defining the affected release ranges and the upstream reports explaining the resource-management failures it addresses.