The Ghost in the Handshake: Traefik & Go mTLS Bypass in HTTP/3

In the modern infrastructure landscape, we have stopped trusting the network. We don't rely on IP allowlists or VPNs anymore; we rely on Mutual TLS (mTLS). It is the cryptographic equivalent of a biometric scan at every door. You present your client certificate, the server validates it against a trusted Certificate Authority (CA), and only then are you allowed in. Traefik, the darling of the cloud-native world, is often the bouncer standing at that door, managing ingress for thousands of microservices.

But here is the dark joke: security and performance are mortal enemies. To make the web faster, we invented HTTP/3 (powered by QUIC), which runs over UDP and promises lightning-fast connections. One of its tricks is 0-RTT (Zero Round Trip Time) or optimized session resumption. It remembers you so you don't have to do the heavy cryptographic lifting every single time you connect.

CVE-2025-68121 is what happens when that memory is a little too trusting. It turns out that under specific conditions in HTTP/3, Traefik (via Go's crypto/tls) forgets to check if your ID is still valid when you resume a session. It just remembers that you were cool five minutes ago. This is a catastrophic failure for any environment relying on mTLS for zero-trust enforcement, effectively turning your fortress into a public park.

The root cause lies deep within the Go programming language's standard library, specifically in how crypto/tls handles TLS 1.3 session resumption. In a standard TLS handshake, the server looks at its configuration (ClientCAs), requests a certificate from the client, validates the signature, and checks the chain of trust. This is expensive in terms of CPU and latency.

To speed this up, TLS 1.3 allows Session Resumption. The server gives the client a "ticket" after the first handshake. The client can present this ticket later to say, "Hey, we just talked, let's use the same encryption keys." The logic flaw here is a classic caching error. The Go library assumed that the server's configuration—specifically the list of trusted CAs—is immutable (unchanging) for the lifespan of that ticket.

However, Traefik is a dynamic proxy. It reloads configurations on the fly. You might rotate your CAs, revoke a compromised root, or change the ClientAuth policy from VerifyClientCertIfGiven to RequireAndVerifyClientCert. The vulnerability is that during resumption, Go checked the validity of the ticket, but it failed to re-verify that the client's certificate chain is trusted by the current ClientCAs configuration. It blindly trusted the state from the previous handshake.

The vulnerability exists in the server_handshake_tls13.go file within the Go standard library. When a client attempts to resume a session (using a Pre-Shared Key or PSK), the server code needs to decide if the old session is still safe to use. The flaw was an omission: the code verified the cipher suites and the SNI, but it didn't verify that the ClientCAs pool hadn't changed.

Here is a conceptual simplification of the vulnerable logic versus the fix:

// VULNERABLE LOGIC (Simplified)
func (c *Conn) handleResumption() {
    session := c.decryptTicket()
    
    // The code checks if the certificate matches, but...
    // It DOES NOT check if the CA that signed this cert 
    // is still in the config.ClientCAs pool.
    if session != nil {
        c.resumeSession(session)
        return // Bypass complete!
    }
    // Fallback to full handshake
}

The fix, introduced in Go 1.24.13 and 1.25.7, adds a critical check. It forces the library to compare the trust anchors used in the original session against the current configuration. If they don't match (e.g., the admin removed a CA), resumption is rejected, forcing a full handshake where the client will fail authentication.

// PATCHED LOGIC
func (c *Conn) handleResumption() {
    session := c.decryptTicket()
    
    // New check: Is the peer's certificate chain still valid 
    // according to the CURRENT config?
    if !c.config.ClientCAs.Contains(session.peerCertChain[0]) {
        // Config changed! Reject resumption.
        return c.doFullHandshake()
    }
    
    c.resumeSession(session)
}

This highlights a dangerous pattern in stateful protocol implementation: Assumption of Static State. In dynamic environments like Kubernetes ingress controllers, nothing is static.

Let's construct a realistic attack scenario. Imagine you have a Traefik ingress controller protecting a sensitive admin panel. It requires a client certificate signed by AdminCA.

Step 1: The Legitimate Entry. The attacker obtains a valid client certificate. Maybe they compromise a low-level employee's laptop, or maybe they were an employee. They connect to the Traefik instance using HTTP/3. The handshake succeeds. Traefik issues a TLS Session Ticket. The attacker now has the "handstamp."

Step 2: The Lockout. The security team detects the compromise or the employee is fired. They update the Traefik configuration. They remove AdminCA from the trust store or revoke the specific certificate. They push the new config. Traefik reloads hot, without dropping connections.

Step 3: The Bypass. The attacker, holding the Session Ticket, reconnects. Instead of initiating a new handshake (which would fail because their cert is now untrusted), they send the Session Ticket in the ClientHello.

Because of CVE-2025-68121, the Go TLS stack sees the valid ticket and thinks, "Oh, I know you." It resumes the session using the old trust context. The attacker is now authenticated and inside the admin panel, despite their certificate authority being explicitly removed from the server's configuration. The "lock" was changed, but the "key" (the session ticket) still works.

This vulnerability is rated CVSS 10.0 (Critical) for a reason. mTLS is rarely used for public websites; it is used for high-security, internal communications (Service-to-Service) and administrative access. It is the bedrock of "Zero Trust."

If you are running a service mesh, a bank API, or a corporate VPN replacement that uses Traefik with HTTP/3 enabled, your revocation lists are essentially broken for anyone with a session ticket. An attacker with persistence can maintain access indefinitely by constantly refreshing their session ticket, even after you have supposedly locked them out.

Furthermore, because this is an issue in the underlying Go library, it's not just Traefik. Any Go-based HTTP/3 server that relies on ClientCAs for authentication and allows configuration updates (common in microservices) is vulnerable. The impact is total compromise of the authentication layer.

The remediation path is straightforward but urgent. The flaw is in the binary's standard library, so you cannot just change a config file—you must update the software itself.

For Traefik Users: Update immediately to v2.11.37 or v3.6.8. These versions were built with the patched Go version. If you cannot update immediately, your only effective workaround is to disable HTTP/3 entirely in your Traefik static configuration. This forces clients to use HTTP/1.1 or HTTP/2, which do not trigger this specific code path in the same way.

For Go Developers: If you maintain your own Go-based servers, you must recompile your application with Go 1.24.13, Go 1.25.7, or Go 1.26.0-rc3. Simply restarting your service isn't enough; the binary itself carries the vulnerable crypto/tls logic. Check your go.mod and your CI/CD pipelines immediately.