CVE-2022-30629

What it actually does

The Go crypto/tls library generates predictable, non-random values for `ticket_age_add` in TLS 1.3 session tickets. This allows a passive network observer who can see multiple TLS handshakes from the same client to correlate them by comparing ticket ages during session resumption. This flaw undermines the privacy feature of session tickets, which is intended to prevent the linking of a client's connections over time.

Why it matters to the business

This vulnerability exposes a low-severity information disclosure risk, potentially compromising user privacy. An attacker positioned to monitor network traffic could track a user's activity across multiple sessions with a service, even if the traffic content remains encrypted. This could reveal sensitive behavioral patterns, such as how frequently a user connects to a specific application, which may have reputational or regulatory implications depending on the nature of the service.

How an attack unfolds

An attacker must first gain a position on the network that allows for passive observation of encrypted traffic between a client and a server, both using a vulnerable Go application. The attacker captures the client's TLS handshakes. When a client uses TLS session resumption, it presents a session ticket from a previous connection. Due to the predictable nature of the `ticket_age_add` value, the attacker can analyze the ticket's age across different handshakes and link them to the same client, effectively de-anonymizing and tracking the client's session activity over time.

How to fix it

To remediate this vulnerability, developers must upgrade their Go development environment and recompile the affected applications. Update to Go version 1.17.11 or later, or Go version 1.18.3 or later. After updating the toolchain, rebuild and redeploy all Go applications that use the `crypto/tls` package for TLS server or client functionality.

How to confirm the fix worked

To validate the fix, verify that all relevant Go applications have been recompiled with a patched version of the Go toolchain. You can check the Go version used to build a specific binary by running `go version -m /path/to/your/binary`. The output should indicate a build version of Go 1.17.11+ or Go 1.18.3+. Auditing build pipelines to ensure they use an updated Go version is the most effective way to confirm remediation across an organization.

Typical attack path

1. An attacker gains a passive network monitoring position (e.g., on the same Wi-Fi, an upstream ISP, or a compromised network device).
2. The attacker observes and records TLS handshakes from clients connecting to a server running a vulnerable Go application.
3. A client attempts to resume a TLS session using a previously issued session ticket.
4. The attacker captures the new handshake and inspects the session ticket.
5. By analyzing the predictable ticket age obfuscation, the attacker correlates the new session with a previous one, linking the client's activity over time.

How to detect it

Detecting historical exploitation of this vulnerability is generally not feasible. The attack is passive and involves observing and analyzing encrypted traffic patterns off-path. It does not generate logs, leave artifacts on the host system, or create distinct network signatures. The focus should be on identifying and remediating vulnerable instances rather than searching for evidence of past compromise.

What your security team should do

• Identify all applications in your environment that are built with vulnerable versions of Go (prior to 1.17.11 and 1.18.3).
• Notify application owners and development teams of the required Go version upgrade and recompilation.
• Track the remediation progress to ensure all affected applications are rebuilt and redeployed.