TLS फ़िंगरप्रिंट टेस्ट

TLS फ़िंगरप्रिंट एक सिग्नेचर है जो आपके ब्राउज़र के ClientHello से लिया जाता है — यानी वे साइफ़र सूट, एक्सटेंशन, एलिप्टिक कर्व और TLS वर्शन, जिन्हें वह हैंडशेक के दौरान अपने ठीक उसी क्रम में पेश करता है। चूंकि अलग-अलग ब्राउज़र, ऑपरेटिंग सिस्टम और HTTP लाइब्रेरी इन पैरामीटर को अलग-अलग तरीके से जोड़ते हैं, इसलिए यह फ़िंगरप्रिंट भरोसेमंद तरीके से पहचान लेता है कि किस तरह का क्लाइंट कनेक्ट हो रहा है। एंटी-बॉट सिस्टम इसका इस्तेमाल आपके पेज रिक्वेस्ट का एक भी बाइट पढ़े जाने से पहले असली ब्राउज़र को ऑटोमेशन से अलग पहचानने के लिए करते हैं।

JA3 मूल तरीका है: यह ClientHello से TLS वर्शन, साइफ़र सूट, एक्सटेंशन और कर्व को जोड़कर उन्हें एक 32-कैरेक्टर MD5 में हैश कर देता है। JA4 इसका आधुनिक उत्तराधिकारी है — यह इंसानों के पढ़ने लायक है, इसमें ज़्यादा फ़ील्ड शामिल होते हैं (जैसे ALPN और एक्सटेंशन की संख्या), और यह नए ब्राउज़र की लाई जाने वाली रैंडमाइज़ेशन के ख़िलाफ़ ज़्यादा मज़बूत है। JA4 से बचना ज़्यादा मुश्किल है और यह Cloudflare तथा दूसरे वेंडर का तेज़ी से अपनाया जा रहा स्टैंडर्ड बनता जा रहा है, इसलिए आप अक्सर दोनों को साथ-साथ रिपोर्ट किया हुआ देखेंगे।

JA3N, JA3 का एक नॉर्मलाइज़्ड वैरिएंट है। Chrome जैसे आधुनिक ब्राउज़र हर कनेक्शन पर TLS एक्सटेंशन का क्रम बदल देते हैं (यह एक फ़ीचर है, जिसे GREASE/एक्सटेंशन रैंडमाइज़ेशन कहते हैं), जिससे कच्चा JA3 हैश हर रिक्वेस्ट पर बदल जाता है। JA3N, हैश करने से पहले एक्सटेंशन को एक कैनॉनिकल क्रम में लगा देता है, जिससे एक स्थिर फ़िंगरप्रिंट बनता है जो हर हैंडशेक पर नहीं बदलता। यही स्थिरता ठीक वह वजह है, जिसके चलते फ़िंगरप्रिंटिंग सिस्टम नॉर्मलाइज़्ड हैश को तरजीह देते हैं।

अगर आपका कच्चा JA3 जांच-दर-जांच बदलता है, तो आम तौर पर इसकी वजह एक्सटेंशन रैंडमाइज़ेशन होती है। Chromium-आधारित ब्राउज़र जानबूझकर TLS एक्सटेंशन का क्रम बदलते हैं और GREASE वैल्यू डालते हैं, ताकि कोई एक स्टैटिक हैश आपको पिन न कर सके। नॉर्मलाइज़्ड रूप — JA3N और JA4 — उस शोर को हटा देते हैं और एक जैसे बने रहते हैं, यही वजह है कि एंटी-बॉट वेंडर कच्चे JA3 के बजाय इन पर भरोसा करते हैं।

हां, लेकिन यह User-Agent बदलने से कहीं ज़्यादा मुश्किल है। चूंकि फ़िंगरप्रिंट खुद TLS लाइब्रेरी से आता है, आप इसे JavaScript या किसी ब्राउज़र सेटिंग से नहीं बदल सकते — आपको एक ऐसा क्लाइंट चाहिए जो किसी असली ब्राउज़र के हैंडशेक की बाइट-दर-बाइट नकल करे, जैसे कोई TLS-इंपर्सनेशन लाइब्रेरी (curl-impersonate, utls) या किसी असली Chromium इंजन पर बना एंटीडिटेक्ट ब्राउज़र। हेडर को यूं ही एडिट करने से मदद नहीं मिलेगी: हैंडशेक किसी भी हेडर के भेजे जाने से पहले हो जाता है।

इसका मतलब है कि आपकी दो परतें अलग-अलग कहानियां बताती हैं। आपका User-Agent हेडर शायद “Windows पर Chrome 124” होने का दावा करे, लेकिन अगर आपका TLS हैंडशेक Python की requests लाइब्रेरी या Go के HTTP क्लाइंट से मेल खाता है, तो सर्वर को एक ऐसा विरोधाभास दिखता है जो कोई असली ब्राउज़र कभी पैदा नहीं करेगा। एंटी-बॉट सिस्टम इस बेमेल को ऑटोमेशन के सबसे मज़बूत संकेतों में से एक मानते हैं — अकेले User-Agent से कहीं ज़्यादा भरोसेमंद, जिसे कोई भी एक लाइन में दोबारा लिख सकता है।

आम तौर पर नहीं। कोई VPN या सामान्य HTTP/SOCKS प्रॉक्सी आपके ट्रैफ़िक को आगे भेजता है, लेकिन उस TLS हैंडशेक को नहीं छूता जो आपका ब्राउज़र बनाता है, इसलिए आपका JA3/JA4 वही रहता है — सिर्फ़ आपका IP बदलता है। अपवाद एक TLS-टर्मिनेटिंग प्रॉक्सी है, जो कनेक्शन को खुद फिर से बनाता है; वह प्रॉक्सी का अपना फ़िंगरप्रिंट लगा देता है, जो प्रदाता के आधार पर अच्छा हो सकता है (एक साफ़, ब्राउज़र जैसा हैंडशेक) या बुरा (एक साफ़ तौर पर ज़ाहिर प्रॉक्सी सिग्नेचर)।

आपका फ़िंगरप्रिंट आपके क्लाइंट से आता है, इसलिए असली हल यह है कि एक एक जैसा, ब्राउज़र-सटीक TLS स्टैक ऐसे IP के साथ जोड़ा जाए जो पूरी कहानी का साथ दे। ProxyWing के रेजिडेंशियल और मोबाइल प्रॉक्सी आपको साफ़, भरोसेमंद IP देते हैं जो असली उपभोक्ता कनेक्शन से मेल खाते हैं, इसलिए एक असली ब्राउज़र हैंडशेक और उसके साथ एक रेजिडेंशियल IP किसी डेटासेंटर ऑटोमेशन के बजाय एक आम यूज़र जैसा दिखता है। एक ऐसे एंटीडिटेक्ट ब्राउज़र के साथ मिलाकर, जो एक प्रामाणिक ClientHello बनाता है, इसी तरह आप अपने TLS, IP और User-Agent को एक ही सुसंगत कहानी कहते हुए बनाए रखते हैं।