The JA3 rules from the Emerging Threats provider have not been available for use with IPFire historically because they required the NSS crypto library package to be installed.
With the release of Suricata-7 in CU185 the NSS dependency was replaced by RustCrypto, which is available in IPFire.
When CU185 was released it was missed to mention in the release notes that the JA3 ruleset can now be selected again without getting error messages about JA3 being disabled.
Hi Adolf, is JA4 not also available meanwhile ?
Best,
Erik
So JA4 is mentioned in the 7.0.10 suricata docs so it looks like it should be available also.
However there was a post thread that included some question marks about the licencing aspects
https://community.ipfire.org/t/ja4-fingerprinting/11318
Looking at the FoxIO JA4 github site then it says the following
JA4: TLS Client Fingerprinting is open-source, BSD 3-Clause, same as JA3. FoxIO does not have patent claims and is not planning to pursue patent coverage for JA4 TLS Client Fingerprinting. This allows any company or tool currently utilizing JA3 to immediately upgrade to JA4 without delay.
JA4S, JA4L, JA4H, JA4X, JA4SSH, and all future additions, (collectively referred to as JA4+) are licensed under the FoxIO License 1.1. This license is permissive for most use cases, including for academic and internal business purposes, but is not permissive for monetization. If, for example, a company would like to use JA4+ internally to help secure their own company, that is permitted. If, for example, a vendor would like to sell JA4+ fingerprinting as part of their product offering, they would need to request an OEM license from us.
All JA4+ methods are patent pending.
This licensing allows us to provide JA4+ to the world in a way that is open and immediately usable, but also provides us with a way to fund continued support, research into new methods, and the development of the upcoming JA4 Database. We want everyone to have the ability to utilize JA4+ and are happy to work with vendors and open source projects to help make that happen.
This means that IPFire can make JA4 available but not JA4+ as it would need to communicate via a plugin type of approach and I believe that is not available for Suricata at the moment.
There is currently no ja4 ruleset in the Emerging Threats Community ruleset and I believe that is also the case for Emerging Threats Pro and this comment was made in a fetaure request for ja4 in suricata.
This hits an issue the Suricata community has been dealing with re: Lua scripts. If a given rule can’t work out of the box everywhere, it won’t make it into shared signature collections like ET OPEN or ET PRO. This won’t work until it can be a plugin delivered with rules (A huge engineering task), or the licensing changes.
So it looks like Suricata can work with ja4 but none of the signature makers used in IPFire are using ja4 due to the licencing question marks.