SoftEther VPN JA4S (JA4S=t130200_1302_a56c5b993250) overlaps with a default nginx TLS setup

[owah]

Hi all,

My nginx version is [nginx 1.24.0-2] (from debian testing) and this is my httpd config: I know that the JA4S depends on the client you use, I used MS Edge (based on chrome). (t13d1516h2_8daaf6152771_02713d6af862)

server {
        listen 443 ssl;

        server_name wildcard-domain;

        root /var/www/html;
        index index.html;

        ssl_certificate /etc/letsencrypt/live/wildcard-domain/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/wildcard-domain/privkey.pem;
}

Edit: It looks like I had accidentally deleted the second part of my comment before submission. The point I wanted to make is that it might not be too handy to have JA4S=t130200_1302_a56c5b993250 featured prominently on the mainpage of the project as belonging to SoftEther VPN, if in fact you get the same JA4S from a standard nginx httpd.

What do you think?

[john-althouse]

JA4+ fingerprints are not meant to be atomic indicators on their own, though sometimes they very much can be, but rather, they are indicators to be used in combination.

For example,

JA4==t13d190900_9dc949149365_97f8aa674fd9

This is GoLang, used by Sliver malware and legit applications.

JA4==t13d190900_9dc949149365_97f8aa674fd9 && 
JA4S==t130200_1301_a56c5b993250

Now that narrows it down to be more likely Sliver malware, but there's still room for false positives.

JA4==t13d190900_9dc949149365_97f8aa674fd9 && 
JA4S==t130200_1301_a56c5b993250 &&
JA4X==000000000000_4f24da86fad6_bf0f0589fc03

Now it's 100% Sliver malware, there would be no false positives with this combination.

That's not the best example because JA4X==000000000000_4f24da86fad6_bf0f0589fc03 is actually a great atomic indicator for Sliver malware, but it gets the point across.

Do you have any suggestions on a good way to make this point clear in the readme?

[owah]

Hi John,

I've been thinking about this problem for quite a while, but I couldn't come up with anything better. I think that the users of JA4+ just have to be made aware explicitly that passing judgement based on a single indicator might not be too prudent.

But what about this.

Description	JA4	# Overlaps
Malware A	abc	1
Malware B	def	0
HTTPd A	abc	1

In essence adding a column mentioning how often a matching JA4+ fingerprint can be found in other rows. It might not look like much but I think users instantly get primed to realize that they need more indicators to have a 'convincing match'.

(Also, I'm working on a project with many thousand unique JA4, JA4S and JA4X fingerprints, I was wondering if I could maybe shoot you an email in regards to that project.)

[john-althouse]

@owah take a look at the ja4db and load that data into Splunk or Elastic or something. When loaded into a log/data management tool, it's easy to zoom in on a fingerprint and then see how many applications it is also seen in. I think that's pretty straight forward but what do you think?

It does kind of put the onus on the user to create their own process of checking -- but every user is using JA4+ for different purposes and in different ways so its hard to find a one-size-fits-all solution. That's why we're leaning on just giving the users all the data for them to load into their own toolset. Feel free to shoot me an email [email protected]