TLS

Most production database traffic worth capturing for a migration is encrypted, and DBReplay needs the plaintext statement to translate and replay it — a raw wire capture of an encrypted session is only useful for measuring capture rate and drops. This page covers what TLS 1.3 actually changes, and the routes available when the source is encrypted.

Why TLS 1.3 closes the easy route

Earlier TLS versions permitted RSA key exchange, under which a captured session could, in principle, be decrypted later given the server's private key. TLS 1.3 removes RSA key exchange entirely — every connection uses ephemeral Diffie–Hellman, a fresh key pair per session that is discarded when the session ends. That is perfect forward secrecy, and in TLS 1.3 it is not optional. A wire capture of a TLS 1.3 session is ciphertext, permanently, with no “decrypt it afterwards with the server key” escape hatch.

This is not a reason to avoid TLS 1.3 — it's the correct, modern default for a production database listener. It does mean the capture strategy has to be chosen deliberately rather than assumed.

Available routes

Platform-level clear-text trace

Where the source platform can trace its own decrypted traffic — after the encryption layer has already done its job, before the bytes reach the application — that trace is plaintext by construction, with no key material involved and no client-side instrumentation needed. This route typically needs a specific authorisation grant and the tracing option explicitly enabled; without both, the trace records show only that confidential data was present, not its content. It's worth confirming both are in place well before capture day, and worth confirming with the platform team what the trace costs in overhead at your expected volume — it is a platform-side facility and platform resources are usually metered.

Client-side capture

An alternative route attaches at the client application's own TLS library, seeing traffic before encryption on send and after decryption on receive — so encryption in transit is no longer relevant to what's captured. This route depends on the client platform: it needs a modern Linux kernel and is not available where the client runs on other platforms, or where the application's TLS library can't be resolved (a statically linked or stripped binary, for instance). Client platform is therefore its own qualifying question, separate from what the source database itself runs on.

Client-side capture also has a different failure signature worth planning for: a wire capture fails loudly — drop counters increment, a decoder desyncs, the gap is measurable. Client-side capture fails silently — it only sees the processes it was actually attached to, and a process nobody instrumented produces no traffic and no counter, indistinguishable from one that's simply idle. For this reason, this route always reports which processes were instrumented, reconciled against the expected inventory, rather than relying on drop counters alone to establish coverage.

Timestamps differ between routes

A wire tap timestamps at the point of capture; client-side capture timestamps before encryption on send and after decryption on receive. These are different intervals, not different precisions of the same measurement. The capture method is recorded in every report header, and the two are never mixed within a single comparison.

Practical guidance

If you're unsure which applies to your estate, the troubleshooting page covers confirming what a listener negotiates, and Capture Topology covers where capture needs to sit relative to where your clients actually are.