How Destination Context Changes TLS Attribution

Back to learning

A TLS fingerprint often matches more than one process. That is not an edge case. Applications share TLS libraries, operating-system networking stacks, and default configurations. A process can also produce more than one fingerprint. The fingerprint alone therefore leaves an attribution problem: which of the possible processes made this connection?

Cisco researchers Blake Anderson and David McGrew addressed that problem in the 2020 paper Accurate TLS Fingerprinting using Destination Context and Knowledge Bases. Their system adds the destination address, destination port, and server name to the fingerprint, then uses a weighted naive Bayes classifier to rank candidate processes.

What destination context contributes

Suppose several applications share a TLS fingerprint. Their destinations may still differ. An updater may usually contact a small set of vendor hosts. A browser reaches a much broader set. A service may consistently use a particular port or server name.

The classifier uses those tendencies to disambiguate candidates found in its knowledge base. In plain terms, it asks: given this fingerprint and where the connection went, which known process is the best-supported explanation?

This is more informative than a fingerprint-only lookup, but it is still an inference learned from labelled observations. It is not information encoded inside the fingerprint.

Keep the pipeline visible

packet capture
  -> selected and normalised TLS features
  -> fingerprint
  -> labelled knowledge base lookup
  -> fingerprint plus destination context
  -> ranked process assessment

Each arrow has a different failure mode. Packet loss can truncate the ClientHello. A format or software update can change the fingerprint. The knowledge base can omit a new process or contain stale labels. Destination behaviour can move between CDNs or shared cloud services. The classifier can then give a confident-looking answer from incomplete evidence.

Mercury preserves this boundary in its output: according to the Mercury repository documentation, fingerprint strings appear in a fingerprint object, while optional process-identification results appear in an analysis object. Running the collector does not automatically make an application attribution.

How should research results be read?

The paper reports that adding destination context substantially improved classification performance in the authors' experiments. That result belongs to their datasets, labels, candidate processes, capture conditions, and 2020 evaluation. It should not be copied into a deployment as a universal accuracy promise.

A local deployment needs its own questions answered:

• Does the knowledge base cover the software and versions present here?
• Were labels produced in a way that can be audited?
• How does performance change for unseen processes and new destinations?
• Are server names visible at the chosen capture point?
• What confidence threshold is safe for the action being considered?
• How quickly do browser, library, CDN, and application changes make the data stale?

Destination data also carries privacy and governance consequences. Collect only what the analysis needs, define retention, and restrict who can query it.

Use attribution as evidence, not identity

A ranked process label can help triage traffic, investigate malware, or build an inventory. It should not be treated as proof of a user, device, or intent. Shared infrastructure, proxies, deliberate impersonation, and missing candidates can all mislead the model.

For enforcement, preserve the raw fingerprint and context behind the label, monitor false positives, and choose actions proportionate to the route and consequence. The broader guide to network fingerprint signals and security decisions covers that operational boundary.

Read what Cisco Mercury fingerprinting is for the collector, representation, knowledge-base, and classifier split. For the underlying representation, see inside a Mercury NPF fingerprint.