Scenario 01 · Quantum-safe public edge

"They're recording our TLS today to crack it in 2032."

A bank exposes account and payments APIs on the public internet. A well-funded adversary can't break TLS 1.3 now — so they copy the encrypted traffic and store it, betting that a cryptographically-relevant quantum computer will decrypt it later. The data underneath — balances, PII, signing keys — stays sensitive for decades. "Harvest now, decrypt later" turns today's recordings into tomorrow's breach.

Architecture

A hybrid handshake the recorder can't unwind

The client offers the hybrid group in its ClientHello; ZenoIngress requires it. Captured packets contain only ciphertext whose shared secret is protected by ML-KEM-768 — quantum-resistant by construction.

The setup

Require post-quantum on the listener

Crypto posture is set per listener through the Gateway's tls.options. Setting pq-mode: require-pq rejects any client that won't negotiate the hybrid group, and the TLS floor pins 1.3 (post-quantum key exchange only exists there).

gateway.yaml gateway.networking.k8s.io/v1

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: zeno-gateway
  namespace: zenoingress-system
spec:
  gatewayClassName: zenoingress
  listeners:
    - name: https
      port: 443
      protocol: HTTPS
      hostname: api.bank.example
      tls:
        mode: Terminate
        certificateRefs:
          - name: api-bank-example-tls
        # crypto agility — posture lives here, per listener
        options:
          zenoingress.io/pq-mode: require-pq      # prefer-pq | require-pq | classical
          zenoingress.io/min-tls-version: "1.3"
      allowedRoutes:
        namespaces:
          from: Same

Harvest-now-decrypt-later doesn't stop at the edge. When ZenoIngress re-originates TLS to an HTTPS backend, a BackendTLSPolicy carries the same posture upstream:

backend-tls.yaml zenoingress.io/v1alpha1

apiVersion: zenoingress.io/v1alpha1
kind: BackendTLSPolicy
metadata:
  name: backend-pq
  namespace: default
spec:
  targetRefs:
    - group: ""
      kind: Service
      name: accounts-api
  validation:
    caCertificateRefs:
      - name: backend-ca
        group: ""
        kind: ConfigMap
    subjectAltNames:
      - type: Hostname
        hostname: accounts-api.default.svc
    options:
      zenoingress.io/pq-mode: prefer-pq   # upstream may not be PQ-ready yet

What happens

One handshake, walked through

A PQ-capable client (Chrome/Edge, or curl on a recent OpenSSL) sends a ClientHello advertising the X25519MLKEM768 hybrid key-share group.
ZenoIngress is in require-pq mode, so it selects the hybrid group. A legacy client offering only classical curves is rejected handshake_failure
The shared secret is derived from both ML-KEM-768 (FIPS 203) and X25519. Breaking it requires breaking both — so it's at least as strong as X25519 today, and quantum-safe tomorrow.
TLS terminates at the edge. ZenoIngress re-originates to the backend, negotiating the hybrid group again where supported (prefer-pq) — no plaintext hop in between.
The recorder on the wire captures only ciphertext. With no ML-KEM-768 secret, a future quantum computer has nothing to attack. quantum-safe

Outcome

Every recorded session is quantum-safe

ML-KEM-768FIPS 203, hybrid with X25519

TLS 1.3required floor, per listener

↓ & ↑downstream + re-originated upstream

Why ZenoIngress

Post-quantum key exchange is on by default and enforceable per listener — downstream and upstream — in one memory-safe Rust binary, with no extra TLS-terminating hop to harvest.

Run this yourself

Confirm the negotiated group

Apply the Gateway above, then verify the handshake actually used the hybrid group with a PQ-capable openssl s_client (OpenSSL 3.5+ or a build of aws-lc/BoringSSL with ML-KEM):

terminal — verify post-quantum key exchange

$ openssl s_client -connect api.bank.example:443 \
      -groups X25519MLKEM768 </dev/null 2>/dev/null | grep -i "Negotiated"

Negotiated TLS1.3 group: X25519MLKEM768

$ # a classical-only client is refused under require-pq:
$ openssl s_client -connect api.bank.example:443 -groups X25519 </dev/null
...:ssl/tls alert handshake failure:...