Flashbots Nested TLS Fixes Attestation Bottleneck for TDX Deployments

39ms per TDX attestation generation, and it serializes across all guests on the same host. That's the bottleneck Flashbots hit when scaling attested TLS connections for confidential computing on GCP. Worse, requesting two attestations concurrently takes almost exactly double the time of one. No parallelism at all.

Why TLS session binding failed for throughput-critical systems

Flashbots originally used Exported Keying Material (EKM) to bind attestation to a TLS session. Security was solid: fresh evidence per session, no replay, CA-signed certificates possible. But the performance cost is brutal when you need many concurrent connections. Each new TLS handshake requires a fresh attestation generation. With TDX quote generation serialized through a single quoting enclave, queueing up multiple attestation requests quickly becomes the bottleneck. For a MEV-boost marketplace serving searchers in TDX, sending large transaction payloads over attested channels to multiple CVM instances demands fast connection establishment. Session binding couldn't deliver.

ACME certificate issuance at boot added another failure point. Every CVM reboot needs a new certificate from LetsEncrypt (or any CA) to keep the private key inside the trust domain. DNS propagation failures, CA rate limits, or downtime can prevent the entire fleet from becoming operational. Flashbots needed a protocol that boots fast without third-party cooperation.

Nested TLS keeps attestation out of the hot path

Flashbots' redesign uses two TLS sessions stacked inside each other. The outer session is vanilla TLS with a long-lived CA-signed certificate (LetsEncrypt). The private key can persist outside the trust domain, so no per-boot ACME. The inner session runs as application data over the outer session, using self-signed certificates that carry an attestation in an x509 extension. The inner TLS private key is generated inside the CVM and destroyed on reboot. Attestation is bound to the inner certificate, not to each connection.

Clients can cache verified inner certificates, making subsequent handshakes fast. No attestation generation in the hot path. The outer session provides domain endorsement (same as HTTPS today); the inner session proves the exact CVM instance. Load balancers work because the client never needs to track which instance it connected to before - it just verifies the attested certificate each time.

Benchmarking shows the performance cost is manageable. The extra TLS-in-TLS handshake adds ~0.35ms (57% over the outer handshake). Overall throughput on a 512KB transfer drops 63.3MBps (15%), but that's dominated by the initial handshake. For sustained application traffic, the double encryption adds 0.6ns per byte (6%). Flashbots judged the trade-off acceptable for their throughput-sensitive deployments.

Trade-offs and what's next

This design gives up freshness guarantees. There is no verifier-provided nonce bound to the attestation. A short validity window on the attested certificate mitigates reuse, but verifiers cannot know exactly how old the attestation is. Flashbots is open to suggestions for proving freshness without making the verifier wait.

Their Rustls-based implementation keeps the API clean: a custom certificate resolver and verifier handle the nested TLS logic. No need to pass around a post-handshake TLS stream like the EKM approach required.

Flashbots now ships this protocol for Buildernet and their MEV-boost marketplace. The nested TLS design is what large, latency-sensitive TDX deployments needed: fast concurrent connections, load balancer friendly, and no per-boot ACME dependency.

Source: Attested TLS Protocol Redesign for Scale and Performance
Domain: collective.flashbots.net