Endpoint capture and decryption feature map

PacketSafari supports two related workflows:

• Analyze an existing capture. Upload a PCAP/PCAPNG and, when available, its TLS key log.
• Collect endpoint evidence. An optional, administrator-enabled PacketSafari sensor can inventory applications and connections, run an authorized capture, and try an eligible decryption strategy.

Endpoint support is intentionally provider-specific. Finding a process, recognizing its TLS library, observing secrets, embedding those secrets, and proving that packets decrypt are separate results. PacketSafari does not label a flow verified until captured application records authenticate.

For local administrator workflows, the sensor CLI can perform this chain in one command for one exact process: passive-provider preflight and attachment, native capture, bounded key-log sealing, PCAPNG Decryption Secrets Block embedding, capture reopen, packet authentication, and raw-key cleanup. The receipt reports each stage independently. This orchestration does not make an unsupported provider supported, and it never silently switches to a proxy.

The sensor receipt makes that rule machine-readable: keyAcquisition, keyCustody, evidenceSemantics, decryptionVerified, and evidencePackageReady stay separate. decryptionVerified can be true only when actual acquired session keys authenticate captured encrypted packets. Plaintext-boundary observation is diagnostic evidence, never decryption. evidencePackageReady additionally requires those keys in the PCAPNG or a protected capture-bound companion artifact.

Sensor availability depends on deployment, entitlement, administrator policy, and the downloadable platform build. The qualified Linux rows below describe functional evidence gates; they do not claim production qualification at 1/10/25 GbE or on every NIC, disk, kernel, distribution, or CPU architecture.

How to read the tables

Qualification is exact, not inferred from a marketing version string. A library update, distribution patch, CPU architecture, hardened build, or different application embedding can require a new proof.

Operating-system coverage

Application-tree tuple capture builds a bounded filter from connections owned by the selected process and its exact descendants. Its receipt says tuple projection: another process using the same endpoint cannot be distinguished without per-packet operating-system metadata.

Decryption techniques

Why several techniques are necessary

The default strategy is passive original-path evidence because it does not change the application's network behavior. Cooperative key logging is more stable when an application exposes a supported API. Exact-build passive profiles can help when supported APIs are unavailable or a connection already exists. Managed proxying is an operator-authorized fallback for compatible applications, not a universal decryption mechanism.

For unknown Linux builds, PacketSafari can recognize exact-binary TLS KDF labels and a narrow set of key-agreement return boundaries. Proven exact ABIs capture the bounded agreement output directly; bounded memory comparison remains a fallback. Neither observation is evidence by itself. The sensor derives the supported TLS/QUIC schedule, reopens the capture, and retains material only when application packets authenticate. It does not collect general RNG output.

TLS provider and application coverage

Protocol coverage

The evidence receipt

For an endpoint capture, PacketSafari keeps this chain visible:

process identified
→ connection attributed
→ packets captured
→ provider identified
→ secrets obtained
→ secrets embedded or separately sealed
→ capture reopened
→ each flow cryptographically authenticated

A receipt can therefore say that a provider was found but its adapter was unavailable, that secrets were embedded but required packets were missing, or that one flow verified while another remained inconclusive. It never promotes keys observed to decryption verified.

For split-custody captures, PacketSafari also reopens the protected companion on the endpoint and reconstructs the protocol analyzer from the sealed records. The companion is marked reusable only when those reopened records authenticate the exact capture again. Broad Kerberos/keytab, SMB, and IKE/IPsec imports are reduced to the exact packet-authenticating keys before the companion is written; unrelated candidate keys are not retained.

Important blockers

• A connection established before collection may be unrecoverable if its secrets no longer remain in accessible memory.
• Certificate pinning, mTLS identity handling, applications that ignore proxy settings, and QUIC can block managed proxy mode.
• SIP, hardened runtime, Secure Enclave identities, Windows PPL, anti-tamper, and protected services can prevent access even with administrator approval.
• Application-level or end-to-end encryption remains encrypted after outer TLS is decrypted.
• Missing handshake/application packets make packet verification inconclusive. Direct ephemeral agreement output cannot recover an established forward-secret connection when its required handshake transcript was not captured; if usable traffic-secret/provider state was also erased, the original keys cannot be reconstructed from later ciphertext.
• macOS still requires privileged PKTAP or a signed, installed Network Extension for exact packet-to-process capture and transparent routing. Windows has a lab-only exact-process WFP redirect proof on one Windows 11 x64 build, but production signing, installer lifecycle, embedded-proxy integration, native capture, TLS packet proof, and broader host qualification remain required.

For capture placement and external tools, see How to capture packets. For an existing PCAP plus key log, see Decryption.