t12i640300_1e98fdfb27e9_c54f48fd7c65
Probe (no SNI, no ALPN) — inferred from the JA4 handshake shape.
What this fingerprint encodes
t12i640300
handshake shape, human-readable
1e98fdfb27e9
truncated hash of the cipher list
c54f48fd7c65
truncated hash of extensions + signature algorithms
- Transport
- TCP
- TLS version
- TLS 1.2
- Server name
- no server name (IP literal)
- Cipher suites offered
- 64
- Extensions offered
- 3
- ALPN
- none offered
Same tool, different options
These 6 other fingerprints share this one's JA4_c — the extension and signature-algorithm hash. A client that keeps its extension set constant while varying its cipher list produces exactly this pattern, which is what a scanner iterating cipher suites looks like. A JA3 cannot show you this: its single MD5 collapses ciphers and extensions together, so every variation looks like an unrelated client.
- t12i040300_058957366436_c54f48fd7c65
- t12i640300_1715b94e3896_c54f48fd7c65
- t12i640300_a3acda31d846_c54f48fd7c65
- t12i640300_e31a90cd0803_c54f48fd7c65
- t12i640300_e7b476f9520b_c54f48fd7c65
- t12i640300_f559eb9565fd_c54f48fd7c65
The hello it was computed from
Recovered because the proxy now stores the pre-hash JA3 string alongside the digest. Every number below came out of this client's ClientHello; anything we cannot name in the IANA registry is shown as its raw value rather than guessed at.
- Version
- TLS 1.2
Cipher suites 64
-
89 (0x0059) -
49173 (0xc015) -
49174 (0xc016) -
88 (0x0058) -
79 (0x004f) -
82 (0x0052) -
81 (0x0051) -
80 (0x0050) -
83 (0x0053) -
86 (0x0056) -
85 (0x0055) -
84 (0x0054) -
129 (0x0081) -
131 (0x0083) -
128 (0x0080) -
130 (0x0082) -
49410 (0xc102) -
49408 (0xc100) -
49411 (0xc103) -
49413 (0xc105) -
49409 (0xc101) -
49412 (0xc104) -
49414 (0xc106) -
41 (0x0029) -
38 (0x0026) -
42 (0x002a) -
39 (0x0027) -
43 (0x002b) -
40 (0x0028) -
35 (0x0023) -
31 (0x001f) -
34 (0x0022) -
30 (0x001e) -
37 (0x0025) -
33 (0x0021) -
36 (0x0024) -
32 (0x0020) -
0 (0x0000) -
49322 (0xc0aa) -
49323 (0xc0ab) -
139 (0x008b) -
140 (0x008c) -
174 (0x00ae) -
49316 (0xc0a4) -
49320 (0xc0a8) -
168 (0x00a8) -
141 (0x008d) -
175 (0x00af) -
49317 (0xc0a5) -
49321 (0xc0a9) -
169 (0x00a9) -
49252 (0xc064) -
49258 (0xc06a) -
49253 (0xc065) -
49259 (0xc06b) -
49300 (0xc094) -
49294 (0xc08e) -
49301 (0xc095) -
49295 (0xc08f) -
52395 (0xccab) -
44 (0x002c) -
176 (0x00b0) -
177 (0x00b1) -
138 (0x008a)
Extensions 3
-
ec_point_formats -
supported_groups -
signature_algorithms
Named groups 5
-
secp256r1 -
secp384r1 -
secp521r1 -
x25519 -
ffdhe2048
Point formats 1
-
uncompressed
Raw JA3 string
771,89-49173-49174-88-79-82-81-80-83-86-85-84-129-131-128-130-49410-49408-49411-49413-49409-49412-49414-41-38-42-39-43-40-35-31-34-30-37-33-36-32-0-49322-49323-139-140-174-49316-49320-168-141-175-49317-49321-169-49252-49258-49253-49259-49300-49294-49301-49295-52395-44-176-177-138,11-10-13,23-24-25-29-256,0Seen in live traffic
- Connections
- 9
- First seen
- 2026-09-07 02:40 UTC
- Last seen
- 2026-10-09 02:35 UTC
- Transport
- TCP
- JA3 hashes absorbed
- 2
The same client, 2 different JA3s
This one JA4 covers 2 distinct JA3 hashes. A JA3 hashes the cipher and extension lists in the order they arrived, so a client that shuffles them — which Chrome and its derivatives do on purpose — produces a new JA3 almost every connection and fragments into what looks like 2 unrelated clients. JA4 sorts those lists before hashing, which is why all of it lands here instead.
e08e2d7f10c70b2cee08b9d63dbfed587ec0635c5b87e19b618f8f1a9a11521d
This entry is an observation, not a policy decision. It is here because the edge saw it, not because anyone reviewed it, and it blocks nothing on its own. Only the curated tier drives classification and banning.