یک سال پیش، طرح به وضوح مشخص بود: مشتری را میگرفتید که توانایی جعل دست دادن TLS را دارد، پروفایل را برای Chrome جدید تنظیم میکردید، JA4 مطابقتی را دریافت میکردید و ضد ربات اجازه میداد. در سال 2026، این دستورالعمل به دلیل دلیلی که هیچ ارتباطی با «دور زدن حفاظتها» ندارد، شروع به شکست کرد. مرورگرها به طور گستردهای به تبادل کلید پساکوانتومی منتقل شدند، در حالی که بیشتر استکهای اسکرپینگ این کار را نکردند. و اکنون، عدم وجود اشتراک کلید پساکوانتومی خود به خود یک علامت اتوماسیون است.
بیایید بر اساس معیارها بررسی کنیم: چه چیزی در دست دادن تغییر کرده است، کدام استکها قبلاً منتقل شدهاند، کدامها نه، و چرا هش JA4 مطابقت دیگر شرط کافی نیست.
چه اتفاقی افتاد: تبادل پساکوانتومی به یک قاعده تبدیل شد، نه یک استثنا
تبادل کلید پساکوانتومی ترکیبی از منحنی بیضوی کلاسیک X25519 و مکانیزم شبکهای ML-KEM (استاندارد NIST FIPS 203) است. جلسه در صورتی که یکی از دو مؤلفه پایدار باشد، محافظت میشود. هدف این است که از سناریوی «همین حالا ضبط کن، بعداً رمزگشایی کن» جلوگیری شود، زمانی که ترافیک به آرشیو نوشته میشود با امید به رایانه کوانتومی آینده.
تاریخچه پیادهسازی در مشتریان:
- Chrome 124 (آوریل 2024) — تبادل پساکوانتومی به طور پیشفرض فعال شده است؛ در وصلههای curl-impersonate این موضوع به عنوان «منحنیهای X25519Kyber768/X25519MLKEM که در Chrome 124 و 130 معرفی شدهاند» ثبت شده است.
- Firefox 132 (نوامبر 2024) — پشتیبانی فعال شده است.
- Safari در iOS و macOS — تبادل پساکوانتومی در اکتبر 2025 وارد شد.
- OpenSSL 3.5.0 (آوریل 2025) — گروههای ترکیبی X25519MLKEM768، SecP256r1MLKEM768 و SecP384r1MLKEM1024 به لیست پیشفرض گروههای TLS اضافه شدند.
- Go 1.24 (فوریه 2025) — X25519MLKEM768 به طور پیشفرض در crypto/tls فعال شده است، مگر اینکه Config.CurvePreferences به وضوح تعیین شده باشد.
از نظر زیرساخت، تصویر حتی واضحتر است. Cloudflare Radar در آوریل 2026 حدود 67% ترافیک HTTPS انسانی با رمزنگاری پساکوانتومی را نشان میداد — در مقابل 32% در ژانویه 2025. Akamai تبادل کلیدهای پساکوانتومی را به عنوان پیشفرض برای همه اتصالات مشتریان در 31 ژانویه 2026 انجام داد و توزیع در شبکه را در مارس به پایان رساند. بر اساس اندازهگیریهای صنعتی، حدود 57.4% از تمام تراکنشهای مرورگر قبلاً برای پساکوانتوم آماده هستند، به طوری که در بین Chrome سهم قادر به PQ حدود 93% است.
به عدم تقارن توجه کنید: پشتیبانی در سمت سرورهای مبدا به طور قابل توجهی کندتر رشد میکند (در Cloudflare — حدود 9%). بنابراین، پساکوانتومی بودن امروز به طور عمده یک ویژگی مشتری است. دقیقاً همان چیزی که برای ضد ربات جالب است.
معیار 1: اندازه اشتراک کلید و ساختار ClientHello
اشتراک کلید پساکوانتومی یک «پرچم دیگر در گسترش» نیست. این به طور فیزیکی بزرگ است: حدود 1124 بایت در مقابل 36 بایت برای X25519 کلاسیک. پیامدها به وضوح در سطح بستهها قابل مشاهده است.
ClientHello با اشتراک کلید پساکوانتومی از 1400 بایت فراتر میرود و دیگر در یک بخش TCP جا نمیگیرد. این به دو یا بیشتر بسته تقسیم میشود. و سپس جالبترین قسمت برای شناسایی آغاز میشود: الگوی تکهتکه شدن در پیادهسازیهای مختلف متفاوت است. اینکه استک چگونه ClientHello بزرگ را برش میدهد، چه ترتیبی برای ارسال بخشها دارد و با چه زمانبندیهایی — این رفتار قابل مشاهدهای است که از هش JA4 استخراج نمیشود و تقریباً هیچیک از نویسندگان ابزارهای اسکرپینگ به طور آگاهانه آن را بازتولید نمیکنند.
نتیجه عملی: ضد ربات یک لایه جدید دارد که زیر اثر انگشت معمولی کار میکند. شما میتوانید لیست رمزها و گسترشها را به طور کامل جمعآوری کنید، اما خود را با نحوه قرار دادن بایتها در سوکت فریب دهید.
معیار 2: سازگاری با نسخه اعلام شده مرورگر
دام اصلی سال 2026 — عدم همزمانی بین اینکه شما خود را چگونه معرفی میکنید و اینکه TLS استک شما واقعاً چه کاری انجام میدهد.
پلتفرمهای ضد ربات پایگاههای داده ClientHello استاندارد را نگه میدارند. درخواستی که در User-Agent و JA4 Chrome 131 را اعلام میکند، اما بدون اشتراک کلید پساکوانتومی میآید، با هیچ یک از Chrome 131 معتبر شناخته شده مطابقت ندارد. این یک «مشکوک» نیست — این یک ترکیب منطقی غیرممکن است. Chrome واقعی از این نسخه به طور فیزیکی نمیتواند در تنظیمات پیشفرض اشتراک کلید کلاسیک را ارسال کند.
اینکه این موضوع چقدر خوب توسط یادگیری ماشین تفکیک میشود نیز محاسبه شده است. طبقهبند CatBoost بر اساس ویژگیهای JA4 در تحقیقات نشان میدهد AUC 0.998 و دقت 0.9863; به طور جداگانه، ترافیک پساکوانتومی از کلاسیک با دقت حدود 98% متفاوت است. این یک «هیوریستیک با هشدارهای کاذب» نیست، این تقریباً یک ویژگی تعیینکننده است.
معیار 3: آمادگی استکهای خاص
اینجا واقعاً خط تقسیم واقعی میگذرد. بیایید بر اساس گروهها تقسیم کنیم.
به طور پیشفرض PQ key share ارسال میکنند
- Chrome 124+، Firefox 132+، Safari (iOS/macOS از اکتبر 2025) — استانداردی که با آن مقایسه میشوید.
- Go 1.24+ — crypto/tls به طور خودکار X25519MLKEM768 را شامل میشود، مگر اینکه شما CurvePreferences را بازنویسی کرده باشید. نکته مهم: پساکوانتومی بودن وجود دارد، اما JA4 در کلاینت خالی Go همچنان شبیه مرورگر نیست. شما یک اثر انگشت «سازگار با PQ، اما شبیه Chrome نیست» دریافت میکنید.
- Node.js 24 — OpenSSL 3.5 خود را دارد، بنابراین لیست پیشفرض گروهها شامل ترکیب است. علاوه بر این، در node:crypto ML-KEM از طریق crypto.encapsulate()/decapsulate() و ML-DSA در sign()/verify() اضافه شده است.
به آنچه متصل شدهاند وابستهاند
- Python: requests، aiohttp، httpx — از ماژول ssl استفاده میکنند و آن از OpenSSL سیستم استفاده میکند. در Ubuntu 24.04، OpenSSL 3.0.x در سیستم وجود دارد که گروههای پساکوانتومی در آن وجود ندارد. برای دریافت PQ، باید OpenSSL 3.5 را از کد منبع بسازید، از طریق LD_LIBRARY_PATH قرار دهید و احتمالاً خود Python را دوباره بسازید. در عمل، این به این معنی است که یک اسکرپر Python معمولی در سال 2026 اشتراک کلید کلاسیک را ارسال میکند و در Akamai به عنوان یک ناهنجاری به نظر میرسد.
میتوانند، اما فقط اگر پروفایل صحیح را انتخاب کنند
- curl_cffi / curl-impersonate — پشتیبانی از منحنیهای پساکوانتومی در فورک وجود دارد و به وضوح اعلام شده است. اما لیست اهداف از chrome99 تا chrome146 (در فورک — تا chrome150) کشیده شده است و پروفایلهای قدیمی دست دادن زمان خود را تولید میکنند، یعنی بدون PQ. کپیپیست
impersonate="chrome116"از راهنمای دو سال پیش — راهی مستقیم به شناسایی است. - uTLS — همان اصل: پروفایلهای HelloChrome زیر 131 شامل اشتراک کلید PQ نیستند. علاوه بر این، در کتابخانه برای سال 2026 دو آسیبپذیری اثر انگشت بسته شده است: CVE-2026-26995 (نسخههای 1.6.0–1.8.1) و CVE-2026-27017 (1.6.0–1.8.0، عدم همزمانی انتخاب رمز برای GREASE ECH — Chrome آن را به طور تعیینکننده انتخاب میکند، در حالی که parrot در uTLS سکهای بین AES و ChaCha20 پرتاب میکرد، که برای Chrome واقعی غیرممکن است). باید حداقل به 1.8.2 بهروزرسانی کنید.
مخرج مشترک: ابزارها عمدتاً به روز شدهاند. مشکل در آنها نیست، بلکه در این است که تنظیمات سریعتر از مرورگرها قدیمی میشوند. پروفایلی که در سال 2024 ایدهآل بود، امروز به عنوان یک نشانگر عمل میکند.
چگونه میتوان در پنج دقیقه استک خود را بررسی کرد
- درخواست را با مشتری واقعی خود به
https://tls.peet.ws/api/allیاja4db.comارسال کنید — آنها JA3/JA4 زنده و تجزیه ClientHello را در JSON بازمیگردانند. - در تجزیه، لیست supported_groups و key_share را پیدا کنید. به دنبال X25519MLKEM768 (یا X25519Kyber768 در پروفایلهای قدیمی) باشید. اگر فقط x25519/secp256r1 وجود دارد — تبادل پساکوانتومی وجود ندارد.
- این را با نسخه مرورگری که خود را معرفی میکنید، مقایسه کنید. اگر Chrome 131+ را اعلام میکنید و گروههای PQ را نمیبینید — ترکیب نامعتبر است، پروفایل را اصلاح کنید.
- به اندازه ClientHello نگاه کنید. کمتر از ~1400 بایت با Chrome جدید اعلام شده — همان نشانه، فقط از طرف دیگر.
- بررسی را از هر گره خروجی انجام دهید، نه فقط از ماشین کاری: بازرسی SSL در دروازه شرکتی یا ارائهدهنده میتواند دست دادن را به جای شما بازنویسی کند.
پروکسیها چه کار میکنند
مهم است که دو لایه مستقل را مخلوط نکنید. اشتراک کلید پساکوانتومی مربوط به دست دادن است، شهرت آدرس مربوط به شبکه است. ضد ربات آنها را به طور جداگانه در نظر میگیرد و جمع میکند.
از اینجا دو نتیجه عملی به دست میآید. اول: IP مقیم ایدهآل درخواست را نجات نخواهد داد، که در سطح TLS خود را به عنوان Chrome 131 بدون گروه PQ معرفی میکند — شما قبل از اینکه سرور به آدرس نگاه کند، شکست خواهید خورد. دوم، معکوس: یک دست دادن پساکوانتومی به درستی جمعآوری شده کمک نخواهد کرد، اگر صد جلسه شما از یک زیرشبکه دیتاسنتر با شهرت خراب بیاید. باید هر دو لایه را تعمیر کنید و آنها با ابزارهای مختلف تعمیر میشوند.
تقسیمبندی عملی بر اساس وظایف: برای اهداف در Akamai و Cloudflare، جایی که هم دست دادن و هم شبکه را در نظر میگیرند، معقول است که پروکسیهای مقیم بگیرید و به طور همزمان هدف impersonate را به Chrome جدید افزایش دهید. برای برنامههای موبایل و پلتفرمهایی که وزن شهرت IP بیشتر از الزامات TLS است، معمولاً پروکسیهای موبایل برنده میشوند. و برای APIهای خود، بارگذاریهای شریک و نظارت داخلی، جایی که ضد ربات وجود ندارد، پرداخت اضافی برای مقیم منطقی نیست — پروکسیهای دیتاسنتر کافی است.
اگر با اثر انگشت از صفر شروع میکنید، از پایه شروع کنید: JA4 چگونه کار میکند و چه چیزی را شامل میشود. و زمانی که صحبت از یک مرورگر کامل است، نه یک کلاینت HTTP، مقایسه ساختهای استلث و نقاط ضعف آنها به طور جداگانه جمعآوری شده است — nodriver، Camoufox و Patchright در اندازهگیریهای 2026.
نتیجهگیری
تبادل کلید پساکوانتومی به عنوان یک مکانیزم ضد ربات طراحی نشده است. او به طور غیرمستقیم به این تبدیل شده است: مرورگرها به سرعت و به طور گسترده به آن منتقل شدند، زیرساخت (Akamai — از 31 ژانویه 2026) آن را به عنوان پیشفرض قرار داد و استکهای اسکرپینگ به سه گروه تقسیم شدند — آنهایی که قبلاً منتقل شدهاند، وابسته به OpenSSL سیستم و آنهایی که فقط با پروفایل جدید کار میکنند.
بررسی به یک سوال خلاصه میشود: آیا کلاینت شما X25519MLKEM768 را ارسال میکند و آیا این با نسخه مرورگری که خود را معرفی میکنید، سازگار است؟ اگر نه — JA4 مطابقت شما را نجات نخواهد داد، زیرا اکنون نه تنها هش، بلکه کل شکل دست دادن به طور کامل مقایسه میشود: اندازه اشتراک کلید، تعداد بخشهای TCP و ترتیب ارسال آنها. خبر خوب این است که این موضوع در بیشتر موارد با بهروزرسانی پروفایل و نسخه کتابخانه حل میشود، نه بازنویسی اسکرپر.