A provider mirror copies a TLS 1.3 session to your sensor - what can that sensor still tell you?
answer
- the copy is out of band, always
- everything before keys exist is readable
- sizes, timings, directions, one name
- TLS 1.3 encrypts the certificate too
- proves bytes moved, not what they were
basics
~20 sMetadata only: the five-tuple, byte and packet counts in each direction, start, duration, record sizes and timing, the client handshake fingerprint, and the SNI when it is present. The payload stays encrypted, and in TLS 1.3 so does the server certificate.
solid answer
~50 sA mirror hands the sensor a copy of packets that have already left, so the sensor is an observer, never a participant. From a TLS 1.3 session it keeps the ClientHello, which is still in the clear unless encrypted client hello is used: offered versions, cipher suites, supported groups, the ALPN list offered and the `server_name` (SNI). Hashing those ordered fields gives a client fingerprint that identifies the TLS stack. Everything from the key exchange onward is encrypted, including the server's certificate - a real loss compared with TLS 1.2, where the subject and issuer crossed in the clear. What is left is volumetrics: bytes each way, duration, record sizes and their timing, which is how beaconing shows up. That record proves bytes moved in a direction to an address. It never proves what the bytes were.
code
json · 15 lines{
"flow_id": 8812433,
"start": "2026-03-11T02:14:07Z", "duration_s": 5382,
"src": "10.42.7.19", "src_port": 51422,
"dst": "203.0.113.44", "dst_port": 443, "proto": "TCP",
"bytes_to_server": 41822190, "bytes_to_client": 118442,
"tls": {
"version": "TLS 1.3",
"sni": "assets.example-cdn.net",
"alpn_offered": ["h2", "http/1.1"],
"client_fingerprint": "e1f4c9a2...",
"server_certificate": "not observed - encrypted in TLS 1.3"
},
"payload": null
}go deeper
Be ready to list what survives encryption - addresses, ports, byte counts, duration, record timing, the client fingerprint, the SNI - and to say plainly that the payload does not.
Explain why the split falls where it does: the ClientHello precedes any key, and in TLS 1.3 everything after the key exchange, including the server certificate, is encrypted.
Show the discipline of stating what a flow record supports and what it does not, and of catching the moment a colleague turns bytes moved into this is what left.
Own the fact that the readable residue is a decaying asset as encrypted client hello and QUIC spread, and decide what you invest in as it decays rather than re-buying the same sensor.
## What a mirror actually delivers In a cloud virtual network there is no wiring closet, so there is nowhere to put a physical tap. The equivalent is a provider mirror session: the fabric copies packets from a workload's virtual NIC and delivers the copy to a sensor instance. Hold on to the word *copy*. The original packet has already gone on its way; the sensor is looking at a photograph of it. That is a genuine strength - a sensor that crashes, saturates or misparses cannot break production - and it is exactly why the sensor can never negotiate anything. It is not an endpoint of the session, it holds no key share in it, and it cannot substitute a certificate. It is out of band by construction, and no configuration promotes it. ## What a TLS 1.3 handshake still leaks past it The ClientHello travels before any keys exist, so it is readable unless encrypted client hello hides it. It carries the offered protocol versions, the cipher-suite list, the supported groups and key share, the ALPN protocols the client is willing to speak, and the `server_name` extension - the SNI, the hostname the client asked for. Fingerprinting schemes hash that ordered set of fields into a short identifier for the client's TLS implementation: a system library, a browser build, a language runtime's default client. That is useful precisely because implants rarely bother to imitate the stack of the software they hide behind, so a workload whose sessions all carry one fingerprint and suddenly carries a second is worth a look. Then the key exchange completes and the rest of the handshake is encrypted under handshake keys. In TLS 1.3 that includes the server's EncryptedExtensions - so the *negotiated* ALPN, as opposed to the offered list - and the server's Certificate. Sensors that were designed against TLS 1.2 used to read the certificate subject, issuer and validity dates off the wire and pivot on them. In TLS 1.3 that field is gone from the passive view. The readable residue shrank, and it keeps shrinking: encrypted client hello removes the SNI, and QUIC moves the whole thing to UDP with the handshake protected and the transport headers obscured. ## The residue, and what it supports What the sensor can still write down for a mirrored session is roughly: source and destination address and port, protocol, packet and byte counts per direction, start and end timestamps and duration, the sizes of the encrypted records and the intervals between them, the TLS version, the client fingerprint, and the SNI where present. Take a record showing 41 MB to an external address and 118 KB back over ninety minutes on port 443. The claims that record supports are narrow and worth stating out loud: bytes moved, in that volume, in that direction, between those addresses, over that window, from that virtual NIC. The claims it does not support are the ones people write into reports anyway: that the bytes were customer data; that the sender was an implant rather than a backup agent or a log shipper; that the destination is the organisation named in the SNI. SNI is a value the *client* chose to send. It names what the client asked for, and it is not corroboration of anything by itself. The timing residue is often the most valuable part. Sessions of near-identical size at a near-constant interval with a little jitter look like a scheduled check-in whatever is inside them, and that pattern survives encryption because encryption hides content, not shape. ## Where the adversary sits in this An implant author reads the same list. So the session runs on 443, offers h2 like everything else, and picks an SNI that looks ordinary in your estate. Volumes get shaped to resemble uploads you already do. If the client supports it, the traffic moves to QUIC, or hides the name with encrypted client hello, and the last cleartext identifier you had disappears. Nothing about the mirror changes; the value of what it delivers just decays. ## The price This is not something the passive position can spend its way out of. Storing more of the same ciphertext with full packet capture costs storage and buys replayability of metadata, not decryption. Enriching the picture means leaving the passive position for a terminating one, which is a different architecture with a different bill and a different owner. So the working discipline is to treat the residue as the asset it is: baseline it per workload, keep it long enough to bound an incident window, and never let a coverage claim quietly promote *bytes moved* into *this is what left*.
- The SNI says a well-known content network. How much does that narrow the destination?Barely. SNI is a client-supplied field in a cleartext ClientHello - it records what the client asked for, not what it reached, and on shared fronting-capable infrastructure the TLS-terminating service and the eventual backend need not be the same party. Treat it as a lead to corroborate against the destination address, resolution records and the endpoint, never as proof of who received the bytes.
- The same session runs over QUIC instead of TCP 443. What changes for your sensor?You see a UDP flow. The handshake is protected and much of what you used to fingerprint moves under encryption, the transport headers are obscured, and connection migration can change the client address mid-session without a new handshake. You keep volumetrics, direction, duration and timing - the shape survives - but the cleartext identifiers you were leaning on largely do not.
- Would full packet capture on the mirror recover the payload?No. It stores the same ciphertext at much higher cost. Full capture is worth buying when you want to re-derive metadata you did not think to extract at the time, or to prove exactly what crossed the wire byte for byte - but the bytes stay opaque. Paying for storage does not buy a decryption you never had the keys for.
It is the sorting-office camera. You can see who posted a parcel, how big it was, how often they came and what address label it carried - and never what was inside.
saying these in an interview costs you the question
- Says the sensor reads the server certificate subject in TLS 1.3
- Treats the SNI as proof of the real destination
- Assumes full packet capture means readable payload
- Claims byte counts show what data was taken
- Thinks a mirror can be reconfigured to intercept