Automatic SNI turns an oversized authority header into an Envoy crash
CVE-2024-32475 exposes a failure when Envoy copies a long HTTP authority into outbound TLS SNI. Istio's new default makes the affected connection path relevant to ordinary 1.21 upgrades.
An HTTP authority value becomes input to a different protocol when a proxy derives outbound TLS SNI from it. CVE-2024-32475 exposes a failure in that conversion. Envoy attempts to set an oversized server name, the TLS operation fails, and the proxy aborts instead of handling the error. Istio's April 22 bulletin identifies requests with an authority header longer than 255 characters as a trigger when auto_sni is enabled.
The timing matters because Istio 1.21 enabled automatic SNI by default. A feature intended to make TLS origination less dependent on explicit destination configuration also makes request data relevant to setting the upstream TLS name. The vulnerability is in the implementation's handling of an invalid value, not in an administrator intentionally requesting an abnormal process exit.
I favor automatic security defaults when their behavior is explicit, but this is a reminder that deriving configuration from traffic creates an input-validation obligation. The mesh now connects two protocol representations. Failure to represent the request's value in the destination protocol needs to remain an ordinary request error, rather than becoming a process-wide availability failure.
The failure occurs on the outbound TLS path
The Envoy advisory published April 18 identifies the affected component as TLS for outbound connections. A request reaches an upstream TLS cluster configured with automatic SNI. Envoy takes the HTTP host or :authority value, or an alternate header selected by override_auto_sni_header, and uses it as the server name for that connection.
The TLS name has a length limit. According to the advisory, a value longer than 255 characters makes the operation fail. Envoy expects that operation to succeed and aborts when it does not. The relevant programming defect is therefore error handling around a protocol-specific operation whose input originated in an HTTP request.
This explains the security impact without assuming any memory corruption. The advisory rates the flaw High at 7.5 and describes denial of service through abnormal process termination. Its vector records network access without prior privileges or user interaction. Confidentiality and integrity impact are not claimed in that rating. The failure is severe because the process handling traffic terminates.
The advisory also identifies an assertion-failure message involving SSL3_EXT_INVALID_SERVERNAME as a detection clue. That message connects an apparent TLS failure to the process-abort condition. It should be interpreted in context with the configured automatic-SNI path, rather than treating every TLS handshake error as evidence of this CVE.
Istio's default determines the affected configuration
The 1.21 upgrade notes document ENABLE_AUTO_SNI=true. If DestinationRule does not explicitly set SNI, the value comes from the downstream HTTP host or authority. This is the ordinary default change that makes the April vulnerability relevant to users upgrading from earlier behavior.
The Istio bulletin lists versions 1.19.0 through 1.19.9, 1.20.0 through 1.20.5 and 1.21.0 through 1.21.1, as well as releases before 1.19.0. It says users are impacted if they enabled Envoy's automatic SNI, use the affected 1.21 configuration where it is default-on, or use an egress gateway. Software version and enabled path both belong in that assessment.
This also clarifies the role of an explicit SNI setting. Automatic derivation applies when DestinationRule does not supply the value. The relevant question is how a particular upstream connection obtains its name. A generic statement that the mesh uses TLS would be too broad to identify the vulnerable behavior described by the advisory.
Compatibility versions were introduced to retain selected prior defaults during an upgrade. They explain why two installations of the same Istio release can have different behavior around automatic SNI. That does not turn compatibility selection into the complete security repair. The patched proxy implementation still matters wherever the automatic path is used.
Workarounds act before the invalid conversion
The Envoy advisory offers several ways to prevent the crash while arranging an update. One is to reject oversized host or authority values before proxying them upstream. Another is to rewrite the value to a trusted name short enough for SNI. Disabling auto_sni avoids the automatic conversion itself. These approaches intervene at different points but all prevent the failing operation from receiving the oversized input.
The advisory specifically notes ordering for a route-based rejection. A special route rejecting problematic values must appear first so other route matches do not bypass it. This is a concrete configuration requirement, because a rejection rule that never receives the request cannot protect the later upstream processing path.
Rewriting also changes semantics. Supplying a trusted fixed name means the upstream TLS name no longer follows the original request authority in the same way. That may be appropriate for a known destination, but it is a configuration choice about which name the connection represents. A workaround needs to preserve the intended destination behavior as well as prevent termination.
I regard these options as explanations of the failure boundary. They show which input reaches the TLS operation and where an administrator can constrain it. The underlying implementation still needs to handle a failed SNI-setting operation safely, because request-derived data should not be able to convert a recoverable error into termination of the whole proxy.
The patched release changes the implementation
The Istio 1.21.2 release implements the April security update. Its notes distinguish that repair from additional CNI improvements, including profiling endpoints and lower memory use when handling large files. Those accompanying changes do not alter the affected TLS path's conditions.
The practical security boundary is the running proxy that originates the upstream TLS connection. A configuration review identifies whether it derives SNI from request data, while the patched release supplies safe handling for the reported error. The advisory's mechanism makes the distinction precise, HTTP input can exceed what the next protocol operation accepts, and that rejection must remain contained within request processing.