CVE-2023-45287

What it actually does

A timing side-channel vulnerability exists in the RSA implementation within the crypto/tls library of Go versions prior to 1.20. The use of the non-constant-time math/big library for RSA key exchanges can leak timing information during the PKCS#1 padding removal process. A network-adjacent attacker capable of making precise timing measurements over many TLS handshakes could statistically analyze these variations to recover bits of the session key, ultimately compromising the confidentiality of the TLS session.

Why it matters to the business

This vulnerability could allow a sophisticated attacker to decrypt encrypted network traffic, potentially exposing sensitive data such as customer information, financial records, or intellectual property. A breach of this nature can lead to significant financial loss, regulatory penalties, reputational damage, and erosion of customer trust. The high confidentiality impact rating highlights the risk of a severe data breach.

How an attack unfolds

An attacker would first establish a network position that allows for precise timing measurements of a target server, such as a man-in-the-middle or by directly connecting to the service. The attacker then initiates a very large number of TLS handshakes using RSA-based key exchange ciphers. By meticulously measuring the server's response time for each handshake, the attacker gathers data on timing variations. These variations, caused by the non-constant-time cryptographic operations, are subjected to statistical analysis. Over millions of connections, this side-channel analysis can leak enough information to reconstruct the session key, enabling the attacker to decrypt captured traffic from that session.

How to fix it

The vulnerability is fully remediated in Go 1.20 and all subsequent versions, which use a constant-time RSA implementation. To fix this vulnerability, all Go applications that handle TLS must be recompiled using the Go 1.20 toolchain or a later stable version. After recompilation, the new, patched binaries must be deployed to replace the vulnerable instances in all environments.

How to confirm the fix worked

To validate the fix, you must identify the Go version used to compile your application binaries. This can be accomplished by running `go version -m /path/to/your/binary`. Any binary that reports a Go version earlier than `go1.20` is vulnerable and must be recompiled. Simply scanning for TLS configurations is insufficient, as the vulnerability lies within the application's cryptographic implementation, not the protocol configuration.

Typical attack path

1. Attacker identifies a public-facing service built with a vulnerable version of Go (prior to 1.20).
2. Attacker establishes a low-latency network position to the target server to ensure precise timing measurements.
3. Attacker initiates a massive number of TLS handshakes, forcing the use of an RSA key exchange.
4. The attacker's client records the precise time taken for the server to complete each handshake.
5. Attacker performs offline statistical analysis on the collected timing data to exploit the side-channel and recover session key bits.
6. Once the session key is reconstructed, the attacker decrypts previously captured network traffic associated with that session.

How to detect it

Detecting a historical compromise is exceptionally difficult, as the attack traffic consists of what appear to be legitimate TLS handshakes. The only potential, low-fidelity indicator would be an anomalously high rate of new TLS connections from a single source IP over an extended period. However, this pattern is not unique to an attack and can be generated by benign services like health checkers or load balancers. The attack leaves no distinct logs, error messages, or file-based artifacts on the vulnerable server.

What your security team should do

• Immediately inventory all applications built with Go and identify which version of the Go toolchain was used for compilation.
• Prioritize recompiling public-facing services and any internal services that handle sensitive data using Go 1.20 or a newer stable version.
• Update CI/CD pipelines and developer environments to use only supported and patched versions of the Go toolchain to prevent recurrence.
• Because this attack is difficult to detect, prioritize patching over detection efforts.