Remote Domain and Port Fingerprinting

• Remote domain and port fingerprinting is a technique that extracts a deterministic TLS ClientHello fingerprint to identify applications behind encrypted traffic.
• It combines the fingerprint string with destination context features such as SNI, IP, and port groupings to create a robust feature vector for disambiguation.
• A weighted Naïve Bayes classifier, validated with high F1 scores in enterprise deployments, effectively attributes processes and flags malware.

Remote domain and port fingerprinting refers to the identification of applications or processes behind encrypted traffic by leveraging network-level features observable from the initial handshake packets, along with destination metadata. In modern enterprise and security monitoring, remote fingerprinting achieves process attribution and malware detection when traditional cleartext identification methods are rendered ineffective by ubiquitous encryption. Recent methods combine detailed protocol fingerprinting—such as constructing deterministic representations of the TLS ClientHello message—with contextual destination features (IP address, port, domain, SNI) and probabilistic classification models operating over large, continuously updated knowledge bases (Anderson et al., 2020).

1. Construction of TLS ClientHello Fingerprint Strings

The process begins with extraction of a deterministic, reversible "fingerprint string" from the unencrypted TLS ClientHello. This string captures the TLS version, the full ordered list of cipher suites, and a selection of protocol extensions, omitting session-specific fields (e.g., nonces, key_share) and raw server_name contents. All GREASE values are normalized to 0x0a0a but positions are preserved. The schema can be formally described as:

$$F = \mathrm{ver}_{f_1} \,\Big\Vert\,\big\Vert_{i=1}^m\mathrm{cs}_i \,\Big\Vert\,\Big(\!\Big(\,\big\Vert_{j=1}^k (\mathrm{ext}_j)\,\Big)\!\Big)$$

where $\mathrm{ver}_{f_1}$ is the TLS version, $cs_i$ are 2-byte cipher suite codes, and $(\mathrm{ext}_j)$ comprises the extension type, length, and extension-specific static data. A total of 21 extensions are preserved according to the published Appendix. This approach ensures the fingerprint is both feature-rich and efficient to construct, suitable for high-throughput environments (Anderson et al., 2020).

2. Destination Context Feature Extraction

For effective disambiguation, the fingerprint string $F$ is combined with destination context features. These include:

• $f_{\text{SNI}}$: the server_name string, if present in ClientHello
• $f_{\text{IP}}$: destination IPv4 or IPv6 address
• $f_{\text{Port}}$: destination TCP port

To generalize across dynamic or unknown endpoints, equivalence-class features are also computed:

• $f_{\text{Domain}}$, $f_{\text{TLD}}$: extracted from SNI via the Public Suffix List
• $\mathrm{ver}_{f_1}$0: derived from destination IP by mapping to BGP Autonomous System (e.g., via GeoLite2)
• $\mathrm{ver}_{f_1}$1: grouping ports into application protocol classes (e.g., HTTPS, IMAPS)

The resulting feature vector is:

$\mathrm{ver}_{f_1}$2

This structured representation enhances the system's ability to resolve ambiguities when hundreds of processes could otherwise share the fingerprint string $\mathrm{ver}_{f_1}$3.

3. Probabilistic Classification via Weighted Naïve Bayes

Classification is performed using a weighted naïve Bayes model. For a given fingerprint string $\mathrm{ver}_{f_1}$4, let $\mathrm{ver}_{f_1}$5 denote the set of observed associated processes. The classifier aims to select

$\mathrm{ver}_{f_1}$6

which by Bayes' theorem (disregarding the denominator), and introducing feature weights, is: $\mathrm{ver}_{f_1}$7 Here, $\mathrm{ver}_{f_1}$8 is the empirical prior for process $\mathrm{ver}_{f_1}$9 conditioned on $cs_i$0, $cs_i$1 the likelihood of feature $cs_i$2 given $cs_i$3, while $cs_i$4 are equivalence-class mappings. All zero counts are Laplace-smoothed by replacing 0 with $cs_i$5. Feature and mapping weights $cs_i$6 are chosen by information-gain-ratio computed over the knowledge base.

4. Knowledge Base Construction and Maintenance

The TLS fingerprint knowledge base (KB) fuses three per-day data streams:

• Network-side: $cs_i$7 from network capture
• Host-side: $cs_i$8 from endpoint agent logs (e.g., AnyConnect NVM)
• Sandbox: controlled packet captures for malware labeling

Records are joined daily on $cs_i$9-tuple and timestamp (within a 5 s window). For each fingerprint $(\mathrm{ext}_j)$0, the KB stores for each process $(\mathrm{ext}_j)$1 the joint distributions and counts over all features and their equivalence classes.

At runtime, $(\mathrm{ext}_j)$2 is looked up: if absent, approximate matching based on Levenshtein distance to known $(\mathrm{ext}_j)$3 is performed, with tie-breaking by prevalence. This approach expedites attribution for previously unseen fingerprints.

5. Empirical Results and Feature Ablation

Empirical evaluation demonstrates that augmenting the fingerprint string with destination context and applying a weighted NB increases process attribution performance. For enterprise deployments:

• Weighted NB achieved $(\mathrm{ext}_j)$4 (process-family) and $(\mathrm{ext}_j)$5 (process) on Site 1 data
• On a second site, $(\mathrm{ext}_j)$6 (family), $(\mathrm{ext}_j)$7 (process)
• For malware detection (sandbox+Site 1): precision $(\mathrm{ext}_j)$8, recall $(\mathrm{ext}_j)$9

Feature ablation indicates $F$0 without SNI and $F$1 without IP, confirming that the framework remains robust when some context is absent. Approximate matching provides $F$2 even for the 0.003% of sessions with totally new fingerprint strings.

6. Operational Considerations and Limitations

KB freshness is essential; a one-month window outperforms longer aggregation, with stale KBs (>30 days) causing $F$3 $F$4 decay. Retaining more than one month of data increases KB size (195 MB to 58 MB) without accuracy gains. Classifier confidence thresholding—e.g., requiring probability $F$5—raises $F$6 to $F$7 but only covers 58% of sessions. KBs are enterprise-specific; cross-enterprise generalization was only assessed within the same organizational context.

Limitations include reliance on host-side logs from desktop OS only (macOS/Windows); mobile/IoT extension would require similar data integration. Emerging protocols such as Encrypted ClientHello (ECH) and novel GREASE variants may reduce visibility into vital features (e.g., SNI, extensions), increasing reliance on the remaining fingerprint string.

7. Significance and Future Directions

Mapping each observed ClientHello into a reversible hex-string $F$8, enrichable with addressing context and processed by real-time, empirically weighted naïve Bayes classifiers supported by continuously-updated knowledge bases, enables accurate process attribution and malware flagging from the very first TLS packet. Observed $F$9 scores above 0.99 on large deployments confirm the viability of this approach in present enterprise networks. A plausible implication is that as encrypted handshake obfuscation methods advance, sustaining high accuracy will require further adaptation of the feature extraction schema or integration of supplementary observable metadata (Anderson et al., 2020).