Go 1.16.6 checks certificate key types during RSA key exchange
A TLS client panic comes from assuming a certificate contains an RSA public key. The fix rejects a mismatch as an error, including when the connection uses net/http.
A certificate can pass a trust check and still contain the wrong kind of public key for a negotiated operation. Go 1.16.6 fixes a TLS client path that assumed those properties were equivalent. Its RSA key-exchange implementation asserted that a certificate's public key had the RSA type without checking the assertion. An incompatible certificate could therefore produce a panic before the handshake completed.
The July 12 security announcement identifies CVE-2021-34558 and Go issue 47143. It announces Go 1.16.6 and Go 1.15.14 and explicitly includes net/http clients making HTTPS requests. The release history entry records the crypto/tls security fix alongside other maintenance changes.
I value Go's explicit error handling because it makes failure policy visible to the caller. A peer offering incompatible handshake material should produce a failed connection that code can handle. A type assumption inside the handshake defeats that expectation when the peer controls the input that violates it.
The operation requires an RSA key
The fixed key-agreement implementation describes RSA key agreement as encrypting a pre-master secret to the server's public key. The client constructs that secret, fills its random portion, and calls rsa.EncryptPKCS1v15. That operation needs an RSA public key.
The release diff shows the earlier call obtaining its argument through an unchecked type assertion on cert.PublicKey. The patch separates extraction from encryption and checks whether the assertion succeeded. A mismatch returns an error indicating that the server certificate has an incorrect key type for the selected cipher suite.
The repaired fragment makes that precondition explicit.
rsaKey, ok := cert.PublicKey.(*rsa.PublicKey)
if !ok {
return nil, nil, errors.New("tls: server certificate contains incorrect key type for selected ciphersuite")
}
This is an excerpt from the internal implementation, not a new configuration requirement for applications. After the check, the encryption call receives rsaKey. The success path still performs RSA encryption. This places the check next to the operation whose precondition it establishes. A reader can follow the accepted value into encryption without inferring a key type from earlier handshake choices or certificate-processing steps. The change concerns how the implementation rejects an input that cannot satisfy the operation's required type.
The distinction matters because an interface value can hold several concrete public-key types. A value being present does not establish which concrete type it contains. The checked assertion turns a violated assumption into an ordinary branch, allowing the function to return through its existing error result.
Certificate trust does not establish protocol compatibility
The advisory says an attacker in a privileged network position can trigger the panic without access to the server certificate's private key. One stated condition is that a trusted ECDSA or Ed25519 certificate for the server exists or can be issued. Another is that the client enables Config.InsecureSkipVerify.
These conditions are important to retain together. The advisory does not require every affected client to have disabled verification. A trusted certificate with a mismatched key type is part of the described attack. Conversely, the existence of a certificate alone does not establish every other condition for exploitation, including the attacker's network position and the negotiated parameters.
The private-key detail explains why a failure during the handshake can matter before successful authentication of the whole connection. During this process, the client reaches code that attempts the incompatible key operation. The attack aims to make that code panic, so completing a legitimate session is unnecessary. A certificate that the attacker cannot use to finish the intended exchange can still be enough to reach a faulty type assumption.
This is an availability issue in the announcement. The repair should not be described as evidence that the attacker can decrypt application traffic or forge a completed authenticated session. Those are different claims requiring different evidence. Here the concrete failure is the client panic, and the patch prevents the type mismatch from taking that route.
RSA authentication and RSA key exchange differ
The announcement identifies unaffected clients by their enabled key-exchange choices. Clients that disable all TLS_RSA cipher suites are unaffected. It clarifies that these are the TLS 1.0 through TLS 1.2 suites without ECDHE. Clients limited to TLS 1.3 are also unaffected.
The distinction prevents an overly broad reading of the word RSA. The implementation file separately describes ECDHE key agreement, where the server generates an ephemeral elliptic-curve key pair and signs it. That signature may use ECDSA, Ed25519, or RSA. An RSA signature in that path does not make it the RSA key-exchange operation repaired here.
A configuration assessment therefore needs the actual cipher-suite category. Looking only for the presence of an RSA certificate or the letters RSA in a suite name can conflate two uses of the algorithm. The advisory's explicit exclusion of ECDHE from the affected TLS_RSA category supplies the relevant distinction.
I find this precision useful when reading security notices. A broad instruction to avoid a cryptographic algorithm would obscure the actual code path. The notice instead gives conditions that can be connected to the selected protocol and the checked assertion in the patch.
HTTPS callers inherit the handshake behavior
Applications do not need to call the key-agreement code directly to encounter this issue. The announcement names net/http clients performing HTTPS requests because their TLS connection setup uses the affected implementation. A service whose networking is entirely outbound still has a relevant exposure boundary when it processes peer-controlled handshake data.
The released toolchains carry the repaired standard library code. Existing applications need builds that incorporate that implementation before their deployed executables benefit from it. Changing an application-level error handler cannot make the old unchecked assertion perform the missing type validation.
The release's substantive change is therefore a specific validation step at the point where it is needed. Certificate acceptance and negotiated parameters must agree on the public-key operation. Go 1.16.6 checks that agreement before invoking RSA encryption and returns an error when the key type cannot support it.