JA3 is a popular method to fingerprint TLS connections used by many monitoring tools and IDSs. JA3 focuses on encryption options specified during TLS connection setup to fingerprint the encryption library used by the application.
So in essence the same JA3 fingerprint will match multiple applications, making JA3 unreliable (when used as single feature) to fingerprint traffic. There are several JA3 fingerprint databases available on the Internet you can use to identify (remember with some grade of uncertainty, thus with false positives) client applications or malware applications.
Now suppose you want to ask yourself a different question. What is the nature of the client behind a TLS request. Is this a web browser or a command line application? Is this perhaps Google Chrome or Apple Safari? Identify a browser vs a different type of application can help to prevent (or score differently) connections, not to say that this (usually via JavaScript redirect) is a common practice for WAF (Web Application Firewalls) and Ant-DDoS protection tools to keep away non-browser applications.
Another question to ask is: what is the nature of this communication? Is this a web application (hence HTML/Javascript or similar) or perhaps a TLS VPN where there is no interest in HTTP at all? The latter in particular is very important to spot VPNs in the wild (remember that popular VPN such as OpenVPN are already detected by nDPI, so we want go beyond this type of detection).
In TLS, and in particular in the Client Hello packet, there is more than encryption information that is then ignored by JA3. In order to speedup protocol negotiation, years ago a new TLS extension called ALPN (Application-Layer Protocol Negotiation) has been defined. In essence the client application tells the contacted server what are the protocols the client supports for data exchange, hence after the TLS connection has been setup.
In addition to ALPN there is another extension (not used by JA3) that can help with application fingerprinting and that is the list of encryption protocol versions supported by the client. Contrary to ALPN, this field won’t help understanding the nature of the client application but it can definitively help with fingerprinting.
Let’s look at some examples.
| Apple Safari | Google Chrome | Mozilla Firefox |
|---|---|---|
 |
 |
 |
As you can see, combining ALPN with TLS protocol version, you can fingerprint these three applications. However if you look closer to ALPN you will notice that all three applications support various HTTP versions, ranging from HTTP 1.1 to 2.0 to SPDY.
Let’s now look at some command line tools to see how they behave.
| OpenVPN | curl | git |
|---|---|---|
 |
 |
 |
Both Curl and git commands speak HTTP and thus they interact with a web server, whereas OpenVPN does not have such extension in the ClientHello that means there is not HTTP server on the server side and thus that this is not web browser-like communication but it has a different nature as you would expect from a VPN.
You might now wonder how to do this analysis without using Wireshark, knowing where in the traffic to look at and how to interpret the information. Well, nDPI is the correct answer. Below you can see how nDPI (in particular the output below comes from ndpiReader) fingerprints the traffic
TCP 192.168.2.17:49360 <-> 31.13.86.52:443 [proto: 91.211/TLS.Instagram][cat: SocialNetwork/6][153 pkts/11644 bytes <-> 206 pkts/284089 bytes][Goodput ratio: 13.2/95.2][2.91 sec][ALPN: http/1.1][TLS Supported Versions: TLSv1.3,TLSv1.3 (Fizz)][bytes ratio: -0.921 (Download)][IAT c2s/s2c min/avg/max/stddev: 0/0 23.0/0.1 2756/16 247.4/1.2][Pkt Len c2s/s2c min/avg/max/stddev: 66/66 76.1/1379.1 592/1454 67.7/296.4][TLSv1.2][Client: scontent-mxp1-1.cdninstagram.com][JA3C: 44dab16d680ef93487bc16ad23b3ffb1]
Now that you can have all this analysis ready to use, you can contribute to nDPI development by coding a simple script that can
- Identify HTTP vs non-HTTP based TLS communications
- Fingerprint web browsers using the method shown above.
Enjoy!