Post-quantum TLS di 2026: mengapa JA4 yang cocok tidak lagi menyelamatkan scraper

Satu tahun yang lalu, skema ini cukup jelas: Anda mengambil klien yang dapat memalsukan handshake TLS, memilih profil untuk Chrome terbaru, mendapatkan JA4 yang cocok — dan anti-bot akan melewatkannya. Pada tahun 2026, resep ini mulai gagal karena alasan yang sama sekali tidak ada hubungannya dengan "menghindari perlindungan". Browser secara massal beralih ke pertukaran kunci pasca-kuantum, sementara sebagian besar tumpukan pengambilan data tidak. Dan sekarang, ketidakadaan berbagi kunci pasca-kuantum itu sendiri menjadi tanda otomatisasi.

Mari kita analisis berdasarkan kriteria: apa yang sebenarnya berubah dalam handshake, tumpukan mana yang sudah beralih, mana yang belum, dan mengapa hash JA4 yang cocok tidak lagi menjadi syarat yang cukup.

Apa yang terjadi: pertukaran pasca-kuantum menjadi norma, bukan eksotisme

Pertukaran kunci pasca-kuantum hibrida adalah kombinasi dari kurva elips klasik X25519 dan mekanisme kisi ML-KEM (standar NIST FIPS 203). Sesi tetap terlindungi jika setidaknya satu dari dua komponen tetap kuat. Intinya adalah perlindungan dari skenario "intersepsi sekarang, dekripsi nanti", ketika lalu lintas ditulis ke arsip dengan harapan untuk komputer kuantum di masa depan.

Timeline penerapan di klien:

• Chrome 124 (April 2024) — pertukaran pasca-kuantum diaktifkan secara default; dalam patch curl-impersonate ini dicatat sebagai "kurva X25519Kyber768/X25519MLKEM, diperkenalkan di Chrome 124 dan 130".
• Firefox 132 (November 2024) — dukungan diaktifkan.
• Safari di iOS dan macOS — pertukaran pasca-kuantum tiba pada Oktober 2025.
• OpenSSL 3.5.0 (April 2025) — grup hibrida X25519MLKEM768, SecP256r1MLKEM768, dan SecP384r1MLKEM1024 dimasukkan dalam daftar grup default TLS.
• Go 1.24 (Februari 2025) — X25519MLKEM768 diaktifkan di crypto/tls secara default, jika Config.CurvePreferences tidak ditentukan secara eksplisit.

Dari sisi infrastruktur, gambaran menjadi lebih jelas. Cloudflare Radar pada April 2026 menunjukkan sekitar 67% lalu lintas HTTPS manusia dengan enkripsi pasca-kuantum — dibandingkan dengan 32% pada Januari 2025. Akamai menjadikan pertukaran kunci pasca-kuantum sebagai default untuk semua koneksi klien 31 Januari 2026, menyelesaikan rollout di seluruh jaringan pada bulan Maret. Menurut pengukuran industri, sekitar 57,4% dari semua transaksi browser sudah siap untuk pasca-kuantum, dengan proporsi Chrome yang mampu PQ sekitar 93%.

Perhatikan asimetri: dukungan di sisi server asal tumbuh jauh lebih lambat (di Cloudflare — sekitar 9%). Artinya, pasca-kuantum saat ini adalah karakteristik klien. Tepat apa yang menarik bagi anti-bot.

Kriteria 1: ukuran key share dan struktur ClientHello

Key share pasca-kuantum bukanlah "sekadar satu lagi tanda centang dalam ekstensi". Ia secara fisik besar: sekitar 1124 byte dibandingkan dengan 36 byte pada X25519 klasik. Konsekuensinya terlihat jelas pada tingkat paket.

ClientHello dengan key share pasca-kuantum keluar lebih dari 1400 byte dan tidak lagi muat dalam satu segmen TCP. Ia dibagi menjadi dua paket atau lebih. Dan kemudian yang paling menarik untuk deteksi dimulai: pola fragmentasi dari berbagai implementasi berbeda. Bagaimana tumpukan memotong ClientHello yang besar, dalam urutan apa segmen dikirim, dengan timing apa — ini adalah perilaku yang dapat diamati, yang tidak dihasilkan dari hash JA4 dan hampir tidak ada penulis alat pengambilan data yang secara sadar mereproduksinya.

Kesimpulan praktis: anti-bot kini memiliki lapisan yang bekerja di bawah jejak yang biasa. Anda dapat mengumpulkan daftar cipher dan ekstensi dengan sempurna, tetapi Anda akan terdeteksi berdasarkan bagaimana tumpukan Anda menempatkan byte ke dalam soket.

Kriteria 2: konsistensi dengan versi browser yang dinyatakan

Perangkap utama tahun 2026 adalah ketidaksinkronan antara siapa Anda mengaku sebagai dan apa yang sebenarnya dilakukan tumpukan TLS Anda.

Platform anti-bot menyimpan basis data ClientHello referensi. Permintaan yang di User-Agent dan JA4 menyatakan Chrome 131, tetapi datang tanpa key share pasca-kuantum, tidak cocok dengan satu pun Chrome 131 yang valid. Ini bukan "mencurigakan" — ini adalah kombinasi yang secara logis tidak mungkin. Chrome versi nyata tidak dapat secara fisik mengirim key share klasik dengan pengaturan default.

Seberapa baik ini dipisahkan oleh pembelajaran mesin — juga telah dihitung. Klasifikator CatBoost pada fitur JA4 dalam penelitian menunjukkan AUC 0,998 dan akurasi 0,9863; secara terpisah, lalu lintas pasca-kuantum berbeda dari yang klasik dengan akurasi sekitar 98%. Ini bukan "heuristik dengan false positives", ini adalah ciri yang hampir deterministik.

Kriteria 3: kesiapan tumpukan tertentu

Di sinilah garis pemisahan yang nyata terjadi. Mari kita kelompokkan.

Mengirim PQ key share secara default

• Chrome 124+, Firefox 132+, Safari (iOS/macOS sejak Oktober 2025) — standar yang dibandingkan dengan Anda.
• Go 1.24+ — crypto/tls secara otomatis menyertakan X25519MLKEM768, jika Anda tidak mengubah CurvePreferences. Nuansa penting: ada pasca-kuantum, tetapi JA4 pada klien Go yang telanjang tetap tidak seperti browser. Anda mendapatkan jejak "kompatibel PQ, tetapi tidak mirip Chrome".
• Node.js 24 — membawa OpenSSL 3.5 sendiri, sehingga daftar grup default sudah mencakup hibrida. Selain itu, di node:crypto ada ML-KEM melalui crypto.encapsulate()/decapsulate() dan ML-DSA dalam sign()/verify().

Tergantung pada apa yang terhubung

• Python: requests, aiohttp, httpx — menggunakan modul ssl, dan itu mengambil OpenSSL sistem. Di Ubuntu 24.04, sistem menjalankan OpenSSL 3.0.x, di mana grup pasca-kuantum tidak ada sama sekali. Untuk mendapatkan PQ, Anda perlu membangun OpenSSL 3.5 dari sumber, menyertakannya melalui LD_LIBRARY_PATH dan, kemungkinan besar, membangun ulang Python itu sendiri. Dalam praktiknya, ini berarti: scraper Python tipikal pada tahun 2026 mengirim key share klasik dan terlihat sebagai anomali di Akamai.

Memiliki kemampuan, tetapi hanya jika memilih profil yang benar

• curl_cffi / curl-impersonate — dukungan untuk kurva pasca-kuantum ada dalam fork dan dinyatakan secara jelas. Namun, daftar target berkisar dari chrome99 hingga chrome146 (dalam fork — hingga chrome150), dan profil lama mereproduksi handshake dari waktu mereka, yaitu tanpa PQ. Menyalin impersonate="chrome116" dari panduan dua tahun yang lalu — adalah jalan langsung menuju deteksi.
• uTLS — prinsip yang sama: profil HelloChrome di bawah 131 tidak mengandung PQ key share. Selain itu, di perpustakaan untuk tahun 2026, dua kerentanan jejak telah ditutup: CVE-2026-26995 (versi 1.6.0–1.8.1) dan CVE-2026-27017 (1.6.0–1.8.0, ketidaksinkronan pemilihan cipher untuk GREASE ECH — Chrome memilihnya secara deterministik, sedangkan parrot di uTLS melempar koin antara AES dan ChaCha20, yang tidak mungkin dilakukan oleh Chrome yang sebenarnya). Pembaruan perlu dilakukan setidaknya hingga 1.8.2.

Keseluruhan: alat-alat pada umumnya telah mengejar. Masalahnya bukan pada mereka, tetapi pada konfigurasi yang menjadi usang lebih cepat daripada browser. Profil yang sempurna pada tahun 2024, hari ini berfungsi sebagai penanda.

Bagaimana memeriksa tumpukan Anda dalam lima menit

1. Kirim permintaan menggunakan klien Anda yang sebenarnya ke https://tls.peet.ws/api/all atau ja4db.com — mereka mengembalikan JA3/JA4 langsung dan analisis ClientHello dalam JSON.
2. Cari dalam analisis daftar supported_groups dan key_share. Cari X25519MLKEM768 (atau X25519Kyber768 pada profil lama). Jika hanya ada x25519/secp256r1 — tidak ada pertukaran pasca-kuantum.
3. Periksa ini dengan versi browser yang Anda klaim. Mengklaim Chrome 131+ dan tidak melihat grup PQ — kombinasi tidak valid, perbaiki profil Anda.
4. Perhatikan ukuran ClientHello. Kurang dari ~1400 byte dengan Chrome terbaru yang dinyatakan — adalah tanda yang sama, hanya dari sisi lain.
5. Jalankan pemeriksaan dari setiap node keluar, bukan hanya dari mesin kerja: inspeksi SSL di gateway perusahaan atau penyedia dapat menulis ulang handshake untuk Anda.

Apa yang dilakukan proxy di sini

Penting untuk tidak mencampur dua lapisan independen. Key share pasca-kuantum — ini tentang handshake, reputasi alamat — tentang jaringan. Anti-bot menghitungnya secara terpisah dan menjumlahkannya.

Dari sini, ada dua konsekuensi praktis. Pertama: IP residensial yang sempurna tidak akan menyelamatkan permintaan yang pada tingkat TLS mengaku sebagai Chrome 131 tanpa grup PQ — Anda akan kalah bahkan sebelum server melihat alamatnya. Kedua, cermin: handshake pasca-kuantum yang disusun dengan benar tidak akan membantu jika seratus sesi Anda datang dari satu subnet pusat data dengan reputasi yang rusak. Kedua lapisan perlu diperbaiki, dan mereka diperbaiki dengan alat yang berbeda.

Pembagian praktis berdasarkan tugas: untuk tujuan di belakang Akamai dan Cloudflare, di mana mereka menghitung baik handshake maupun jaringan, masuk akal untuk mengambil proxy residensial dan secara bersamaan meningkatkan target impersonate ke Chrome terbaru. Untuk aplikasi seluler dan platform di mana bobot reputasi IP lebih tinggi daripada persyaratan TLS, sering kali lebih menguntungkan menggunakan proxy seluler. Dan untuk API sendiri, pengunduhan mitra, dan pemantauan internal, di mana tidak ada anti-bot, tidak ada gunanya membayar lebih untuk residensial — cukup menggunakan datacenter.

Jika Anda memulai dari awal dengan jejak, mulailah dengan dasar: bagaimana JA4 bekerja dan apa yang termasuk di dalamnya. Dan ketika berbicara bukan tentang klien HTTP, tetapi tentang browser penuh, perbandingan build stealth dan kelemahan mereka telah dikumpulkan secara terpisah — nodriver, Camoufox, dan Patchright dalam pengukuran 2026.

Kesimpulan

Pertukaran kunci pasca-kuantum tidak dirancang sebagai mekanisme anti-bot. Ia menjadi demikian secara tidak langsung: browser beralih ke sana dengan cepat dan massal, infrastruktur (Akamai — sejak 31 Januari 2026) menjadikannya default, dan tumpukan pengambilan data terbagi menjadi tiga kelompok — yang sudah beralih, yang tergantung pada OpenSSL sistem, dan yang hanya mampu jika profilnya terbaru.

Pemeriksaan disimpulkan dalam satu pertanyaan: apakah klien Anda mengirim X25519MLKEM768 dan apakah ini sesuai dengan versi browser yang Anda klaim. Jika tidak — JA4 yang cocok tidak akan menyelamatkan Anda, karena yang dibandingkan bukan lagi hash, tetapi seluruh bentuk handshake secara keseluruhan: ukuran key share, jumlah segmen TCP, dan urutan pengirimannya. Kabar baiknya adalah bahwa ini dapat diperbaiki dalam sebagian besar kasus dengan memperbarui profil dan versi perpustakaan, bukan dengan menulis ulang scraper.