salesforce / ja3

JA3 is a standard for creating SSL client fingerprints in an easy to produce and shareable way.

JA3 - A method for profiling SSL/TLS Clients

JA3 was invented at Salesforce in 2017. However, the project is no longer being actively maintained by Salesforce. Its original creator, John Althouse, maintains the latest in TLS client fingerprinting technology at FoxIO-LLC.

JA3 is a method for creating SSL/TLS client fingerprints that should be easy to produce on any platform and can be easily shared for threat intelligence.

Before using, please read this blog post: TLS Fingerprinting with JA3 and JA3S

This repo includes JA3 and JA3S scripts for Zeek and Python. You can find a nice Rust implementation of the JA3 algorithm here

JA3 support has also been added to:
Moloch
Trisul NSM
NGiNX BFE MISP
Darktrace
Suricata
Elastic.co Packetbeat
Splunk
MantisNet
ICEBRG
Redsocks
NetWitness
ExtraHop
Vectra Cognito Platform
Corvil
Java
Go
Security Onion
AIEngine
RockNSM
Corelight
VirusTotal
SELKS
Stamus Networks
IBM QRadar Network Insights (QNI)
InQuest
Cloudflare
AWS Network Firewall
Azure Firewall
AWS WAF
Google Cloud
and more...

Examples

JA3 fingerprint for the standard Tor client:

e7d705a3286e19ea42f587b344ee6865

JA3 fingerprint for the Trickbot malware:

6734f37431670b3ab4292b8f60f29984

JA3 fingerprint for the Emotet malware:

4d7a28d6f2263ed61de88ca66eb011e3

While destination IPs, Ports, and X509 certificates change, the JA3 fingerprint remains constant for the client application in these examples across our sample set. Please be aware that these are just examples, not indicative of all versions ever.

Lists

Example lists of known JA3's and their associated applications can be found here.

A more up-to-date crowd sourced method of gathering and reporting on JA3s can be found at ja3er.com.

How it works

TLS and it’s predecessor, SSL, I will refer to both as “SSL” for simplicity, are used to encrypt communication for both common applications, to keep your data secure, and malware, so it can hide in the noise. To initiate a SSL session, a client will send a SSL Client Hello packet following the TCP 3-way handshake. This packet and the way in which it is generated is dependant on packages and methods used when building the client application. The server, if accepting SSL connections, will respond with a SSL Server Hello packet that is formulated based on server-side libraries and configurations as well as details in the Client Hello. Because SSL negotiations are transmitted in the clear, it’s possible to fingerprint and identify client applications using the details in the SSL Client Hello packet.

JA3 is a method of TLS fingerprinting that was inspired by the research and works of Lee Brotherston and his TLS Fingerprinting tool: FingerprinTLS.

JA3 gathers the decimal values of the bytes for the following fields in the Client Hello packet; SSL Version, Accepted Ciphers, List of Extensions, Elliptic Curves, and Elliptic Curve Formats. It then concatenates those values together in order, using a "," to delimit each field and a "-" to delimit each value in each field.

The field order is as follows:

SSLVersion,Cipher,SSLExtension,EllipticCurve,EllipticCurvePointFormat

Example:

769,47-53-5-10-49161-49162-49171-49172-50-56-19-4,0-10-11,23-24-25,0

If there are no SSL Extensions in the Client Hello, the fields are left empty.

Example:

769,4-5-10-9-100-98-3-6-19-18-99,,,

These strings are then MD5 hashed to produce an easily consumable and shareable 32 character fingerprint. This is the JA3 SSL Client Fingerprint.

769,47-53-5-10-49161-49162-49171-49172-50-56-19-4,0-10-11,23-24-25,0 --> ada70206e40642a3e4461f35503241d5
769,4-5-10-9-100-98-3-6-19-18-99,,, --> de350869b8c85de67a350c8d186f11e6

We also needed to introduce some code to account for Google’s GREASE (Generate Random Extensions And Sustain Extensibility) as described here. Google uses this as a mechanism to prevent extensibility failures in the TLS ecosystem. JA3 ignores these values completely to ensure that programs utilizing GREASE can still be identified with a single JA3 hash.

JA3S

JA3S is JA3 for the Server side of the SSL/TLS communication and fingerprints how servers respond to particular clients.

JA3S uses the following field order:

SSLVersion,Cipher,SSLExtension

With JA3S it is possible to fingerprint the entire cryptographic negotiation between client and it's server by combining JA3 + JA3S. That is because servers will respond to different clients differently but will always respond to the same client the same.

For the Trickbot example:

JA3 = 6734f37431670b3ab4292b8f60f29984 ( Fingerprint of Trickbot )
JA3S = 623de93db17d313345d7ea481e7443cf ( Fingerprint of Command and Control Server Response )

For the Emotet example:

JA3 = 4d7a28d6f2263ed61de88ca66eb011e3 ( Fingerprint of Emotet )
JA3S = 80b3a14bccc8598a1f3bbe83e71f735f ( Fingerprint of Command and Control Server Response )

In these malware examples, the command and control server always responds to the malware client in exactly the same way, it does not deviate. So even though the traffic is encrypted and one may not know the command and control server's IPs or domains as they are constantly changing, we can still identify, with reasonable confidence, the malicious communication by fingerprinting the TLS negotiation between client and server. Again, please be aware that these are examples, not indicative of all versions ever, and are intended to illustrate what is possible.

Intriguing Possibilities

JA3 is a much more effective way to detect malicious activity over SSL than IP or domain based IOCs. Since JA3 detects the client application, it doesn’t matter if malware uses DGA (Domain Generation Algorithms), or different IPs for each C2 host, or even if the malware uses Twitter for C2, JA3 can detect the malware itself based on how it communicates rather than what it communicates to.

JA3 is also an excellent detection mechanism in locked-down environments where only a few specific applications are allowed to be installed. In these types of environments one could build a whitelist of expected applications and then alert on any other JA3 hits.

For more details on what you can see and do with JA3 and JA3S, please see this DerbyCon 2018 talk: https://www.youtube.com/watch?v=NI0Lmp0K1zc or this blog post.

Please contact me on twitter @4A4133 or over email, let me know what you find and if you have any feature requests.

---

JA3 Created by

John Althouse
Jeff Atkinson
Josh Atkins

Please send questions and comments to John Althouse.

ja3's Issues

JA3(s) can not parse windows/x64/meterpreter/reverse_https Payload

Hello , When I use JA3(S) to parse MetaSploit-Framework(6.0.37-dev) - windows/x64/meterpreter/reverse_https Payload, it does not work.

I don't understand the reason for this, could you give me some suggestions? Thank you very much～

msf_https.pcap.zip

No fingerprints generated for IPv6 handshakes

In its current form, the JA3 code will not generate fingerprints for IPv6 TLS handshakes. For example, if you run the following:
ja3 -a /path/to/pcap/containing/ipv6.pcap
Then it will just output [] indicating that no fingerprints were found.

The problem is because of one of the packet checks that is performed inside the process_pcap method:

if not isinstance(eth.data, dpkt.ip.IP):
    # We want an IP packet
    continue

This check will only allow IPv4 packets through.

I was able to get around this by changing the check to be:

if not (isinstance(eth.data, dpkt.ip.IP) or isinstance(eth.data, dpkt.ip6.IP6)):
    # We want an IP packet
    continue

After making this change, I was able to get fingerprints from PCAP files containing IPv6 packets.

The issue appears to be present in all of the following files:

• ja3.py
• ja3s.py
• ja3/ja3.py

How to make http requests with ja3 fingerprint in python?

why md5

it is really cool. Just a question: why md5 and not a faster hash like SipHash or BLAKE2?

Add go implementation to the README

We from Open Systems just open sourced a Go Implementation of the JA3 algorithm over at: https://github.com/open-ch/ja3

We were wondering if you would be willing to add our implementation to your README.

Cheers

No JA3 hash in logs

Installed plugin by the instructions, when running scripts -c in zeekctl I do get

{"name":"  /opt/zeek/share/zeek/site/ja3/__load__.zeek"}
{"name":"    /opt/zeek/share/zeek/site/ja3/ja3.zeek"}
{"name":"    /opt/zeek/share/zeek/site/ja3/intel_ja3.zeek"}
{"name":"    /opt/zeek/share/zeek/site/ja3/ja3s.zeek"}

but don't have anything in ssl.log and can't figure out where to look for problems (if they exists)

Error loading scripts in Bro

Bro Version: 2.5.1

I receive the following error when checking scripts:

[BroControl] > deploy checking configurations ... bro scripts failed. error in /opt/bro/share/bro/site/./ja3/./ja3.bro, line 66: orphaned field "client_version" in record coercion ((coerce (coerce [] to JA3::TLSFPStorage) to TLSFP::TLSFPStorage)) error in /opt/bro/share/bro/site/./ja3/./ja3.bro, line 83: orphaned field "client_version" in record coercion ((coerce (coerce [] to JA3::TLSFPStorage) to TLSFP::TLSFPStorage)) error in /opt/bro/share/bro/site/./ja3/./ja3.bro, line 102: orphaned field "client_version" in record coercion ((coerce (coerce [] to JA3::TLSFPStorage) to TLSFP::TLSFPStorage)) error in /opt/bro/share/bro/site/./ja3/./ja3.bro, line 121: orphaned field "client_version" in record coercion ((coerce (coerce [] to JA3::TLSFPStorage) to TLSFP::TLSFPStorage)) error in /opt/bro/share/bro/site/./ja3/./ja3.bro, line 122: no such field in record (JA3::c$tlsfp$client_version) error in /opt/bro/share/bro/site/./ja3/./ja3.bro, line 127: no such field in record (JA3::c$tlsfp$client_ciphers) error in /opt/bro/share/bro/site/./ja3/./ja3.bro, line 128: no such field in record (JA3::c$tlsfp$client_ciphers) error in /opt/bro/share/bro/site/./ja3/./ja3.bro, line 131: no such field in record (JA3::c$tlsfp$client_ciphers) error in /opt/bro/share/bro/site/./ja3/./ja3.bro, line 135: no such field in record (JA3::c$tlsfp$client_version) error in /opt/bro/share/bro/site/./ja3/./ja3.bro, line 135: no such field in record (JA3::c$tlsfp$client_ciphers)

Not sure if i am missing a step. I tried loading the scripts from two different locations custom and site.

getting the wrong JA3 hashes for chrome, edge etc

Hi! I'm not entirely familiar with JA3 but basically I have set up and configured Suricata with JA3 enabled etc but once I run Suricata, I seem to be getting the wrong hashes. I know this because I copy and paste them into https://ja3er.com/form and the hashes arent recognised, I'm testing it on the google chrome for reference. Any help would be greatly appreciated. I'm kinda new to IDS and JA3 so bare with me please!

Unknown or invalid cipher suite type fafa

I got this error while I was running js3 on pcap file :-

Traceback (most recent call last):
  File "F:\Program Files\Python39\lib\site-packages\dpkt\ssl.py", line 301, in unpack
    self.ciphersuites = [
  File "F:\Program Files\Python39\lib\site-packages\dpkt\ssl.py", line 302, in <listcomp>
    ssl_ciphersuites.BY_CODE[code] for code in struct.unpack('!' + num_ciphersuites * 'H', ciphersuites)]
KeyError: 64250

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "F:\Program Files\Python39\Scripts\ja3-script.py", line 33, in <module>
    sys.exit(load_entry_point('pyja3==1.1.0', 'console_scripts', 'ja3')())
  File "F:\Program Files\Python39\lib\site-packages\ja3\ja3.py", line 245, in main
    output = process_pcap(capture, any_port=args.any_port)
  File "F:\Program Files\Python39\lib\site-packages\ja3\ja3.py", line 194, in process_pcap
    handshake = dpkt.ssl.TLSHandshake(record.data)
  File "F:\Program Files\Python39\lib\site-packages\dpkt\dpkt.py", line 87, in __init__
    self.unpack(args[0])
  File "F:\Program Files\Python39\lib\site-packages\dpkt\ssl.py", line 421, in unpack
    self.data = embedded_type[1](self.data)
  File "F:\Program Files\Python39\lib\site-packages\dpkt\dpkt.py", line 87, in __init__
    self.unpack(args[0])
  File "F:\Program Files\Python39\lib\site-packages\dpkt\ssl.py", line 304, in unpack
    raise SSL3Exception('Unknown or invalid cipher suite type %x' % int(e.args[0]))
dpkt.ssl.SSL3Exception: Unknown or invalid cipher suite type fafa

ja3 not found in Zeek

Upgraded our bro instance to the latest LTS version of Zeek (3.0.13 at time of writing). We had the older version of ja3 for bro so did a one-to-one replacement of the files to be placed in the /opt/zeek/share/zeek/site/ja3 directory. We tried both the original and the installation instruction's @ load line in local.zeek (@ load ja3/ which worked for the bro version, and @ load ./ja3 per the zeek instructions). In both cases, the file permissions are exactly the same.

The error message received when we run broctl deploy is:
"fatal error in /opt/zeek/share/zeek/site/local.zeek, line 221: can't find ./ja3"

The path changes to what we originally used with the bro version of ja3/.

Also for sanity made sure there were no extraneous white spaces or anything. When I moved the older bro version of ja3 back in place, deploy was successful and the scripts worked as expected adding the fields we need.

why pyja3 not used

$ja3 -j cs_client_online.pcap
$[]

cs_client_online.zip

Possible parse problem on loopback

Not sure if loopback pcaps are even a concern but client and server could be on same system over loopback and the loopback header seems to cause the data to be incorrectly parsed using your dpkt logic because of the lack of an Ethernet header.

ja3s python program not working

python3 ja3s.py -j trace1.pcap
[]

Will you add this to the Bro Package Manager system?

Hey guys,

Thanks for providing this - it looks awesome and I can really see the usefulness of it in my own deployment.

One quick question - do you have any plans to integrate it with the Bro Package Manager system (http://bro-package-manager.readthedocs.io/en/stable/index.html)? It simplifies deployment and maintenance on the hosts quite a bit.

Thanks in advance, Mike

JA3 uniqueness in modern version of Chrome (which randomizes ClientHello messages)

https://chromestatus.com/feature/5124606246518784 discusses a new change, designed to prevent ossification, in which client hellos will be randomized, subject to the limits in the RFC.

It was originally scheduled to go into Chrome 110, but was actually merged in Chrome 109.

Other fingerprinting implementations such as https://tlsfingerprint.io have started to sort these headers to restore some consistency; see https://tlsfingerprint.io/norm_fp .

Does JA3 plan to address this?

Add lookup table with ja3 hash to user-agent for additional metadata.

I've been working on a lookup table for ja3.bro that uses the input framework to ingest a file with ja3 hashes and their associated user-agents and add that meta-data to record. Wondering if you would be interested in adding that feature upstream. Below is my Github Repo.

https://github.com/bryant-treacle/SSL_Traffic_Hunting

Let me know what you think.

What did happen to ja3er.com? Website is down

Was this site completely turned off or is it a temporary outage?

python install with setup fails to find README

long_description=read('README.md'),

In the python folder it's a different extension.

Zeek 3 support

Topic :)

warning in /opt/zeek/share/zeek/site/packages/./ja3/./ja3.bro, line 59: deprecated (bro_init): Remove in v3.1: use zeek_init
warning in /opt/zeek/share/zeek/site/packages/./ja3/./ja3s.bro, line 41: deprecated (bro_init): Remove in v3.1: use zeek_init

Integration in IVRE

Hi there,

Thanks a lot for sharing JA3, it is a great idea!

For your information, I have integrated JA3 support, based on the Bro scripts from this repository, to the passiverecon Bro script integrated to (and used by) IVRE, an open-source passive & active network recon framework.

I have tried to prevent any incompatibility with your scripts (or other existing scripts) by using ivre specific prefix for the records added to existing logs and structures (to prevent issues similar to #13).

I have also simplified & improved the code, so you may want to reuse some of the changes I made.

The integration has been done in ivre/ivre#624. The script, based on your code, is released under the same license as IVRE (GPLv3+), while keeping the Salesforce copyright notice (Copyright 2017 salesforce.com, inc.) as it is my understanding that this is permitted by the license used for the original scripts. Please let me know if you disagree or if it is a problem for you.

Thanks again!

Link broken in README.md

https://github.com/salesforce/ja3/blob/master/README.md
"This repo includes JA3 and JA3S scripts for Zeek..."
https://www.zeekurity.org https://zeek.org

parameter to accept network interface to do sniffing

like fingerprintls, can you kindly add a parameter to ja3 tool to accept and based its sniffing and computation on a network interface?

Only getting ja3s info added to the ssl.log, not ja3 info...

I have this weird issue in Zeek where only the ja3s information is being added to my ssl.log file, not sign of any ja3 information...How should I start troubleshooting this ?

I installed using zkg an have the following in my local.zeek file, I had no errors when starting on installing anything (Zeek included):

@load packages

Zeek is installed on my proxy server (running Squid) so it should see all SSL traffic going back and forth.

Is there a good resource for understanding SSL extensions?

I am trying to understand how the SSL extension length and extensions are set in the server hello packet but can't find a good resource for it. Any help is appreciated.

Add Rust implementation to the README

Hello! I created a Rust implementation of your amazing work here: https://github.com/jabedude/ja3-rs.

Is there any way you could add that to your README? There is some network analysis work being done with rust in the Suricata project that might want to use it !

Why is there no "ec_point_formats" extension in the "TSL Extensions" section of JA3S?

Gentlemen:

I would appreciate if someone could answer the title question, i.e. why is the output of ja3s.py on the pcap file that contains a TLS handshake with Server Hello that has several extensions , including "ec_point_formats" extension (extension id: 0x0b or 11), does not contain the aforementioned extension in its output:

~/GITreps/ja3/python/ja3s.py ~/Test/chrome.pcap
[10.5.20.22:54729] JA3: 769,49161,0-65281 --> 5dd9d7e21843ad5870da6c2485c21e81

In this case, I would expect the JA3S to look like:

JA3: 769,49161,0-65281-11 --> 8685e43ade3e6ec8993efb5d149fb4bc

For comparison, the ja3.py output does contain this extension, when Client Hello has it:

~/GITreps/ja3/python/ja3.py ~/Test/chrome.pcap
[81.218.16.216:443] JA3: 769,47-53-5-10-49171-49172-49161-49162-50-56-19-4,65281-0-10-11,23-24,0 --> 1d095e68489d3c535297cd8dffb06cb9

I can provide the referenced PCAP file, if need be.

JA3... really? I don't think this name is vague enough. We can do better.

So you arrived at the name JA3. Honestly, I'm not impressed guys. I don't think this name is ambiguous enough. I think we can do better.

I propose that we change the name from JA3 to XZ8. I think if Salesforce wants to stay a leader in CRM, you need to think even harder about using acronyms and names that are even more difficult to recognise. I mean what is the point otherwise? If we are going to go with JA3, why don't we go all in?

Look. I'm sorry John Althouse ,Jeff Atkinson, and Josh Atkins but this name just doesn't cut it. If you want people to adopt this, you have to make the name even more mysterious, more vague and more ambiguous. If I only need to dig through 15 pages in my favourite search engine, to figure out why you ran with this awful name, then clearly someone wasn't trying hard enough.

No really, in all seriousness. What compels 3 people to name something so badly (even if it is after themselves) when it could be revolutionary?
Can you imagine if Linus Torvalds had decided to name his OS "LT1"?

If you truly care about adoption and visibility. Rename the project. Especially as it's now evolved past the neckbeard-joke-phase.

ja3 uses = for comparison instead of ==

Throughout ja3.bro, single equals (assignment) is used for comparison in situations like:

if ( is_orig = T ) {

where I believe that == (equality) is the intended operator. I think this has been working because is_orig is always true (see issue #19 ).

ERROR - next statement used outside of for or while statement

A next statement in the ja3.zeek errors out in Zeek v5.2 and above. It should be a return statement.

From https://github.com/zeek/zeek/blob/master/NEWS:

• Usage of break and next statements is now validated. It was previously
  possible to place these outside of for, while or switch
  statements without any error indication.

Output when running the package errors out:
error in ./ja3/zeek/./ja3.zeek, line 69: next statement used outside of for or while statement

Offending code:
event ssl_extension(c: connection, is_orig: bool, code: count, val: string)
{
if ( ! c?$tlsfp )
c$tlsfp=TLSFPStorage();
if ( is_orig == T ) {
if ( code in grease ) {
next;
}
...

ja3.py: map does not remove items

In ja3.py, line 256:

map(remove_items,output)

It does not actually remove items, because map returns an iterator that is not consumed.
Possible solution:
list(map(remove_items,output))

Producing the same value

Ja3 always producing the same value. I have 2 different pcap. they have different random bytes value.

https://ibb.co/D7gp7Dt
https://ibb.co/qx3vbc0

But it creating the same JA3 value.

"ja3": "771,60-47-61-53-5-10-49191-49171-49172-49195-49187-49196-49188-49161-49162-64-50-106-56-19-4,65281-0-10-11-13,23-24,0",
        "ja3_digest": "4d7a28d6f2263ed61de88ca66eb011e3"

Broxygen syntax warnings

When running the ja3.bro plugin, several syntax warnings are issued:

internal warning in /opt/bro/share/bro/site/./ja3/./intel_ja3.bro, line 1: Discarded extraneous Broxygen comment: LOG FIELD VALUES ##
internal warning in /opt/bro/share/bro/site/./ja3/./intel_ja3.bro, line 1: Discarded extraneous Broxygen comment: FOR DEBUGGING ##

PR for quick and easy fix coming in a minutes

TLS1.3 TLSVersion Inconsistencies

Should TLSVersion for TLS1.3 be 771 or 772?

Per RFC 8446 :

In previous versions of TLS, this field was used for
version negotiation and represented the highest version number
supported by the client. Experience has shown that many servers
do not properly implement version negotiation, leading to "version
intolerance" in which the server rejects an otherwise acceptable
ClientHello with a version number higher than it supports. In
TLS 1.3, the client indicates its version preferences in the
"supported_versions" extension (Section 4.2.1) and the
legacy_version field MUST be set to 0x0303, which is the version
number for TLS 1.2. TLS 1.3 ClientHellos are identified as having
a legacy_version of 0x0303 and a supported_versions extension
present with 0x0304 as the highest version indicated therein.

I'm of the opinion that TLSVersion should be correctly set to the actual version negotiated as JA3 spec doesn't dictate where the version is sourced: the legacy version or the version from "supported_versions" extension.

I've noticed that Wireshark will report the JA3 String for TLS1.3 with 771. However, Browserleaks will report 772.

Broken Netwitness link on Readme

Link is currently set to:

https://github.com/timetology/nw/tree/master/parsers/ssl_ja3

This should be updated to:

https://github.com/timetology/NetWitness/tree/master/Network/Parsers/ssl_ja3

Extra value of 21 in the ja3 digest related to the extensions (related to GREASE???)

I have the folliowing ja3/ja3 digests for a pcap I analyzed:

    "ja3": "771,4867-4865-4866-49196-49195-49188-49187-49162-49161-52393-49200-49199-49192-49191-49172-49171-52392-157-156-61-60-53-47-49160-49170-10,65281-0-23-13-5-13172-18-16-11-51-45-43-10-21,29-23-24-25,0",
    "ja3_digest": "7a7a639628f0fe5c7e057628a5bbec5a",

Now using fingerprintls tool for the same pcap, i have this data:

'record_tls_version': '0x0301',
'tls_version': '0x0303',
'ciphersuite_length': '0x0034',
'ciphersuite': '0x1303 0x1301 0x1302 0xC02C 0xC02B 0xC024 0xC023 0xC00A 0xC009 0xCCA9 0xC030 0xC02F 0xC028 0xC027 0xC014 0xC013 0xCCA8 0x009D 0x009C 0x003D 0x003C 0x0035 0x002F 0xC008 0xC012 0x000A',
'compression_length': '1',
'compression': '0x00',
'extensions': '0xFF01 0x0000 0x0017 0x000D 0x0005 0x3374 0x0012 0x0010 0x000B 0x0033 0x002D 0x002B 0x000A ',
'e_curves': '0x001D 0x0017 0x0018 0x0019 ',
'sig_alg': '0x0403 0x0804 0x0401 0x0503 0x0203 0x0805 0x0805 0x0501 0x0806 0x0601 0x0201 ',
'ec_point_fmt': '0x00',

For the extensions part of ja3:

65281-0-23-13-5-13172-18-16-11-51-45-43-10-21

I noticed that there's an additional 21 value that was added because looking at the fingerprintls output for extensions, the final element is 0x000A:

'extensions': '0xFF01 0x0000 0x0017 0x000D 0x0005 0x3374 0x0012 0x0010 0x000B 0x0033 0x002D 0x002B 0x000A ',

Now i understand that this may have something to do with GREASE. My question is should I just add 21 to the end of the extensions ALWAYS, when there is a value in the extensions (or ciphers) that is in the GREASE table? Thanks

looking to create ja3

hi there , i'd like to know if there is any tools to create ja3 finger prints .

all of the tools i've seen till now , are tools that are extracting ja3 finger prints and their md5 hash.

however i am looking for a tool that create "generate" those ja3 finger prints .

thanks

about Ignored ext application_settings and ja3 will change by session_ticket

1. Type: application_settings (17513) will be ignored?
   Why? I didn't see the place mentioned

2. ja3 will change by session_ticket
   In chrome ,The ja3 of the first request and subsequent requests are different.
   The reason is that there is no session ticket for the first time.
   Most of the time, ja3 seen in a carries a session ticket.
   However, curl does not carry session tickets

The update of the python library dpkt caused changes in Ciphers fingerprint results.

Updating dpkt to 1.9.5 will cause the password to be changed from a number to the corresponding string, and the fingerprint result will be changed. When GARSE appears, the script dpkt will report an error.
When dpkt is 1.9.4,look like this:

[root@localhost python]# python3 ja3.py /home/pcap/ja3_test.pcap  
[ip:port] JA3: 771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,0-23-65281-10-11-35-16-5-13-18-51-45-43-27-21,29-23-24,0 --> b32309a26951912be7dba376398abc3b
[root@localhost python]# python3 ja3s.py /home/pcap/ja3_test.pcap 
[ip:port] JA3S: 771,49199,35-16 --> 4504e8d0495298feb931ec7e09f94bcc

When dpkt is 1.9.5,look like this:

[root@localhost python]# python3 ja3.py /home/pcap/ja3_test.pcap 
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/site-packages/dpkt/ssl.py", line 302, in unpack
    ssl_ciphersuites.BY_CODE[code] for code in struct.unpack('!' + num_ciphersuites * 'H', ciphersuites)]
  File "/usr/local/lib/python3.6/site-packages/dpkt/ssl.py", line 302, in <listcomp>
    ssl_ciphersuites.BY_CODE[code] for code in struct.unpack('!' + num_ciphersuites * 'H', ciphersuites)]
KeyError: 27242

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "ja3.py", line 284, in <module>
    main()
  File "ja3.py", line 264, in main
    output = process_pcap(capture, any_port=args.any_port)
  File "ja3.py", line 203, in process_pcap
    handshake = dpkt.ssl.TLSHandshake(record.data)
  File "/usr/local/lib/python3.6/site-packages/dpkt/dpkt.py", line 87, in __init__
    self.unpack(args[0])
  File "/usr/local/lib/python3.6/site-packages/dpkt/ssl.py", line 421, in unpack
    self.data = embedded_type[1](self.data)
  File "/usr/local/lib/python3.6/site-packages/dpkt/dpkt.py", line 87, in __init__
    self.unpack(args[0])
  File "/usr/local/lib/python3.6/site-packages/dpkt/ssl.py", line 304, in unpack
    raise SSL3Exception('Unknown or invalid cipher suite type %x' % int(e.args[0]))
dpkt.ssl.SSL3Exception: Unknown or invalid cipher suite type 6a6a

[root@localhost python]# python3 ja3s.py /home/pcap/ja3s_test.pcap 
[ip:port]  JA3S: 771,CipherSuite(TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256),35-16 --> 8ce7e2735b56d547ea7168506ac74566

Error when deployed with Zeek version 5.2

When we deploy this plugin on Zeek 5.2, we receive the following error:

checking configurations ...
logger-1 scripts failed.
error in /opt/zeek/share/zeek/site/packages/./ja3/./ja3.zeek, line 69: next statement used outside of for or while statement

manager scripts failed.
error in /opt/zeek/share/zeek/site/packages/./ja3/./ja3.zeek, line 69: next statement used outside of for or while statement

proxy-1 scripts failed.
error in /opt/zeek/share/zeek/site/packages/./ja3/./ja3.zeek, line 69: next statement used outside of for or while statement

zeek01-1 scripts failed.
error in /opt/zeek/share/zeek/site/packages/./ja3/./ja3.zeek, line 69: next statement used outside of for or while statement

Do you have any suggestions or workarounds?

Using ja3s, extensions are never added to the JA3 string

I pulled down the JA3S Bro script and installed it on a 2.5.3 Bro installation. JA3S fingerprints are being generated, but they never include extensions. For example: JA3S: 7770094a92b1cbfa5a6de2017cfb682a Fingerprint String: 771,49200,

I added some debug print statements to ssl_extensions() and observed that is_orig is never false (F), so the logic never fires. In ja3s.py (pull request forthcoming) and Wireshark, I can see extensions in the Sever Hellos like status_request, renegotiation_info, etc. I'm not sure if this is an issue specific to my build of Bro or if others have been able to replicate it.

it seems ja3 not really get rid of the GREASE

i have head to https://ja3er.com/ , after some of time , i get another ja3 hash, that's change after a while , i have read this draft document.

my current browser version:
chrome version 74.0.3729.157（64 位）
mac osx 10.11.6

Rename the project to something meaningful!

STFU - SSL / TLS Fingerprinting Uniqueness
STUF - SSL / TLS Unique Fingerprinting
STF - SSL / TLS Fingerprinting

seriously!

SSLv2 in Python Script

When a piece of malware issues a SSLv2 client hello, ja3.py misses it. Can ja3 apply to SSLv2 hellos? I know there are no extensions, but that could just be blank.

a tool for extract ja3(s) when sniffing or from a pcap.

https://github.com/Macr0phag3/ja3box

solved #29

Website is down

Any chance it will be repaired?

Get SNI from the Client Hello

I am interested in getting an SNI from the Client Hello handshake processed by JA3. However, I don't have the low level background required for this, so I am finding it hard to do.

If anyone could provide me with some pointers, on what needs to be done in order to extract SNI. That help would be very much appreciated.

Thank you

Output not generated for a Android pcap file

I recently captured packets from my Android device of a particular application. The packets are in pcap format. But when I try to pass them into ja3 command, no output is being generated. All I get is an empty string.

However, output is generated when I pass a different pcap file which was generated on Windows.

Here is the link for both the pcap : -
https://drive.google.com/drive/folders/1khS7Bs4k9-CnvGWOiFcOhohDQ3mbrSaR?usp=sharing

Can anyone help me with this issue or maybe take a look over my Android Pcap file ?

provide sample pcaps and expected results

Would be great if you could provide some sample pcaps and the expected JA3 so we can verify our implementations. Definitely hit some trickyness when the tls header and hello headers had different values and which to use

How to integrate with python requests?

Hi I'm just wondering if this can be integrated with python requests library? What will the steps look like? I'm interested in running tests mimicking a web browser on a site that uses cloudfare. I want to use a library like requests or urllib, not browser emulation. My requests arent going through because of TLS fingerprinting since the requests library cant do this.

Normally I would request a site like this:

import requests

headers = {
    'authority': 'vplates.com.au',
    'sec-ch-ua': '" Not A;Brand";v="99", "Chromium";v="99", "Google Chrome";v="99"',
    'sec-ch-ua-mobile': '?0',
    'sec-ch-ua-platform': '"Windows"',
    'upgrade-insecure-requests': '1',
    'user-agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.74 Safari/537.36',
    'accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9',
    'sec-fetch-site': 'none',
    'sec-fetch-mode': 'navigate',
    'sec-fetch-user': '?1',
    'sec-fetch-dest': 'document',
    'accept-language': 'en-US,en;q=0.9',
}

response = requests.get('https://example.com/', headers=headers)

But the site site uses cloudflare so I get no response. Anyway to use ja3 to get around this?

JA3 is recalculated in error upon hello retry request

When a SSL client hello is resent, the current implementation adds the strings onto the already existing string, and then recomputes the MD5 of this bloated string and this is what gets logged.