एक साल पहले योजना स्पष्ट थी: आप एक ग्राहक लेते हैं, जो TLS-हैंडशेक को धोखा देने में सक्षम है, एक नए Chrome के लिए प्रोफ़ाइल चुनते हैं, एक मेल खाता JA4 प्राप्त करते हैं - और एंटीबॉट इसे पास कर देता है। 2026 में, यह नुस्खा विफल होने लगा, जिसका कारण "सुरक्षा को बायपास" से कोई संबंध नहीं है। ब्राउज़र बड़े पैमाने पर पोस्ट-क्वांटम कुंजी विनिमय पर चले गए, जबकि अधिकांश स्क्रैपिंग स्टैक नहीं गए। और अब पोस्ट-क्वांटम कुंजी साझा करने की अनुपस्थिति अपने आप में स्वचालन का एक संकेत है।
आइए मानदंडों के अनुसार विश्लेषण करें: हाथ मिलाने में क्या बदलाव आया है, कौन से स्टैक पहले ही चले गए हैं, कौन से नहीं, और क्यों मेल खाता हैश JA4 अब पर्याप्त शर्त नहीं है।
क्या हुआ: पोस्ट-क्वांटम विनिमय सामान्य हो गया, न कि विदेशी
हाइब्रिड पोस्ट-क्वांटम कुंजी विनिमय - यह क्लासिक अंडाकार वक्र X25519 और ग्रिड तंत्र ML-KEM (NIST FIPS 203 मानक) का संयोजन है। सत्र सुरक्षित रहता है, यदि इनमें से कम से कम एक घटक स्थिर हो। इसका अर्थ है "अब पकड़ो, बाद में डिक्रिप्ट करो" परिदृश्य से सुरक्षा, जब ट्रैफ़िक को भविष्य के क्वांटम कंप्यूटर के लिए आर्काइव में लिखा जाता है।
ग्राहकों में कार्यान्वयन की समयरेखा:
- Chrome 124 (अप्रैल 2024) - हाइब्रिड पोस्ट-क्वांटम विनिमय डिफ़ॉल्ट रूप से सक्षम है; curl-impersonate पैच में इसे "क्रिव्स X25519Kyber768/X25519MLKEM, जो Chrome 124 और 130 में पेश किए गए हैं" के रूप में दर्ज किया गया है।
- Firefox 132 (नवंबर 2024) - समर्थन सक्षम है।
- iOS और macOS पर Safari - पोस्ट-क्वांटम विनिमय अक्टूबर 2025 में आया।
- OpenSSL 3.5.0 (अप्रैल 2025) - हाइब्रिड समूह X25519MLKEM768, SecP256r1MLKEM768 और SecP384r1MLKEM1024 डिफ़ॉल्ट TLS समूहों की सूची में शामिल हो गए।
- Go 1.24 (फरवरी 2025) - X25519MLKEM768 crypto/tls में डिफ़ॉल्ट रूप से शामिल है, यदि Config.CurvePreferences स्पष्ट रूप से निर्दिष्ट नहीं किया गया है।
इन्फ्रास्ट्रक्चर की दृष्टि से चित्र और भी स्पष्ट है। Cloudflare Radar ने अप्रैल 2026 में लगभग 67% मानव HTTPS ट्रैफ़िक को पोस्ट-क्वांटम एन्क्रिप्शन के साथ दिखाया - जनवरी 2025 में 32% की तुलना में। Akamai ने 31 जनवरी 2026 को सभी ग्राहक कनेक्शनों के लिए पोस्ट-क्वांटम कुंजी विनिमय को डिफ़ॉल्ट बना दिया, और मार्च में नेटवर्क पर रोलआउट पूरा किया। उद्योग के माप के अनुसार, लगभग 57.4% सभी ब्राउज़र लेनदेन पहले से ही पोस्ट-क्वांटम-तैयार हैं, जिसमें Chrome में PQ के लिए सक्षम हिस्सेदारी लगभग 93% है।
असमानता पर ध्यान दें: मूल सर्वरों की ओर समर्थन कहीं अधिक धीमी गति से बढ़ रहा है (Cloudflare पर - लगभग 9%)। यानी आज पोस्ट-क्वांटम होना सबसे पहले ग्राहक की विशेषता है। यही वह है जो एंटीबॉट के लिए दिलचस्प है।
मानदंड 1: कुंजी साझा करने का आकार और ClientHello की संरचना
पोस्ट-क्वांटम कुंजी साझा करना "एक और फ्लैग एक्सटेंशन में" नहीं है। यह भौतिक रूप से बड़ा है: लगभग 1124 बाइट क्लासिक X25519 के 36 बाइट की तुलना में। परिणाम पैकेट स्तर पर स्पष्ट हैं।
पोस्ट-क्वांटम कुंजी साझा करने वाला ClientHello 1400 बाइट से अधिक हो जाता है और एक TCP सेगमेंट में समा नहीं पाता। यह दो या अधिक पैकेट में विभाजित हो जाता है। और फिर डिटेक्ट के लिए सबसे दिलचस्प हिस्सा शुरू होता है: विभाजन का पैटर्न विभिन्न कार्यान्वयनों में भिन्न होता है। स्टैक बड़े ClientHello को कैसे काटता है, किस क्रम में सेगमेंट भेजता है, किस समय के साथ - यह अवलोकनीय व्यवहार है, जो JA4 के हैश से नहीं निकाला जाता है और जिसे स्क्रैपिंग टूल्स के लेखकों में से लगभग कोई भी जानबूझकर पुन: उत्पन्न नहीं करता है।
व्यावहारिक निष्कर्ष: एंटीबॉट के पास एक परत है, जो नीचे सामान्य फिंगरप्रिंट के काम करती है। आप कुशलता से एन्क्रिप्शन और एक्सटेंशन की सूची बना सकते हैं, लेकिन यह दिखा सकते हैं कि आपका स्टैक बाइट्स को सॉकेट में कैसे डालता है।
मानदंड 2: ब्राउज़र के घोषित संस्करण के साथ संगति
2026 का मुख्य जाल - आप किसके रूप में प्रस्तुत होते हैं और आपका TLS स्टैक वास्तव में क्या कर रहा है, के बीच का असंगति।
एंटीबॉट प्लेटफार्मों के पास मानक ClientHello का डेटाबेस है। एक अनुरोध, जो User-Agent और JA4 में Chrome 131 के रूप में प्रस्तुत करता है, लेकिन पोस्ट-क्वांटम कुंजी साझा किए बिना आता है, किसी भी ज्ञात मान्य Chrome 131 के साथ मेल नहीं खाता। यह "संदिग्ध" नहीं है - यह तार्किक रूप से असंभव संयोजन है। असली Chrome इस संस्करण का क्लासिक कुंजी साझा करने को डिफ़ॉल्ट सेटिंग्स पर नहीं भेज सकता।
यह मशीन लर्निंग द्वारा कितनी अच्छी तरह विभाजित किया जाता है - यह भी गणना की गई है। JA4 के लक्षणों पर CatBoost वर्गीकरणकर्ता अनुसंधान में AUC 0.998 और सटीकता 0.9863 दिखाता है; अलग से पोस्ट-क्वांटम ट्रैफ़िक क्लासिक से लगभग 98% सटीकता के साथ भिन्न होता है। यह "झूठी सकारात्मकता के साथ ह्यूरिस्टिक्स" नहीं है, यह लगभग निश्चित लक्षण है।
मानदंड 3: विशिष्ट स्टैक्स की तैयारी
यहां वास्तविक विभाजन रेखा है। आइए समूहों में विभाजित करें।
डिफ़ॉल्ट रूप से PQ कुंजी साझा करते हैं
- Chrome 124+, Firefox 132+, Safari (iOS/macOS अक्टूबर 2025 से) - मानक, जिसके साथ आपको तुलना की जाती है।
- Go 1.24+ - crypto/tls X25519MLKEM768 को स्वयं शामिल करता है, यदि आपने CurvePreferences को पुनः परिभाषित नहीं किया है। महत्वपूर्ण बिंदु: पोस्ट-क्वांटम है, लेकिन कच्चे Go-क्लाइंट का JA4 फिर भी ब्राउज़र जैसा नहीं है। आपको "PQ-संगत, लेकिन Chrome जैसा नहीं" फिंगरप्रिंट मिलता है।
- Node.js 24 - अपने OpenSSL 3.5 के साथ आता है, इसलिए डिफ़ॉल्ट समूहों की सूची में पहले से ही हाइब्रिड शामिल है। इसके अलावा, node:crypto में crypto.encapsulate()/decapsulate() और ML-DSA में sign()/verify() के माध्यम से ML-KEM जोड़े गए हैं।
इस पर निर्भर करते हैं कि वे किससे जुड़े हैं
- 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 इसे निश्चित रूप से चुनता है, जबकि uTLS में पैरोट ने AES और ChaCha20 के बीच सिक्का उछाला, जो असली Chrome के लिए संभव नहीं है)। आपको कम से कम 1.8.2 तक अपडेट करना होगा।
सामान्य गुणांक: उपकरण मुख्य रूप से पकड़ में आ गए हैं। समस्या उनमें नहीं है, बल्कि इस बात में है कि कॉन्फ़िगरेशन ब्राउज़रों की तुलना में तेजी से पुराना हो जाता है। प्रोफ़ाइल, जो 2024 में आदर्श थी, आज एक मार्कर के रूप में काम करती है।
कैसे पांच मिनट में अपने स्टैक की जांच करें
- अपने कार्यात्मक ग्राहक से
https://tls.peet.ws/api/allयाja4db.comपर अनुरोध भेजें - ये जीवित JA3/JA4 और JSON में ClientHello का विश्लेषण लौटाते हैं। - विश्लेषण में supported_groups और key_share की सूची खोजें। X25519MLKEM768 (या पुराने प्रोफाइल में X25519Kyber768) की तलाश करें। यदि वहां केवल x25519/secp256r1 है - तो पोस्ट-क्वांटम विनिमय नहीं है।
- इसे उस ब्राउज़र के संस्करण के साथ मिलाएं, जिसके रूप में आप प्रस्तुत होते हैं। यदि आप Chrome 131+ का दावा करते हैं और PQ समूह नहीं देखते हैं - तो संयोजन अमान्य है, प्रोफ़ाइल ठीक करें।
- ClientHello के आकार पर ध्यान दें। यदि घोषित नए Chrome के साथ ~1400 बाइट से कम है - तो यह वही लक्षण है, केवल दूसरी तरफ से।
- हर आउटबाउंड नोड से जांच चलाएं, न कि केवल कार्य मशीन से: कॉर्पोरेट गेटवे या प्रदाता पर 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 सेगमेंट की संख्या और उनके भेजने का क्रम। अच्छी खबर यह है कि अधिकांश मामलों में, इसे प्रोफ़ाइल और पुस्तकालय के संस्करण को अपडेट करके ठीक किया जा सकता है, न कि स्क्रैपर को फिर से लिखकर।