You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Zeek implementation of JA4 is not conform the spec, when the first ALPN is an empty string.
The following snippet is from the Zeekscript source, that first checks if the alpns field is present and subsequently checks if there are any alpns in the list.
local alpn: string = "00";
if (c$fp$client_hello?$alpns && |c$fp$client_hello$alpns| > 0) {
alpn = c$fp$client_hello$alpns[0][0] + c$fp$client_hello$alpns[0][-1];
}
Now consider a situation where alpns is a list with an empty string, [""]. This passes the check and results in alpn = "" instead of alpn = "00".
The result is a malformed JA4 hash that is two characters short in the first section.
The Python implementation does include a len(alpn) > 2 check, but only to truncate ALPNs that are too long. The Python impl is therefore probably also prone to this bug.
The Zeek implementation of JA4 is not conform the spec, when the first ALPN is an empty string.
The following snippet is from the Zeekscript source, that first checks if the
alpnsfield is present and subsequently checks if there are any alpns in the list.Now consider a situation where alpns is a list with an empty string,
[""]. This passes the check and results inalpn = ""instead ofalpn = "00".The result is a malformed JA4 hash that is two characters short in the first section.
The Python implementation does include a
len(alpn) > 2check, but only to truncate ALPNs that are too long. The Python impl is therefore probably also prone to this bug.Unfortunately, I cannot share a PCAP with sample traffic at the moment.
While digging into this issue, I also found that: