Beyond JA3/JA4: Introducing nDPI Traffic Fingerprint

Traffic fingerprinting is a hot topic and we have discussed it several times both in this blog and at conferences. There are various fingerprints techniques and probably most of you know JA3/JA4. Let me do a short recap on the subject

  • There are several fingerprints techniques: each of them addresses a different problem and there is not a good/bad fingerprint, but selecting a family or another depends on the use case. For instance in cybersecurity we often need an exact match to spot a malware as accurately as possible, whereas in monitoring we often need the concept of “family” (e.g. Windows) instead of exact (e.g. Win10 or Win11) matches.
  • Fingerprints can lead to false positives as multiple traffic traces can match the same fingerprint. For this reason single fingerprints can be used as indicators but cannot be trusted 100% with some exceptions (e.g. nDPI identifies reliably massive scanners such as zMap or MassScan).

in nDPI we support several de-facto fingerprint such a JA4 and additional nDPI-native such as the OS (Operating System) fingerprint. In our research we have realized that in cybersecurity using a single fingerprint (e.g. JA4) leads to too many false positives making it a “nice to have” rather than a reliable technique. In order to consolidate the fingerprint work we have done so far and move forward on this field, we have introduced in nDPI a new fingerprint named nDPI fingerprint.

Contrary to all the other fingerprinting techniques, nDPI fingerprint is designed to be as accurate as possible and open to changes based on the use-case, as there is no single fingerprint that addresses all use-cases. In order to achieve that this fingerprint combines both layer 4 (operating system detection) and layer 7 (application) fingerprint. This allows to dramatically reduce false positives for instance when detection VPN tunnel X on Android that using JA4 can be mixes with Windows traffic accessing a generic website.

Currently nDPI fingerprint comes in two versions:

  • Client-only (default) designed to identify client applications regardless of the server. This fingerprint is calculated as SHA256(<OS fingerprint>,<JA4>).
  • Client+Server, designed to identify the combination or client-server (e.g. when a malware talks back to its botnet). This fingerprint is calculated as SHA256(<OS fingerprint>,<JA4>,<JA3 server>).

For keeping fingerprint short, the returned fingerprint is cut to the first 16 bytes. The current nDPI natively supports both versions, and the nDPI fingerprint is reported in output:

TCP 192.168.80.96:63358 <-> 78.129.139.4:23576 [proto: 91/TLS][Stack: TLS][IP: 0/Unknown][Encrypted][Confidence: DPI][FPC: 0/Unknown, Confidence: Unknown][DPI packets: 6][cat: Web/5][Breed: Safe][9 pkts/1090 bytes <-> 7 pkts/1880 bytes][Goodput ratio: 54/79][0.63 sec][Hostname/SNI: fuck.rkn][(Advertised) ALPNs: h2;http/1.1][TLS Supported Versions: GREASE;TLSv1.3;TLSv1.2][bytes ratio: -0.266 (Download)][IAT c2s/s2c min/avg/max/stddev: 0/0 90/50 346/190 120/81][Pkt Len c2s/s2c min/avg/max/stddev: 54/54 121/269 550/1454 153/485][Risk: ** Known Proto on Non Std Port **][Risk Score: 50][Risk Info: Expected on port 443][nDPI Fingerprint: 7b8ae0e0763cd4dc7ece67c6231d18a7][TCP Fingerprint: 2_64_65535_41a9d5af7dd3/Android][TLSv1.3][JA4: t13d1516h2_8daaf6152771_02713d6af862][JA3S: f4febc55ea12b31ae17cfb7e614afda8][ECH: version 0xfe0d][Chrome][Cipher: TLS_AES_128_GCM_SHA256][Plen Bins: 33,0,33,0,0,0,0,0,0,0,0,0,0,0,0,16,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,16,0,0,0,0]

In order to demonstrate the advantage of this technique with respect to existing ones, let’s make a simple example. Suppose we want to reliably indenty two popular Android tunnel/VPN applications

With JA4 you can detect them defining in protos.txt the following entries

  • ja4:t13d1713h1_5b57614c22b0_eca864cca44a@X-RPTunnelPlus=2061
  • ja4:t13d171100_5b57614c22b0_3f5d972527c0@HATunnelPlus=2062

Unfortunately if you google the above fingerprints you will find several results that have nothing to do with these VPNs, in essence false positives. With nDPI fingerprint you need to define in the same file:

  • ndpifp:dfa6fdeeef0fd0570c08d3a0d5783d94@X-RPTunnelPlus=2061
  • ndpifp:9550335a5a30986a89620e87fa7f679e@HATunnelPlus=2062

that instead work reliably as it restricts this JA4 only to those Android devices that run the VPN reducing probability that a macOS host with the same JA4 will match too.

In summary, fingerprints are a promising technique for spotting traffic patters. Standard ones such as JA4 have some limitations, nDPI fingerprinting addresses them in an open and patent-free format. Future nDPI fingerprint formats will be implemented, stay tuned.

Share