Fingerprinting TLS Clients with JA4 on F5 BIG-IP
What is JA4?
JA4 is a subset of the larger JA4+ set of network fingerprints. JA4+ is a set of simple network fingerprints for a number of protocols that are intended to be both human and machine readable, and replaces the JA3 TLS fingerprinting standard from 2017 (Salesforce is no longer maintaining JA3). Currently, JA4+ includes JA4/S/H/L/X/SSH, or JA4+ for short.
JA4+ Fingerprints
JA4 — TLS Client
JA4S — TLS Server Response
JA4H — HTTP Client
JA4L — Light Distance/Location
JA4X — X509 TLS Certificate
JA4SSH — SSH Traffic
More fingerprints are in development and will be added to the JA4+ family as they are released.
From the previous table, JA4 is the network fingerprint for TLS clients. If you are not familiar with network fingerprinting or TLS fingerprinting, please see John Althouse's excellent article detailing the release of JA4+.
Like JA3 (the predecessor to JA4), JA4 generates the fingerprint through passive analysis of the TLS CLIENT_HELLO packet. Using the information provided in this protocol packet, an easily readable and sharable fingerprint is generated using the following format:
For details on the technical implementation of JA4+ please see the JA4+ github page.
Like all of the other JA4+ fingerprints, the JA4 client TLS fingerprint is broken into three parts in an a_b_c format. The intent of this format is to allow for tracking of similar, but not identical, fingerprints. For example, as John explains in his blog, one vendor already implementing JA4 into their product has "an actor who scans the internet with a constantly changing single TLS cipher. This generates a massive amount of completely different JA3 fingerprints but with JA4, only the b part of the JA4 fingerprint changes, parts a and c remain the same. As such, they can track the actor by looking at the JA4_ac fingerprint (joining a+c, dropping b)".
Implementing JA4 on F5 BIG-IP
While F5 MAY implement JA4 natively into its various products and services at some point, that doesn't help us NOW. So, how can we take advantage of JA4 on F5 BIGIP TODAY? F5 iRules, of course!!!
Following the technical implementation detailed in the JA4+ github documentation, I wrote an iRule to generate JA4 client TLS fingerprints. I will not explain all the details of the iRule, as I tried to include enough inline comments in the iRule itself sufficiently to document what each section of the iRule is doing.
Update Jan 19, 2024: There was a change to the JA4 spec (prior to it's release) that I did not capture in the previous version of this iRule. The iRule has been updated to include this change.
Update April 24, 2024: Removing the inline iRule in favor of a link to the Github repository so readers will also have latest version of the iRule.
JA4 Client TLS Fingerprint iRule:
All of the F5 iRules for JA4 can be found on the DevCentral Github Repository here.
As you may be able to tell from the last few lines of the iRule, the JA4 fingerprint is injected into an HTTP request header. This allows the web server (or, potentially, any other security component in the path) to "see" and act on the JA4 fingerprint. Also, because this HTTP header is injected at HTTP_REQUEST time, it allows other modules in the BIGIP to "see" and potentially act on the JA4 fingerprint.
JA4 Fingerprint in HTTP Request Log
In my next article in this series on JA4, I'll detail how I could use F5 Advanced Web Application Firewall (AWAF) to block traffic based on the "reputation" of a JA4 fingerprint.
Requirements and Caveats
Currently, this iRule uses SSL iRule events and commands. As such, it requires a Client SSL profile to be attached to any virtual server that has this iRule assigned. This also means that SSL/TLS is terminated at the F5 device. Depending on demand, I MAY create another version of this iRule that does not have this requirement.
EDIT: The latest version of the JA4 iRule no longer requires SSL/TLS termination at the F5 BIGIP. It will work whether the SSL/TLS is terminated at the F5 BIGIP or not.
Also, because the iRule is injecting an HTTP header, it requires that an HTTP profile is also assigned to the virtual server. The latest version of the JA4 iRules uses a separate iRule to inject JA4+ fingerprints as HTTP headers. This allows use of the JA4 iRules without needing to modify them. If you do not want to inject the JA4 as an HTTP header, you will then want to log the JA4 fingerprint. Or, you could inject the JA4 fingerprint into the underlying protocol in some way; otherwise, you are simply generating a JA4 fingerprint and doing nothing with it.