Tracks PRD open question 11. This is deliberately an open issue rather than a "future phase" — the JA4 labeling capability ships in v1; only the rule content is missing.
Current state
- Capability: in v1. Suricata's native
ja4.hash matching is enabled and tested; JA4 rules pass through the same per-source admission filter and snapshot provenance as any other rule (PRD §6.3, US-14).
- Content: none exists. Verified at Stage 1 — ET Open's rules directory contains
emerging-ja3.rules and no JA4 rules at all; no free maintained JA4 malicious-fingerprint feed exists; ja4db catalogues application identification, not malicious verdicts.
- Consequence: JA4 label output is zero on release. The run records the admitted JA4 rule count so a zero is visibly "no content published" rather than "path broken" (US-15).
The moment this closes
Any admitted source publishing ja4.hash rules starts producing labels with no code change. Three routes:
- Wait for ET Open to publish JA4 rules. Zero cost, zero work, unknown timing. ET already maintains JA3 rules with confidence metadata, so JA4 is a plausible extension for them.
- Evaluate a commercial JA4 feed (Hunt.io, GreyNoise, VirusTotal). Reopens the free-sources-only constraint and adds a procurement dependency.
- Derive our own by running known-malicious captures through Zeek and harvesting JA4 fingerprints — how abuse.ch originally built its JA3 list from ~25M malware pcaps. Highest provenance since we control it end to end; needs a malware corpus and a benign corpus to subtract against, or it produces the collision false-positives that make fingerprint labeling dangerous.
Periodic check worth doing
Re-check https://rules.emergingthreats.net/open/suricata-7.0/rules/ for a JA4 rules file. Cheap to check, and route 1 costs nothing if it lands.
Why this matters
JA4 sorts TLS extensions, making it resistant to the ClientHello shuffling that destabilises JA3. Once content exists, JA4 is the better fingerprint for encrypted-traffic labeling — so the value of closing this grows over time.
Tracks PRD open question 11. This is deliberately an open issue rather than a "future phase" — the JA4 labeling capability ships in v1; only the rule content is missing.
Current state
ja4.hashmatching is enabled and tested; JA4 rules pass through the same per-source admission filter and snapshot provenance as any other rule (PRD §6.3, US-14).emerging-ja3.rulesand no JA4 rules at all; no free maintained JA4 malicious-fingerprint feed exists;ja4dbcatalogues application identification, not malicious verdicts.The moment this closes
Any admitted source publishing
ja4.hashrules starts producing labels with no code change. Three routes:Periodic check worth doing
Re-check
https://rules.emergingthreats.net/open/suricata-7.0/rules/for a JA4 rules file. Cheap to check, and route 1 costs nothing if it lands.Why this matters
JA4 sorts TLS extensions, making it resistant to the ClientHello shuffling that destabilises JA3. Once content exists, JA4 is the better fingerprint for encrypted-traffic labeling — so the value of closing this grows over time.