feat(suricata): carry the JA4 TLS client fingerprint into the report - #29
Open
mjbradford89 wants to merge 1 commit into
Open
feat(suricata): carry the JA4 TLS client fingerprint into the report#29mjbradford89 wants to merge 1 commit into
mjbradford89 wants to merge 1 commit into
Conversation
Suricata computes JA4 for TLS from 8.0.0 onward when
`app-layer.protocols.tls.ja4-fingerprints` is enabled, and logs it in the
eve.json `tls` record — `LOG_TLS_FIELD_JA4` is part of `EXTENDED_FIELDS`, so
the existing `extended: yes` eve-log output emits it with no further output
configuration.
`tls_items` is the allowlist that decides which eve `tls` keys are copied into
the CAPE report (see the loop below at the `event_type == "tls"` branch), so
without "ja4" here Suricata computes the fingerprint and the processing module
immediately discards it.
Unlike ja3/ja3s, which are `{hash, string}` objects, ja4 is a plain string.
The tuple is exploded across lines because appending "ja4" takes the single
line to 133 characters, past the 132 configured for black/ruff/flake8.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TL;DR
"ja4"to thetls_itemsallowlist inmodules/processing/suricata.py, so Suricata's JA4 TLS client fingerprint reaches the CAPE report instead of being computed and discarded.app-layer.protocols.tls.ja4-fingerprintsis enabled insuricata.yaml— that half lands in the polysando PR below.Why
tls_itemsis the allowlist that decides which keys from an eve.jsontlsrecord are copied into the report (theevent_type == "tls"branch further down). Suricata computes JA4 from 8.0.0 onward whenapp-layer.protocols.tls.ja4-fingerprintsis on, andLOG_TLS_FIELD_JA4is part ofEXTENDED_FIELDSinoutput-json-tls.c— so the existingextended: yeseve-log config emits it with no additional output configuration. Without"ja4"in this tuple the value is produced by Suricata and dropped here.Note that unlike
ja3/ja3s, which are{hash, string}objects,ja4is a plain string.Requires
Pairs with polyswarm/polysando#626, which enables
ja4-fingerprints: yesin the CAPE image'ssuricata.yamland bumps this submodule pointer. Neither half does anything alone; merge order does not matter.