Terraform 1.11.4 disables a TLS key exchange for firewall compatibility

An infrastructure client can encounter a network compatibility failure without changing its configuration language or the cloud API it calls. Its implementation language can change the TLS handshake underneath the same operation. Terraform 1.11.4, released on April 9, addresses that situation by disabling X25519Kyber768Draft00 to prevent timeouts with some AWS network firewalls. The patch also corrects how internal providers return write-only attributes.

I value Terraform's ability to turn API operations into reusable configuration, but that abstraction still depends on the client reaching those APIs. A timeout caused by a handshake change is especially awkward because the configuration being reviewed may be entirely unchanged. The April fix belongs to the executable's transport behavior.

Go supplied a different default handshake

The Go 1.23 release notes describe an experimental hybrid post-quantum key exchange, X25519Kyber768Draft00, enabled by default when the TLS configuration does not explicitly select its curve preferences. They also describe disabling that default with GODEBUG=tlskyber=0. The release notes warn that buggy TLS implementations can fail because of the larger records associated with the new exchange.

That context explains why a dependency or toolchain change can affect a client before an application author adds a new TLS option. Using the standard library's defaults delegates part of the wire behavior to the toolchain. The program can continue making the same request while offering a different handshake to the network path between client and service.

The compatibility problem therefore does not require a new resource type or a different provider argument. It can arise before the remote application handles the intended request. Diagnosing it solely as a cloud API failure would miss the earlier protocol interaction.

Terraform sets the compatibility choice in the build

The Terraform patch adds a godebug directive to go.mod. Its comment identifies the experimental exchange and errors with AWS Network Firewall when using Go 1.23. This is a default embedded in the program's build configuration, not an HCL backend argument or a provider-specific setting.

The relevant directive is short:

godebug tlskyber=0

This establishes the scope of the workaround. Terraform disables that exchange in its own Go TLS behavior. The patch does not disable TLS, switch requests to plaintext or remove certificate verification. It changes the default that triggered the reported compatibility problem while leaving the application using TLS.

There is also no basis in this change for claiming that it alters every provider's network transport. A separately built provider is its own executable dependency. The patch modifies Terraform's module configuration. Its effect should be described at that boundary unless the provider's own implementation supplies evidence of the same choice.

Write-only values have a different persistence contract

The second fix follows the new managed-resource capability described in the Terraform 1.11 announcement. Providers can define write-only arguments that accept values without storing them in plan or state files. This extends the usefulness of ephemeral values by allowing temporary data to enter supported managed-resource arguments.

The important distinction is between supplying an input and returning it as part of the resource's retained value. Write-only handling must preserve that distinction through all execution paths. A mock or override that synthesizes a resource result still participates in the same contract, even if it never calls the external service that a real provider would use.

That makes this correction relevant to test implementations as well as ordinary resource execution. A simulated provider must reproduce the meaningful constraints of the provider protocol. Returning a configured write-only value unchanged can produce a result that an actual implementation is required to avoid.

Internal providers must clear the same attributes

The internal-provider patch applies write-only stripping to several synthesized responses, including mocked and overridden resource handling. Its tests cover normal, mocked and overridden cases. Those cases matter because an override can otherwise copy configuration values into a result without going through the provider behavior that normally clears them.

The stripping helper in the released source uses the provider schema to locate write-only attributes. It transforms those paths to null values with the corresponding type. This is schema-directed processing, so it does not depend on an attribute having a conventional password name or on a test author remembering to remove it manually.

I find this an important property for provider tests. A fixture that accepts an impossible result weakens the value of the test even if its expected outputs look plausible. Internal substitutes need to preserve the contract that write-only arguments introduce, including when other fields are generated or overridden for convenience.

The release's two fixes address different layers of the same infrastructure tool. One changes the TLS default used by the executable. The other makes internal provider responses respect a resource-schema rule. In each case, the configuration author can express the intended operation correctly while an implementation detail prevents the expected behavior. Terraform 1.11.4 repairs those details at their respective boundaries.