JA3 / JA4 Fingerprinting

Techniki tworzenia stałych odcisków klienta i serwera TLS z jawnych pól handshake (ClientHello/ServerHello), które pozwalają rozpoznać aplikację lub malware bez deszyfracji ruchu.

JA3 / JA4 Fingerprinting to techniki, które tworzą stały „odcisk” klienta lub serwera TLS na podstawie tego, jak negocjuje on szyfrowane połączenie. Odcisk powstaje z jawnych, jeszcze niezaszyfrowanych pól pierwszych pakietów połączenia — ClientHello i ServerHello (wersja TLS, lista szyfrów, rozszerzenia, obsługiwane krzywe, ALPN). Dzięki temu można rozpoznać typ aplikacji, użytą bibliotekę TLS albo rodzinę malware bez odszyfrowywania treści połączenia. JA3 powstało w firmie Salesforce, a JA4+ — jego następca — w firmie FoxIO.

Jak działa fingerprinting TLS?

Każde połączenie TLS zaczyna się od krótkiej „rozmowy wstępnej” (handshake), która idzie jeszcze otwartym tekstem. Klient wysyła pakiet ClientHello i deklaruje w nim, jakie wersje protokołu obsługuje, jaką ma listę szyfrów (cipher suites), jakie rozszerzenia (extensions) i krzywe, oraz jaki protokół aplikacji chce negocjować (ALPN — Application-Layer Protocol Negotiation). Te dane są widoczne, zanim powstanie klucz sesji.

Każda implementacja TLS — przeglądarka, biblioteka, agent czy narzędzie — układa te wartości w trochę inny, charakterystyczny sposób. Odcisk TLS to po prostu skrót (hash) tej kombinacji. To trochę jak rozpoznać kogoś po sposobie mówienia, a nie po treści: ten sam typ klienta daje ten sam odcisk niezależnie od tego, z jakim adresem IP, portem czy certyfikatem się łączy.

Jak liczy się JA3?

JA3 buduje odcisk z pakietu ClientHello. Z jego pól wyciąga się wartości liczbowe i skleja w jeden ciąg, zawsze w tej samej kolejności:

  1. wersja TLS,
  2. lista szyfrów (cipher suites),
  3. lista rozszerzeń (extensions),
  4. obsługiwane krzywe eliptyczne (elliptic curves),
  5. formaty punktów krzywych (EC point formats).

Pola rozdziela się przecinkiem, a wartości w polu — myślnikiem, np. 769,47-53-5-10-...,0-23-65281-10-11-...,29-23-24,0. Tak złożony ciąg jest haszowany algorytmem MD5, co daje 32-znakowy odcisk. Wartości GREASE (mechanizm z RFC 8701, który celowo wstrzykuje „losowe” wpisy) są pomijane, żeby klienci ich używający dawali mimo to stabilny hash. Odpowiednikiem po stronie serwera jest JA3S, liczony z pakietu ServerHello (wersja, wybrany szyfr, rozszerzenia).

Jak liczy się JA4 i co obejmuje suite JA4+?

JA4 to nowsza wersja odcisku ClientHello, zaprojektowana tak, by była czytelna dla człowieka i odporniejsza na zmiany w klientach. Ma format z trzech części, a_b_c:

  • Część a — czytelne metadane: protokół (t dla TLS po TCP, q dla QUIC, d dla DTLS), wersja TLS (np. 13), czy podano nazwę domeny (d) czy adres IP (i), liczba szyfrów, liczba rozszerzeń i dwa znaki z pierwszego ALPN.
  • Część b — 12-znakowy, skrócony hash SHA256 z posortowanej listy szyfrów.
  • Część c — 12-znakowy, skrócony hash SHA256 z posortowanej listy rozszerzeń (bez SNI i ALPN) wraz z listą algorytmów podpisu.

Najważniejsza różnica wobec JA3: JA4 sortuje szyfry i rozszerzenia, więc losowa kolejność rozszerzeń nie psuje już odcisku. JA4+ to cały zestaw (suite) odcisków dla różnych protokołów i warstw, m.in. JA4 (klient TLS), JA4S (odpowiedź serwera TLS), JA4H (nagłówki HTTP), JA4L (lokalizacja/opóźnienie), JA4X (certyfikaty X.509) oraz JA4T i JA4SSH. Człony można łączyć i wyszukiwać po fragmentach (np. tylko a i c), co pomaga w threat huntingu, czyli aktywnym szukaniu zagrożeń w ruchu.

Czym różni się JA3 od JA4?

  • Format: JA3 to jeden 32-znakowy hash MD5; JA4 to czytelny ciąg a_b_c z jawnymi metadanymi i skróconymi hashami SHA256.
  • Kolejność pól: JA3 zależy od kolejności rozszerzeń w ClientHello; JA4 je sortuje, więc nie przeszkadza mu ich losowanie.
  • Zakres: JA3 obejmuje tylko TLS po TCP; JA4 rozróżnia TCP, QUIC i DTLS, a cały zestaw JA4+ pokrywa też HTTP, certyfikaty i SSH.
  • Czytelność: JA3 to sam hash i nic z niego nie widać; JA4 pokazuje część cech (protokół, wersję, SNI, ALPN) wprost.

Dlaczego JA3/JA4 są ważne dla bezpieczeństwa?

Prawie cały dzisiejszy ruch sieciowy jest szyfrowany, więc klasyczna inspekcja pakietów niewiele widzi bez odszyfrowywania. Fingerprinting TLS odzyskuje część tej widoczności, bo pracuje na jawnych metadanych handshake — nie zagląda do treści. W praktyce używa się go do kilku rzeczy:

  • Wykrywanie malware i kanałów C2 (Command and Control, czyli zdalnego sterowania zainfekowanymi maszynami): wiele rodzin malware używa specyficznych bibliotek TLS, więc daje charakterystyczny odcisk — rozpoznawalny mimo zmiany IP, domeny czy certyfikatu. Połączenie odcisku klienta i serwera (JA3+JA3S albo JA4+JA4S) podnosi trafność, bo opisuje całą parę negocjacji.
  • Klasyfikacja ruchu i wykrywanie anomalii: odciski pozwalają grupować klientów, wychwytywać niezgodność deklarowanego User-Agenta z faktycznym stosem TLS i odróżniać boty oraz skanery od zwykłych przeglądarek.
  • Wzbogacanie telemetrii dla SOC, NDR i SIEM: odcisk jako dodatkowy atrybut przepływu (flow) ułatwia łączenie zdarzeń, przeszukiwanie historii i pisanie reguł wykrywania.

W modelu Pyramid of Pain (który porządkuje wskaźniki ataku według tego, jak bardzo bolą atakującego przy podmianie) odcisk negocjacji TLS jest trudniejszy do zmiany niż adres IP czy hash pliku, więc podnosi koszt działania napastnika. Technika dobrze uzupełnia się z Encrypted Traffic Analysis (ETA) — analizą zaszyfrowanego ruchu, która z metadanych i cech statystycznych wnioskuje o charakterze połączenia bez odszyfrowywania.

Jakie są ograniczenia JA3/JA4?

  • Randomizacja rozszerzeń: od Chrome 110 i Firefox 114 przeglądarki losują kolejność rozszerzeń TLS, więc ten sam klient potrafi dawać różne hashe JA3 — przez to JA3 stał się niestabilny. JA4 rozwiązuje to sortowaniem.
  • Kolizje i brak unikalności: odcisk wskazuje implementację lub bibliotekę, a nie konkretny komputer czy osobę; różne aplikacje oparte na tej samej bibliotece mogą mieć identyczny odcisk.
  • Podszywanie się: atakujący mogą celowo naśladować ClientHello popularnej przeglądarki (TLS mimicry), żeby ukryć swoje narzędzie pod znanym, „niewinnym” odciskiem.
  • Potrzebny jawny handshake: mechanizm Encrypted ClientHello (ECH) szyfruje część pakietu ClientHello, więc zostaje mniej danych do odcisku.
  • To wskazówka, nie wyrok: sam odcisk jest sygnałem, a nie dowodem — trzeba go zestawiać z innymi (reputacja, wolumen, regularne „pukanie” do serwera, czyli beaconing).

Dowiedz się więcej