Bir yıl önce şeması açıktı: TLS el sıkışmasını taklit edebilen bir müşteri alıyorsunuz, yeni Chrome için bir profil seçiyorsunuz, eşleşen JA4'ü alıyorsunuz - ve anti-bot geçiyor. 2026 yılında bu tarif bozulmaya başladı, bunun nedeni "korumaları aşmakla" hiç ilgisi olmayan bir sebeptir. Tarayıcılar topluca post-kuantum anahtar değişimine geçti, ancak çoğu scraping yığını geçmedi. Ve şimdi post-kuantum anahtar paylaşımının olmaması, kendisi otomatikleştirme işareti haline geldi.
Kriterlere göre inceleyelim: el sıkışmasında ne değişti, hangi yığınlar geçti, hangileri geçmedi ve neden eşleşen hash JA4 yeterli bir koşul olmaktan çıktı.
Ne oldu: post-kuantum değişim norm haline geldi, egzotik değil
Hibrit post-kuantum anahtar değişimi, klasik eliptik eğri X25519 ile ızgara mekanizması ML-KEM'in (NIST FIPS 203 standardı) birleşimidir. Oturum, iki bileşenden en az biri dayanıklı olduğu sürece korunur. Anlamı, "şimdi yakala, sonra çöz" senaryosuna karşı koruma sağlamaktır; burada trafik, gelecekteki bir kuantum bilgisayar için arşivlenmektedir.
Müşterilerdeki uygulama zaman çizelgesi:
- Chrome 124 (Nisan 2024) - hibrit post-kuantum değişim varsayılan olarak etkin; curl-impersonate yamanlarında bu, "Chrome 124 ve 130'da tanıtılan X25519Kyber768/X25519MLKEM eğrileri" olarak kaydedilmiştir.
- Firefox 132 (Kasım 2024) - destek etkinleştirildi.
- iOS ve macOS'taki Safari - post-kuantum değişimi Ekim 2025'te geldi.
- OpenSSL 3.5.0 (Nisan 2025) - hibrit gruplar X25519MLKEM768, SecP256r1MLKEM768 ve SecP384r1MLKEM1024, TLS'nin varsayılan grup listesine eklendi.
- Go 1.24 (Şubat 2025) - X25519MLKEM768, Config.CurvePreferences açıkça belirtilmedikçe varsayılan olarak crypto/tls'ye dahil edildi.
Altyapı açısından tablo daha da belirgin. Cloudflare Radar, Nisan 2026'da yaklaşık %67 insan HTTPS trafiği post-kuantum şifreleme ile gösteriyordu - Ocak 2025'te %32'ye karşı. Akamai, post-kuantum anahtar değişimini tüm müşteri bağlantıları için 31 Ocak 2026'da varsayılan hale getirdi ve Mart ayında ağda dağıtımı tamamladı. Sektör ölçümlerine göre, yaklaşık %57,4 tüm tarayıcı işlemlerinin artık post-kuantum uyumlu olduğu, Chrome arasında PQ uyumlu oranının ise %93 civarında olduğu belirtiliyor.
Asimetriye dikkat edin: origin sunucularındaki destek çok daha yavaş artıyor (Cloudflare'da yaklaşık %9). Yani, post-kuantum günümüzde öncelikle bir müşteri özelliğidir. Tam olarak anti-botun ilgisini çeken şey.
Kriter 1: anahtar paylaşım boyutu ve ClientHello yapısı
Post-kuantum anahtar paylaşımı, "bir başka bayrak" değildir. Fiziksel olarak büyüktür: yaklaşık 1124 bayt klasik X25519'un 36 baytına karşı. Sonuçlar, paketler düzeyinde gözle görülür.
Post-kuantum anahtar paylaşımı ile ClientHello, 1400 baytı aşar ve bir TCP segmentine sığmaz. İki veya daha fazla pakete bölünür. Ve sonra tespit için en ilginç kısım başlar: farklı uygulamalardaki parçalanma deseni farklıdır. Yığın, büyük ClientHello'yu nasıl kesiyor, segmentleri hangi sırayla gönderiyor, hangi zamanlamalarla - bu gözlemlenebilir bir davranıştır ve bu, JA4 hash'inden çıkarılamaz ve scraping araçları yazarlarının çoğu bunu bilinçli olarak yeniden üretmez.
Pratik sonuç: anti-bot, alışıldık izlerin altında çalışan bir katmana sahip oldu. Şifreler ve uzantılar listesini mükemmel bir şekilde toplayabilirsiniz, ancak yığınınızın baytları sokete nasıl yerleştirdiğini gösterirseniz kendinizi ele vermiş olursunuz.
Kriter 2: tarayıcı versiyonu ile tutarlılık
2026 yılının en büyük tuzağı, kendinizi nasıl sunduğunuz ile TLS yığınınızın gerçekten ne yaptığı arasındaki senkronizasyon eksikliğidir.
Anti-bot platformları, referans ClientHello veritabanlarını tutar. User-Agent ve JA4'te Chrome 131 olarak beyan edilen bir istek, ancak post-kuantum anahtar paylaşımı olmadan gelirse, bilinen geçerli Chrome 131 ile eşleşmez. Bu "şüpheli" değil - bu mantıksal olarak imkansız bir kombinasyondur. Gerçek Chrome bu versiyonda varsayılan ayarlarla klasik anahtar paylaşımını gönderemez.
Makine öğrenimi ile bunun ne kadar iyi ayrıldığını da hesapladılar. JA4 özellikleri ile CatBoost sınıflandırıcısı, araştırmalarda AUC 0,998 ve doğruluk 0,9863 göstermektedir; ayrıca post-kuantum trafiği, klasik olandan yaklaşık %98 doğrulukla ayrılmaktadır. Bu "yanlış pozitiflerle birlikte bir heuristik" değil, neredeyse belirleyici bir özelliktir.
Kriter 3: belirli yığınların hazır oluşu
Burada gerçek bir ayrım çizgisi geçiyor. Gruplara ayıralım.
Varsayılan olarak PQ anahtar paylaşımı gönderirler
- Chrome 124+, Firefox 132+, Safari (iOS/macOS Ekim 2025'ten itibaren) - karşılaştırıldığınız standarttır.
- Go 1.24+ - crypto/tls, CurvePreferences'ı yeniden tanımlamadıysanız X25519MLKEM768'i kendiliğinden dahil eder. Önemli bir nokta: post-kuantum var, ancak çıplak Go istemcisinin JA4'ü yine de tarayıcıya benzemiyor. "PQ uyumlu ama Chrome'a benzemeyen" bir iz alırsınız.
- Node.js 24 - kendi OpenSSL 3.5'ini taşır, bu nedenle varsayılan grup listesi zaten hibrit içerir. Ayrıca node:crypto'da crypto.encapsulate()/decapsulate() ve ML-DSA'da sign()/verify() ile ML-KEM eklenmiştir.
Bağlı olduklarına bağlıdır
- Python: requests, aiohttp, httpx - ssl modülünü kullanır ve bu da sistem OpenSSL'ini alır. Ubuntu 24.04'te sistemde OpenSSL 3.0.x bulunur, burada post-kuantum grupları yoktur. PQ almak için OpenSSL 3.5'i kaynaklardan derlemek, LD_LIBRARY_PATH ile eklemek ve muhtemelen Python'u yeniden derlemek gerekir. Pratikte bu, tipik bir Python scraping aracı 2026'da klasik anahtar paylaşımını gönderir ve Akamai'da anomali olarak görünür.
Yapabilirler, ama sadece doğru profili seçerlerse
- curl_cffi / curl-impersonate - post-kuantum eğrileri desteği fork'ta mevcuttur ve açıkça belirtilmiştir. Ancak hedef listesi chrome99'dan chrome146'ya (fork'ta chrome150'ye kadar) uzanır ve eski profiller, kendi zamanlarının el sıkışmasını yeniden üretir, yani PQ olmadan. İki yıl önceki kılavuzdan
impersonate="chrome116"kopyalamak, tespit için doğrudan bir yoldur. - uTLS - aynı prensip: HelloChrome profilleri 131'den düşük PQ anahtar paylaşımını içermez. Ayrıca, 2026 yılı için kütüphanede iki izleme açığı kapatılmıştır: CVE-2026-26995 (1.6.0–1.8.1 sürümleri) ve CVE-2026-27017 (1.6.0–1.8.0, GREASE ECH için şifre seçimi senkronizasyonu - Chrome bunu belirleyici olarak seçerken, uTLS'deki parrot, AES ve ChaCha20 arasında bir madeni para atıyordu, bu gerçek Chrome için mümkün değildir). En az 1.8.2 sürümüne güncellenmelidir.
Ortak payda: araçlar genellikle yetişti. Sorun onlarda değil, konfigürasyonların tarayıcılardan daha hızlı yaşlandığı. 2024'te mükemmel olan bir profil, bugün bir işaretçi olarak çalışıyor.
Yığınınızı beş dakikada nasıl kontrol edersiniz
- Canlı istemcinizle
https://tls.peet.ws/api/allveyaja4db.comadresine bir istek gönderin - bunlar canlı JA3/JA4 ve ClientHello çözümlemesini JSON formatında döndürür. - Çözümlemede supported_groups ve key_share listesini bulun. X25519MLKEM768 (veya eski profillerde X25519Kyber768) arayın. Eğer sadece x25519/secp256r1 varsa - post-kuantum değişimi yoktur.
- Bunu kendinizi sunduğunuz tarayıcı versiyonu ile karşılaştırın. Chrome 131+ beyan ediyorsanız ve PQ gruplarını görmüyorsanız - kombinasyon geçersizdir, profilinizi düzeltin.
- ClientHello boyutuna bakın. Yeni bir Chrome beyanında ~1400 bayttan daha azsa - bu da başka bir işarettir.
- Her çıkış düğümünden kontrolü geçirin, sadece çalışma makinenizden değil: Kurumsal geçitte veya sağlayıcıda SSL denetimi, el sıkışmasını sizin yerinize yeniden yazabilir.
Proxy'ler burada ne yapıyor
İki bağımsız katmanı karıştırmamak önemlidir. Post-kuantum anahtar paylaşımı, el sıkışması ile ilgilidir, adresin itibarı ise ağ ile ilgilidir. Anti-bot bunları ayrı değerlendirir ve toplar.
Bundan iki pratik sonuç çıkar. Birincisi: mükemmel bir yerleşik IP, TLS düzeyinde PQ grubu olmadan kendini Chrome 131 olarak gösteren bir isteği kurtaramaz - sunucu adresi kontrol etmeden önce kaybedersiniz. İkincisi, tersine: doğru bir post-kuantum el sıkışması, yüzlerce oturumunuz kötü bir itibara sahip bir veri merkezi alt ağından geliyorsa işe yaramaz. Her iki katmanı da düzeltmek gerekir ve bunlar farklı araçlarla düzeltilir.
Görevler için pratik bir dağılım: Akamai ve Cloudflare için, burada hem el sıkışması hem de ağı dikkate alıyorlar, yerleşik proxy'ler almak ve aynı zamanda hedef impersonate'i yeni bir Chrome'a yükseltmek mantıklıdır. Mobil uygulamalar ve IP itibarının TLS gereksinimlerinden daha yüksek olduğu platformlar için genellikle mobil proxy'ler kazanır. Kendi API'leriniz, ortak yüklemeler ve iç izleme için, anti-bot yoksa, yerleşik için fazla ödeme yapmanın bir anlamı yok - veri merkezi proxy'leri yeterlidir.
İz bırakma ile sıfırdan başlıyorsanız, temelden başlayın: JA4'ün nasıl çalıştığı ve neler içerdiği. HTTP istemcisi değil de tam bir tarayıcı söz konusu olduğunda, stealth yapıların ve zayıf noktalarının karşılaştırması ayrı olarak toplanmıştır - nodriver, Camoufox ve Patchright 2026 ölçümlerinde.
Sonuç
Post-kuantum anahtar değişimi, anti-bot mekanizması olarak düşünülmemiştir. Dolaylı olarak bir anti-bot mekanizması haline geldi: tarayıcılar hızlı ve kitlesel olarak buna geçti, altyapı (Akamai - 31 Ocak 2026'dan itibaren) bunu varsayılan hale getirdi ve scraping yığınları üç gruba ayrıldı - geçiş yapanlar, sistem OpenSSL'ine bağımlı olanlar ve sadece yeni bir profil seçildiğinde yapabilenler.
Kontrol, bir soruya indirgenir: istemciniz X25519MLKEM768 gönderiyor mu ve bu, kendinizi sunduğunuz tarayıcı versiyonu ile uyumlu mu? Eğer hayırsa - eşleşen JA4 sizi kurtaramaz, çünkü artık karşılaştırılan sadece hash değil, el sıkışmasının tüm şeklidir: anahtar paylaşım boyutu, TCP segment sayısı ve bunların gönderim sırası. İyi haber, çoğu durumda bunun, scraping aracını yeniden yazmak yerine profil ve kütüphane sürümünü güncellemekle düzeltilebilmesidir.