TLS fingerprinting mengidentifikasi perangkat lunak yang membuka koneksi HTTPS dengan melihat bagaimana ia membukanya — cipher mana yang ditawarkan dan dalam urutan apa, ekstensi dan kurva eliptik apa yang didaftarkan — sebelum konten permintaan apa pun dikirim. Setiap pustaka TLS dan setiap versi browser menyapa server dengan cara yang sedikit berbeda, dan sapaan itu terlihat oleh server dalam teks biasa meskipun semua yang setelahnya dienkripsi. JA3 dan penerusnya JA4 mengubah sapaan itu menjadi hash pendek. Sistem anti-bot membandingkan hash itu dengan apa yang seharusnya dihasilkan oleh browser yang diklaim. Inilah mengapa skrip Python yang mengaku sebagai Chrome, terhubung melalui IP residential yang sempurna, tetap tertangkap: IP mengatakan “pengguna rumahan di Berlin”; handshake TLS mengatakan “OpenSSL dalam skrip.”
Dari mana sidik jari berasal: ClientHello
Koneksi HTTPS dimulai dengan handshake TLS. Pesan pertama, yang dikirim oleh klien, adalah ClientHello. Pesan ini tidak dienkripsi — memang harus begitu, karena enkripsi belum dinegosiasikan — dan berisi, antara lain:
- versi TLS yang didukung klien;
- daftar cipher suite yang bersedia digunakan, dalam urutan preferensinya;
- daftar ekstensi — SNI (nama host), ALPN (protokol aplikasi mana, mis.
h2,http/1.1), grup yang didukung (kurva eliptik), algoritma tanda tangan, key share, session ticket, dan seterusnya — lagi-lagi dalam urutan tertentu; - kurva eliptik dan format titik yang didukungnya.
Tidak satu pun dari nilai-nilai ini yang rahasia dan tidak ada yang dipilih per situs; semuanya tertanam dalam pustaka TLS dan aplikasi yang menggunakannya. Chrome 128 mengirim satu ClientHello tertentu; Firefox mengirim yang lain; modul ssl Python (OpenSSL) mengirim yang ketiga; crypto/tls Go yang keempat; curl yang kelima. Server melihat ClientHello untuk setiap koneksi — memang harus, untuk menjawabnya. Merekam dan meng-hash-nya tidak memerlukan biaya apa pun.
JA3 dan JA4: mengubah handshake menjadi tanda tangan
JA3
Diperkenalkan oleh peneliti Salesforce pada tahun 2017, JA3 menggabungkan lima bidang ClientHello — versi TLS, cipher suite, ekstensi, kurva eliptik, format titik kurva eliptik — sebagai daftar desimal yang dipisahkan koma, kemudian meng-hash string tersebut dengan MD5. Hasilnya adalah sidik jari 32 karakter seperti cd08e31494f9531f560d64c695473da9. Siapa pun dapat menghitungnya dari tangkapan paket, dan daftar yang memetakan hash JA3 ke klien yang dikenal (“hash ini = Chrome 120 di Windows,” “hash ini = python-requests”) banyak dibagikan.
JA3 memiliki kelemahan yang menjadi fitur untuk penghindaran: karena meng-hash daftar ekstensi secara berurutan, dan Chrome (sejak versi 110) mengacak urutan ekstensi pada setiap koneksi, satu instalasi Chrome menghasilkan banyak hash JA3 yang berbeda. Itu dilakukan dengan sengaja untuk mencegah server mengeras pada satu sidik jari — dan itu membuat JA3 jauh kurang berguna untuk mengidentifikasi browser.
JA4
JA4, dirilis oleh FoxIO pada tahun 2023, dirancang untuk bertahan dari itu. JA4 mengurutkan daftar cipher dan ekstensi sebelum meng-hash (sehingga pengacakan Chrome tidak lagi masalah), menjaga sebagian sidik jari dapat dibaca manusia, dan memasukkan lebih banyak sinyal: apakah koneksi melalui TCP atau QUIC, tipe SNI, nilai ALPN, versi TLS, dan jumlah cipher serta ekstensi. Sidik jari JA4 terlihat seperti t13d1516h2_8daaf6152771_e5627efa2ab1: blok pertama mengatakan “TLS 1.3 melalui TCP, 15 cipher, 16 ekstensi, ALPN h2,” dua lainnya adalah hash terpotong dari daftar cipher yang diurutkan dan daftar ekstensi yang diurutkan plus algoritma tanda tangan. JA4 sebenarnya adalah keluarga (JA4 untuk TLS, JA4H untuk header HTTP, JA4S untuk sisi server, JA4X untuk sertifikat, dan lainnya); ketika vendor anti-bot mengatakan “sidik jari TLS” hari ini, mereka biasanya berarti JA4 atau setara kepemilikan yang dibangun dengan cara yang sama.
Mengapa proxy tidak dapat membantu
Proxy meneruskan handshake TLS; ia tidak menulis ulang. Dengan proxy HTTP, klien mengirim CONNECT host:443, proxy membuka terowongan TCP, dan ClientHello milik klien berjalan melalui terowongan ke tujuan tanpa tersentuh. Dengan SOCKS5 hal yang sama terjadi satu lapisan di bawahnya. Oleh karena itu, server tujuan melihat dua fakta independen:
- IP sumber — milik proxy, residential dan bersih;
- ClientHello — milik klien, yang mengatakan persis pustaka apa yang membuatnya.
Logika anti-bot kemudian mengajukan pertanyaan sederhana: apakah sidik jari TLS cocok dengan User-Agent? Header User-Agent mengklaim “Chrome 128 di Windows.” JA4 mengatakan “OpenSSL 3.x melalui Python.” Chrome asli tidak pernah menghasilkan JA4 itu. Permintaan ditandai — bukan karena IP-nya buruk, tetapi karena ceritanya tidak konsisten secara internal. Ini adalah alasan paling umum mengapa proxy residential yang “bersih” masih mendapatkan CAPTCHA di situs yang dilindungi, dan mengapa kami mengatakan proxy menjawab dari mana, bukan siapa; lihat apa yang dilakukan dan tidak disembunyikan oleh proxy.
Proxy dapat berpengaruh dalam satu hal: beberapa penyedia menghentikan TLS sendiri (proxy “man-in-the-middle” yang mendekripsi dan mengenkripsi ulang, mengharuskan Anda memasang sertifikatnya). Dalam kasus itu, tujuan melihat ClientHello milik proxy, bukan milik Anda — yang biasanya lebih buruk, karena itu adalah pustaka sisi server, bukan browser. Proxy biasa tidak melakukan ini.
Seperti apa tampilan setiap jenis klien
| Klien | Apa yang dikatakan sidik jari TLS-nya | Konsisten dengan User-Agent browser? |
|---|---|---|
| Chrome / Firefox / Safari asli | Browser dan versi itu, di OS itu | Ya — itu memang browser |
Python requests, httpx, aiohttp | OpenSSL sesuai konfigurasi modul ssl Python | Tidak — dapat dikenali sebagai skrip terlepas dari header |
Node.js fetch / axios | Build OpenSSL/BoringSSL Node | Tidak |
Go net/http | Tumpukan TLS Go sendiri; khas | Tidak |
| curl (build default) | OpenSSL/LibreSSL sesuai build | Tidak |
| Headless Chrome via Puppeteer/Playwright | Chrome asli — TLS yang benar | Ya untuk TLS; sinyal lain (flag otomatisasi, plugin yang hilang) mungkin masih bocor |
| Klien “meniru” (curl-impersonate, curl_cffi, tls-client) | ClientHello browser yang dipilih, direproduksi byte demi byte | Ya, jika Anda juga mencocokkan header dengan browser yang sama |
Cara memiliki sidik jari yang konsisten
Ada tiga rute yang jujur, dalam urutan biaya yang meningkat.
- Gunakan browser asli. Otomatiskan Chrome atau Firefox dengan Playwright atau Puppeteer; TLS-nya benar-benar milik browser. Lebih lambat dan lebih berat daripada HTTP mentah, tetapi untuk situs yang dilindungi, ini adalah garis dasarnya. Pasangkan setiap konteks browser dengan proxy-nya sendiri — lihat proxy di Playwright, Puppeteer, dan Selenium.
- Gunakan klien HTTP yang meniru. Pustaka seperti curl_cffi (Python, dibangun di atas curl-impersonate) dan tls-client mereproduksi ClientHello dan pengaturan HTTP/2 browser tertentu, sehingga Anda mendapatkan kecepatan scraper dengan sidik jari browser. Anda kemudian harus menjaga semua header lain konsisten dengan versi browser yang sama — User-Agent,
Accept-Language, petunjuk kliensec-ch-ua— atau Anda menukar satu kontradiksi dengan yang lain. Panduan proxy Python kami menunjukkan peralihan darirequestskecurl_cffi. - Berhenti berpura-pura. Jika target menawarkan API resmi, gunakan dengan identitas klien asli Anda. TLS fingerprinting hanya menjadi masalah ketika sidik jari bertentangan dengan klaim.
Apa yang tidak berhasil: mengatur User-Agent Chrome pada requests. Itu mengubah satu header dan membiarkan handshake tidak tersentuh — ketidakcocokan sekarang lebih tajam dari sebelumnya, karena UA python-requests polos dengan sidik jari OpenSSL setidaknya konsisten dengan dirinya sendiri.
Gambaran yang lebih besar: sidik jari menumpuk
TLS adalah satu lapisan. Vendor anti-bot modern juga mengambil sidik jari koneksi HTTP/2 (nilai frame SETTINGS, ukuran jendela, urutan header dan urutan pseudo-header — kadang disebut Akamai fingerprinting), tumpukan TCP/IP (ukuran jendela, TTL, opsi; p0f klasik), dan tentu saja browser itu sendiri melalui JavaScript, yang tidak dapat dijalankan oleh klien HTTP sama sekali. Setiap lapisan harus menceritakan kisah yang sama dengan yang lain dan dengan IP. IP residential dengan sidik jari TLS browser dan pengaturan HTTP/2 browser tetapi tanpa eksekusi JavaScript masih merupakan anomali di situs yang mengharapkan tantangan JS berjalan. Inilah mengapa jawaban jujur untuk “proxy mana yang menghindari deteksi?” adalah “tidak ada yang sendirian” — dan mengapa peringkat kami mempertimbangkan apa yang dilakukan penyedia di luar IP; lihat perbandingan proxy elit.
Cara melihat sidik jari Anda sendiri
Beberapa halaman publik menggemakan JA3/JA4 yang mereka hitung untuk koneksi Anda, bersama dengan browser apa yang mereka pikir itu milik. Muat satu dari browser asli, lalu ambil dengan skrip Anda melalui proxy yang sama, dan bandingkan. Jika keduanya berbeda, Anda telah menemukan alasan mengapa skrip Anda diperlakukan berbeda dari browser Anda — dan tidak ada perubahan proxy yang akan memperbaikinya. Tambahkan ini ke pemeriksaan di Cara menguji proxy setiap kali target diketahui menjalankan anti-bot perusahaan.
Pertanyaan yang sering diajukan
Apa itu JA3?
Hash MD5 dari lima bidang ClientHello TLS (versi, cipher, ekstensi, kurva, format titik) yang digunakan untuk mengidentifikasi perangkat lunak klien. Ini bekerja dengan baik untuk skrip dan pustaka; menjadi tidak dapat diandalkan untuk Chrome setelah Chrome mulai mengacak urutan ekstensi.
Apa itu JA4?
Penerus JA3: ia mengurutkan daftar sebelum meng-hash sehingga pengacakan ekstensi tidak mengubahnya, menjaga sebagian sidik jari dapat dibaca, dan menyertakan transport (TCP/QUIC), ALPN, dan jumlah. Ini adalah dasar dari sebagian besar deteksi sidik jari TLS saat ini.
Apakah proxy residential mengubah sidik jari TLS saya?
Tidak. Proxy meneruskan handshake Anda tanpa perubahan; tujuan melihat IP proxy dan ClientHello Anda. Hanya perangkat lunak klien yang menentukan sidik jari.
Bisakah saya memalsukan sidik jari TLS browser di Python?
Ya, dengan klien yang meniru seperti curl_cffi, yang mereproduksi ClientHello dan perilaku HTTP/2 browser yang dipilih. Anda harus menjaga header konsisten dengan browser yang sama. requests/httpx biasa tidak dapat melakukan ini.
Apakah TLS fingerprinting sama dengan browser fingerprinting?
Tidak. TLS fingerprinting membaca handshake koneksi terenkripsi dan mengidentifikasi perangkat lunak klien; browser fingerprinting menjalankan JavaScript dan mengidentifikasi perangkat (canvas, font, GPU). Sistem anti-bot menggunakan keduanya, plus reputasi IP, dan memeriksa bahwa mereka setuju.
Mengapa skrip yang sama diblokir di satu situs dan tidak di situs lain?
Karena pemeriksaan sidik jari TLS adalah fitur produk anti-bot perusahaan, bukan fitur web secara umum. Situs tanpa perlindungan seperti itu tidak pernah melihat handshake; situs dengan itu membandingkannya dengan User-Agent pada setiap permintaan.