JA3 fingerprint discrepancy when compare with other JA3 tools

[Barbosik]

Thanks for plugin, I compared it's output with these JA3 online tools:

• https://ja3er.com (json version: https://ja3er.com/json )
• https://tls.browserleaks.com (json version: https://tls.browserleaks.com/json )

and found some discrepancy.

The difference happens because your plugin include some extension types into ja3 fingerprint, but these tools ignore these extensions and not include it into ja3 fingerprint. Both tools showing exactly the same JA3 fingerprint, but it is different from one calculated with this wireshark plugin. For example, it happens for the following extension types:

• 20 (server_certificate_type)
• 24 (token_binding)
• 25 (cached_info),
• 30032 (channel_id)
• etc.

So, it looks that this plugin exclude GREASE values, but still include some other extension types into JA3 fingerprint. While other tools ignore these extension types.

For example you can compare Android Chrome v49 TLS fingerprint (it works with TLS 1.2).

Any idea which JA3 implementation is more correct?

[fullylegit]

The implementation in this plugin is based on the original salesforce article and code.

I replicated your testing and then checked the pcaps against the salesforce python script and got the same values as the plugin provides, so I'm comfortable that the plugin is behaving correctly.

There's nothing in the algorithm detail about excluding any values other than GREASE, so I suspect there may be a device in the hosting providers' networks of the sites you linked to that's rewriting the connections.

[Barbosik]

Man in the middle modification is not possible for TLS connection, just because ClientHello message content is used for digital signature in verify block of TLS Handshake Finished message. Any attempt to modify ClientHello message leads to a fail of TLS authentication.

[fullylegit]

You're quite right, I was thinking more along the lines of a CDN or load balancer or something else that was decrypting and inspecting the traffic intentionally rather than doing it maliciously.

Either way my original guess doesn't seem very likely so I had another look into both those sites. I noticed they both use nginx so I checked how the ja3 nginx module works on the hypothesis that they're using that. A quick test showed I was seeing the same results with nginx locally as those sites return so I'm pretty sure this guess is correct.

The module uses openssl functions to get the list of extensions from the tls connection. It turns out that openssl will only return the extension types it knows about and discards the unknown types. There is a patch included in the repo to add two more types (27 and 28), and when I added a few more missing ones to that patch and rebuilt it I then got results with nginx that are consistent with wireshark.

Hope this helps.

[Barbosik]

Thanks