TLS 1.3 for Every Internal Connection — and What Comes Next

How we upgraded the Riptides kernel module from TLS 1.2 to TLS 1.3, and why that change is the foundation for everything we are building toward.

Most internal mTLS deployments were not designed to be wrong. They were designed for the constraints of the time: TLS 1.2, a negotiated cipher suite, certificates from an internal CA with comfortable lifetimes. That is a defensible baseline, and for years it was good enough.

It is no longer good enough — and the problem is not dramatic. It is structural. TLS 1.2 does not mandate forward secrecy. It allows cipher suite combinations that have known weaknesses. It carries a negotiation surface large enough that misconfiguration is common and often undetected. And its handshake structure was not designed with the cryptographic landscape of 2025 in mind.

We have upgraded the Riptides kernel module to TLS 1.3. This post explains what changed, why each change matters for internal workload traffic specifically, and what this upgrade unlocks going forward.

Why Internal mTLS Needed This

There is a reasonable assumption that internal east-west traffic is lower risk than public-facing TLS. It never leaves the cluster, the VPC, the datacenter. But this assumption breaks down in ways that matter.

Compromised infrastructure components. A rogue node, a misconfigured network tap, a compromised CNI plugin — internal traffic can be captured at the hypervisor or switch layer, not at the perimeter. The capture happens silently, long before anyone raises an alert.

Supply chain persistence. An adversary who lands in your environment via a compromised build artifact does not need to exfiltrate data immediately. A low-volume, low-frequency tap on internal handshake transcripts is operationally quiet and extremely valuable. The services most worth targeting — authentication, secrets management, inter-service RPC — are precisely the ones running on long-lived connections with rarely rotated credentials.

Long-lived credential exposure. TLS 1.2 does not enforce forward secrecy. A session key derived from a static RSA certificate is retroactively recoverable if the certificate is later compromised. For internal services with multi-year certificate lifetimes — which describes most environments that have not adopted automated rotation — every recorded session is a liability.

The question is not whether internal traffic is harder to reach than perimeter traffic. It is whether the information in that traffic is worth the effort for an adversary who is patient and well-resourced. For authentication and RPC traffic, the answer is clearly yes.

What Changed in the Kernel Module

Riptides performs TLS interception and enforcement at the kernel level via kTLS. The kernel module handles the handshake; the userspace daemon validates the SPIFFE SVID presented by the peer; the connection is accepted or torn down before any application bytes flow. No changes are required to application code.

Until this release, the kernel module’s TLS implementation was limited to TLS 1.2. That constraint was a function of the underlying TLS library, which had no TLS 1.3 support and no active development path toward it. We replaced that library — keeping implementation specifics minimal, but the selection was driven by a clear set of requirements: active maintenance posture, production-grade TLS 1.3 support, and a memory footprint compatible with kernel context.

We have upgraded the kernel module to TLS 1.3.

TLS 1.3 is not an incremental improvement over 1.2. The protocol was rearchitected. The changes that matter most for internal workload traffic:

Forward secrecy is mandatory. Every session uses an ephemeral key exchange. There is no code path in TLS 1.3 that allows a static certificate key to decrypt recorded traffic. This eliminates an entire class of retroactive exposure that TLS 1.2 leaves open.

The cipher suite surface is dramatically reduced. TLS 1.3 ships with five cipher suites, all of which provide authenticated encryption (AEAD). The negotiation attack surface that plagued TLS 1.2 deployments — BEAST, POODLE, FREAK, and the long tail of downgrade attacks — structurally does not exist.

Fewer round trips. The 1-RTT handshake reduces latency for short-lived connections. For high-frequency internal RPC patterns with connection reuse, the reduction per connection is small but accumulates at scale.

A clean extension model. The key_share extension in TLS 1.3 is the designed integration point for new key exchange algorithms. This is not incidental — it is what makes the next step possible.

Post-Quantum mTLS: The First Use of the New Foundation

The TLS 1.3 upgrade is a prerequisite, not a destination. The first capability it enables is automatic post-quantum mTLS for internal workloads.

When pqc_hybrid is enabled in the Riptides configuration, the kernel module negotiates a hybrid key exchange on every mTLS handshake: X25519 for classical security, ML-KEM-768 for post-quantum security. The session key is derived from both; neither alone is sufficient to reconstruct it.

tls:
  min_version: "1.3"
  pqc_hybrid: true

No application changes are required. SPIFFE SVID validation, workload attestation, and rotation policy are all unchanged. If a peer does not support the hybrid group — a legacy endpoint, a third-party service — Riptides falls back to X25519 only and logs the event.

The threat model this addresses, and the full reasoning behind the hybrid construction and algorithm selection, deserves its own treatment. We will cover that in a follow-up post — including the harvest-now, decrypt-later attack pattern and what the NIST PQC standardization timeline means for infrastructure teams making decisions today.

Deployment Considerations

TLS 1.3 minimum version is now the default for new deployments. Existing deployments can set min_version: "1.3" to enforce it. If you have services that only speak TLS 1.2, the Riptides telemetry pipeline will surface them as fallback events — a useful audit of your internal TLS posture.

PQC hybrid mode is opt-in. The key share size increase with ML-KEM-768 (~1.1 KB versus ~32 bytes for X25519) adds measurable overhead for very high connection-rate workloads with no connection reuse. For most internal RPC patterns, the impact is negligible. Benchmark before enabling cluster-wide.

Certificate rotation is independent. The TLS 1.3 upgrade and PQC hybrid mode both protect session keys. They do not change SVID validity windows. If you are running 90-day or longer SVID lifetimes, that is a separate and worthwhile conversation — short lifetimes matter regardless of what the key exchange is doing.

The Right Layer to Fix This

The alternative to solving TLS hygiene at the kernel module layer is asking every service team to instrument their TLS stack independently. That produces patchy coverage, inconsistent cipher suite enforcement, and no visibility into which workloads have and have not been upgraded. One configuration change in Riptides covers every managed workload.

TLS 1.3 is the baseline. Post-quantum key exchange builds on it. Both are available now.

Questions about the TLS 1.3 rollout or PQC mode? Reach out at riptides.io or get in touch for a demo.

---

If you enjoyed this post, follow us on LinkedIn and X for more updates. If you'd like to see Riptides in action, get in touch with us for a demo.