How to tune specific JA3 rules to exclude requests to specific domains when SNI is not available?

For example, Acronis Backup (cloud) client appears to like to frequently connect to via TLS 1.0 with no SNI in the Client Hello. This keeps tripping rule 2028304 “ET JA3 Hash - Metasploit SSL Scanner” because it happens to match the JA3 hash in the rule. How would you recommend I tune this out since the server IPs vary (CDN) and there is no SNI to compare to? I tried to make a pass rule based on the FP-prone rule with the addition of tls.cert_subject criteria but the rule is rejected with the error “rule…mixes keywords with conflicting directions”.


pass tls $EXTERNAL_NET any -> $HOME_NET any (msg:“ET JA3 Hash - Metasploit SSL Scanner”; flow:established,to_server; ja3.hash; content:“6825b330bf9de50ccc8745553cb61b2f”; tls.cert_subject; content:“acronis”; sid:500000900; rev:1;)

It seems that ja3.hash must operate in a flow:established,to_server context while the tls.* criteria require a flow:established,from_server context. Is there any way to stop a specific JA3 rule from firing if a particular string is found in the server’s TLS cert subject?

Not all TLS clients sent SNI’s, and servers commonly are behind ever-changing IPs, so the only other thing I have to look at is the server’s TLS cert in cases like the above.

Perhaps something could be chained together using flowbits? Any suggestions would be greatly appreciated, as I’m certainly not a NIDS rule ninja.

This new “ET JA3 Hash” rule family looks promising but I’m not sure how to approach tuning out the false positives, and from what I can see there are no exclusion conditions presently in place in any of the rules of this family. I hope this does not mean that it is inherently resistant to being tuned.


The best way to do this is to add more identification conditions for Metasploit or do a correlation analysis in a SIEM like Splunk. Using just one ja3 will inevitably cause birthday problems.

In order to solve using only suricata, it seems to be necessary to consider the exception handling method using flowbits. Most situations that require exception handling involve many conditions.

  enabled: yes
    dp: 443

  # Generate JA3 fingerprint from client hello. If not specified it
  # will be disabled by default, but enabled if rules require it.
  ja3-fingerprints: yes

  # What to do when the encrypted communications start:
  # - default: keep tracking TLS session, check for protocol anomalies,
  #            inspect tls_* keywords. Disables inspection of unmodified
  #            'content' signatures.
  # - bypass:  stop processing this flow as much as possible. No further
  #            TLS parsing and inspection. Offload flow bypass to kernel
  #            or hardware if possible.
  # - full:    keep tracking and inspection as normal. Unmodified content
  #            keyword signatures are inspected as well.
  # For best performance, select 'bypass'.
  encryption-handling: full

Change encryption-handling: to full in suricata.yaml

alert tls $HOME_NET any-> $EXTERNAL_NET any (msg:“ET JA3 Hash-Metasploit SSL Scanner”; flow:established,to_server; ja3.hash; content:“6825b330bf9de50ccc8745553cb61b2f”; flowbits:set,ja3_1; noalert; sid:1; )
alert tls $EXTERNAL_NET any -> $HOME_NET any (msg:“Acronis Backup Server Res”; flow:established,to_client; flowbits:isset,ja3_1; tls.cert_subject; content:“acronis”; flowbits:set,ja3_2; noalert; sid:2; )
alert tls $HOME_NET any -> $EXTERNAL_NET any (msg:“ET JA3 Hash-Metasploit SSL Scanner”; flow:established,to_server; flowbits:isset,ja3_1; flowbits:isnotset,ja3_2; dsize:>0; stream_size:<,2922; sid:3; )

sid:1 checks the corresponding ja3 hash. sid:2 checks if acronis exists in the connection response from sid:1. If it exists, use flowbits to mark it as ja3_2. sid:3 detects the client’s packet after the server’s response. If it is not an acronis connection, ja3_2 is not displayed. The sid:3 rule checks the existence of ja3_2 through flowbits and alerts when it is determined that it is not connected to acronis (flowbits:isnotset,ja3_2).

The rules presented are temporary. With the exception of acronis, the result of using only ja3 hash is unconditionally unbelievable. Also, rules can become more complex if the same ja3 is found in different applications. For example, application B uses the same ja3. B can use 1.3 for TLS connections. Connections using TLS 1.3 cannot identify the certificate because the server’s response is encrypted. Eventually you need to check for additional packets on the connection.

As in the example described by salesforce, ja3 hash should be used as a secondary role for detection.