skip to content

How does editcap's --inject-secrets option produce a self-decrypting TLS capture for a colleague, and what does the file then carry?

level: middleimportance: nice to knowfreq 6%

answer

  1. a block inside the capture
  2. pcapng only, never pcap
  3. the whole file goes in
  4. discard or extract again

basics

~20 s

editcap --inject-secrets tls,keys.log in.pcapng out.pcapng copies the key log into a Decryption Secrets Block, so Wireshark decrypts without the key-log preference. The file now carries every secret in that log, and classic pcap cannot hold one.

solid answer

~40 s

`editcap --inject-secrets tls,<keylog> <in> <out>` reads the key log and writes its contents into a **Decryption Secrets Block** (DSB) in the pcapng output, which is editcap's default format; Wireshark then decrypts the file without anyone setting `tls.keylog_file`. pcap has no such block, so the capture must stay pcapng. editcap embeds the whole file verbatim, so a log that also holds other sessions' secrets ships them too: inject a per-run log, or first save only this capture's secrets with *File > Export TLS Session Keys* (or use *Edit > Inject TLS Secrets*, which embeds the secrets in use). The type must be `tls`; editcap warns that a PEM or PKCS#12 private key is not a key log and decryption will not work. `--discard-all-secrets` writes a copy without them and `--extract-secrets` pulls them back out.

go deeper

for a junior

Recall that pcapng can carry TLS secrets inside the file, and that editcap --inject-secrets tls,<file> puts them there.

for a middle

Explain the Decryption Secrets Block, why the output must be pcapng, and how --discard-all-secrets and --extract-secrets reverse the operation.

for a senior

Show that you scope what you embed, since editcap copies the whole key log, and that you treat a secrets-bearing capture like the plaintext it unlocks.

for a principal

Decide where self-decrypting captures may be stored and who may receive them, and when a team should share only discarded-secrets copies.

## The problem it solves A decryptable TLS capture normally comes in two pieces: the capture file and a separate key log that the reader must configure in the TLS preference *(Pre)-Master-Secret log filename*. The pieces drift apart, get renamed, or reach a colleague whose profile points at a different file. **pcapng** solves this with a **Decryption Secrets Block** (DSB): a block inside the capture that holds secrets in a declared format. When Wireshark opens a pcapng with a TLS DSB, it uses those secrets as if they came from the key log preference. ## Injecting with editcap `editcap` copies or transforms capture files. The option is: ```bash editcap --inject-secrets tls,run1-keys.log run1.pcapng run1-dsb.pcapng ``` - The argument is `<secrets type>,<file>`. The types editcap knows are `tls`, `ssh`, `wg` (WireGuard) and `opcua`; `editcap --inject-secrets help` lists them. - The option may be repeated to embed several logs. - editcap's default output format is pcapng, so the result can carry the block. A classic pcap file has no block for secrets. - editcap embeds the **contents of the file verbatim**. It does not filter lines down to the sessions in the capture. - editcap checks one obvious mistake: if the file starts like a PEM key or a PKCS#12 bundle, it warns that the file "is not a key log file, but an unsupported private key file" and that decryption will not work. A DSB holds session secrets, never a server private key. ## Doing it from the GUI Wireshark 4.6 has two related menu items: 1. **Edit > Inject TLS Secrets** embeds the TLS secrets the open capture is using into the file, so it decrypts without the separate key log once saved as pcapng. 2. **File > Export TLS Session Keys** writes those same secrets out as a key log file, which you can inject with editcap later. Both start from what Wireshark actually matched to sessions in the capture, which makes them the tidy way to scope what you share. ## What the shared file now carries | Action | What travels with the capture | |---|---| | Inject a per-run key log | Secrets for every session that client made during the run | | Inject a long-lived key log | Secrets for every session in that log, including ones not in this capture | | Edit > Inject TLS Secrets | The secrets Wireshark is using for this capture | | Share capture without a DSB | Nothing beyond the packets | The secrets in a DSB are useless without matching packets, but the packets are right there. **Anyone who can read the file can read the plaintext**, including cookies, bearer tokens and personal data in the requests. Treat a DSB-carrying capture like the plaintext itself. ## Embedded or separate: the trade-off Embedding is not always the right call: - **For embedding:** the secrets cannot drift away from the capture, the reader needs no preference change, and tshark or another Wireshark decrypts the file as-is. - **For keeping them separate:** every copy of an embedded capture is also a copy of the plaintext, including copies made by ticketing systems, chat attachments and backups that nobody tracks. - **A middle path:** share the pcapng without secrets broadly, and send the scoped key log only to the person who needs the payload. ## Removing or recovering the secrets - `editcap --discard-all-secrets in.pcapng clean.pcapng` writes a copy without the DSBs. It does not discard secrets added by `--inject-secrets` in the same command. - `editcap --extract-secrets in.pcapng keys.log` writes the embedded secrets back out; with several DSBs each goes to a numbered file. It cannot be combined with other options except `-V`. - **Edit > Discard All Secrets** removes them from the open file in the GUI. A sensible routine for a test-client investigation: capture, keep a per-run key log, scope the secrets with Inject TLS Secrets, share the pcapng with the people who need the plaintext, and keep a discarded-secrets copy for anyone who only needs timing and headers of the handshake.

  • How do you share a capture whose embedded secrets cover only its own sessions?
    Open the capture with the run's key log configured, then use *Edit > Inject TLS Secrets* and save as pcapng; it embeds only the secrets in use. Alternatively write them out with *File > Export TLS Session Keys* and inject that file with `editcap --inject-secrets tls,<file>`. Either way a long-lived key log never leaves your machine.
  • A colleague needs the capture's timing but must not see the payload. What do you send?
    A copy made with `editcap --discard-all-secrets in.pcapng clean.pcapng`. It keeps every packet, including the cleartext handshake and record sizes, but drops the Decryption Secrets Blocks, so the application data stays encrypted. Check that the colleague's profile has no key log of its own configured that could still match.

saying these in an interview costs you the question

  • Injected secrets cover only the sessions in the capture, whatever the key log held.
  • editcap can embed the server's RSA private key so the capture decrypts anywhere.
  • A pcap file carries injected secrets just as well as pcapng.
  • A capture with embedded secrets is as safe to share as one without.
  • --discard-all-secrets also strips secrets injected in the same command.