Suricata

https://github.com/OISF/suricata/pull/9545

Sascha Steinbiss wrote:

JA4+ is out (see https://blog.foxio.io/ja4-network-fingerprinting-9376fe9ca637 and https://github.com/FoxIO-LLC/ja4). Similar to JA3, we should include the fingerprints in the EVE output for TLS and QUIC and also provide it in a buffer for detection.

A good approach would be to implement JA4 (the TLS client fingerprint) first and decide whether the others in the JA4+ suite can be implemented in Suricata due to licensing/patents.

Thanks for implementing this! Feel free to reach out to me with any questions on licensing or implementation. Arkime is another open-source network tool that is implementing all of JA4+ as a switch that can be enabled/disabled.

John Althouse wrote in #note-4:

Thanks for implementing this! Feel free to reach out to me with any questions on licensing or implementation. Arkime is another open-source network tool that is implementing all of JA4+ as a switch that can be enabled/disabled.

Thanks for getting in touch! Yes, I still have some question. I am not sure about being able to implement all of JA4+ though. If I implement all fingerprints a part of Suricata's codebase, then they would be GPL with the rest of Suricata's code. The GPL makes no distinction between commercial vs. noncommercial use. Anyone could take, fork, modify this code and use it in any context, as long as modifications stay free in the sense of the GPL. Any switch that is enabled/disabled at runtime or compile time will not change that.

An alternative approach would be include JA4+ code written by me under a different license in Suricata. That is, the parts of the code that generate JA4+ would be, for instance, FoxIO licensed while the rest is GPL. This would obviously be a decision that I would like to raise with the rest of the developers, ideally before starting to implement anything ;)

With my Debian Developer hat on, I would also like to point out that a license that restricts commercial use would at least make the JA4+ feature non-free under Debian's Free Software Guidelines (https://www.debian.org/social_contract#guidelines). That means that Debian maintainers need to either patch this feature out in the Debian packaged version of Suricata or leave it in, but move Suricata to Debian's "non-free" section. This section needs additional action by a user to make the software there installable.

I would be happy to receive some additional input on how to proceed here. I would be up to implement more of JA4+ as I think it's very useful to have widely available fingerprinting capabilities across tools, but since this would be something I do in my spare time I'd like to make sure my contributions are actually useful. Maybe you could give some more insight on how you would envision Free software like Suricata, Zeek, ... to implement the fingerprints -- thanks!

John Althouse wrote in #note-4:

Thanks for implementing this! Feel free to reach out to me with any questions on licensing or implementation. Arkime is another open-source network tool that is implementing all of JA4+ as a switch that can be enabled/disabled.

I appreciate the approach Arkime is taking and think it will work great for other NSMs like Zeek. Unfortunately, I don't think this approach will work for Suricata, Snort or other signature based network monitoring solutions.

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.

Jo Johnson wrote in #note-6:
[...]

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.

True, that's a practical issue I hadn't considered yet either.

It would be good if all the fields required for JA4 can be exported in the EVE TLS event meta-data, that way JA4's (or alternative fingerprint algorithms) can be computed independently of Suricata.

We, at rapid7, are collecting passive TLS survey data, and we'd like to be able to perform some analysis and investigations on that data in bulk. Applications include eg. detecting the use of weak ciphers. It's impossible to tell from a sha256 hash, whether any weak cipher was used.

Another problem we had with JA3 was that the hashes soon became useless once randomization was used, and in order to make sense of the data we're receiving, we've had to look into the JA3 strings and normalize them. So actually, over the long term, the hashes were less useful than the raw data about the handshake parameters.

I agree that these data should also be in the TLS and QUIC EVE metadata; very useful and also currently IIRC not consistent in terms of completeness and format. I'd consider that a separate feature though...