TLS फ़िंगरप्रिंटिंग और JA4 हैश की व्याख्या
TLS Client Hello संदेश डिवाइस पहचान के लिए सोने की खान क्यों हैं — और JA4 हैश हमें ऐसा स्थिर फ़िंगरप्रिंट कैसे देते हैं जो ब्राउज़र अपडेट के बाद भी टिका रहता है।
हर HTTPS कनेक्शन एक TLS handshake से शुरू होता है, और हर TLS handshake एक Client Hello संदेश से शुरू होता है। इस संदेश में कनेक्ट हो रहे क्लाइंट के बारे में ढेर सारी जानकारी होती है — cipher suites, extensions, समर्थित curves, signature algorithms — जो ब्राउज़रों, संस्करणों और ऑपरेटिंग सिस्टम में काफ़ी भिन्न होती है। TLS फ़िंगरप्रिंटिंग इस जानकारी को पकड़कर उसे पहचान के संकेत के रूप में इस्तेमाल करती है।
Client Hello में क्या होता है?
जब कोई ब्राउज़र किसी HTTPS सर्वर से कनेक्ट होता है, तो वह एक Client Hello संदेश भेजता है जिसमें होता है: उसके द्वारा समर्थित TLS संस्करण, उन cipher suites की सूची जिन्हें वह उपयोग करने को तैयार है, उसमें शामिल TLS extensions (जैसे SNI, ALPN और key share), उसके द्वारा समर्थित elliptic curves, उसके द्वारा स्वीकार किए जाने वाले signature algorithms, और उसके द्वारा प्रस्तावित compression methods।
हर ब्राउज़र परिवार का एक विशिष्ट फ़िंगरप्रिंट होता है। Chrome, Firefox और Safari सभी अलग-अलग cipher suite क्रम, अलग-अलग extension सेट और अलग-अलग curve वरीयताएँ भेजते हैं। एक ही ब्राउज़र परिवार के भीतर भी, अलग-अलग संस्करण थोड़े भिन्न Client Hello संदेश भेज सकते हैं क्योंकि cipher suites जोड़ी या हटाई जाती हैं।
JA3 से JA4 तक
JA3 मूल TLS फ़िंगरप्रिंटिंग हैश था, जिसे 2017 में Salesforce ने पेश किया। यह TLS संस्करण, cipher suites, extensions, elliptic curves और EC point formats को एक स्ट्रिंग में जोड़ता है और एक MD5 हैश की गणना करता है। हालाँकि यह अभूतपूर्व था, JA3 की सीमाएँ हैं: यह एक एकल अपारदर्शी हैश उत्पन्न करता है जिसका विश्लेषण करना कठिन है, और किसी भी फ़ील्ड में छोटा-सा बदलाव पूरी तरह भिन्न हैश उत्पन्न कर देता है।
JA4, जिसे 2023 में FoxIO ने पेश किया, कई तरीकों से JA3 पर सुधार करता है। यह तीन घटकों वाला एक संरचित फ़िंगरप्रिंट उत्पन्न करता है: एक मानव-पठनीय उपसर्ग (जैसे "t13d1715h2" — TLS 1.3, 17 cipher suites, 15 extensions, HTTP/2), cipher suites का एक क्रमबद्ध हैश, और extensions का एक क्रमबद्ध हैश। यह संरचना JA4 फ़िंगरप्रिंट को एक नज़र में विश्लेषण-योग्य बनाती है, साथ ही पहचान के लिए आवश्यक परिशुद्धता बनाए रखती है।
TLS फ़िंगरप्रिंट डिवाइस इंटेलिजेंस के लिए क्यों मायने रखते हैं
TLS फ़िंगरप्रिंट इसलिए मूल्यवान हैं क्योंकि इन्हें किसी भी JavaScript के निष्पादित होने से पहले एकत्र किया जाता है। एक बॉट जो अपना user agent स्पूफ़ करता है, अपनी canvas रेंडरिंग नकली बनाता है और अपनी navigator प्रॉपर्टीज़ पैच करता है, फिर भी जिस TLS लाइब्रेरी का वह वास्तव में उपयोग करता है उससे एक असली Client Hello संदेश भेजता है। अगर Client Hello कहता है "Go की crypto/tls लाइब्रेरी" पर user agent कहता है "Chrome 124," तो हमें पता चल जाता है कि कुछ स्पूफ़ किया जा रहा है।
यह क्रॉस-वैलिडेशन बॉट डिटेक्शन के लिए बेहद शक्तिशाली है। अधिकांश ऑटोमेशन फ़्रेमवर्क — Selenium, Puppeteer, Playwright — ब्राउज़र के नेटिव TLS स्टैक का उपयोग करते हैं, इसलिए उनके TLS फ़िंगरप्रिंट उस ब्राउज़र से मेल खाते हैं जिसे वे नियंत्रित करते हैं। लेकिन कस्टम HTTP क्लाइंट, Go-आधारित स्क्रैपर और requests लाइब्रेरी का उपयोग करने वाली Python स्क्रिप्ट सभी के TLS फ़िंगरप्रिंट विशिष्ट होते हैं जो उन्हें तुरंत गैर-ब्राउज़र क्लाइंट के रूप में पहचान देते हैं।
TLS फ़िंगरप्रिंट स्थिरता
TLS फ़िंगरप्रिंटिंग को लेकर एक चिंता ब्राउज़र अपडेट के दौरान स्थिरता की है। जब Chrome कोई cipher suite जोड़ता या हटाता है, तो TLS फ़िंगरप्रिंट बदल जाता है। व्यवहार में, यह उतनी बार नहीं होता जितना आप सोच सकते हैं। Chrome की cipher suite सूची अपेक्षाकृत स्थिर है — बड़े बदलाव साल में एक-दो बार होते हैं, हर संस्करण के साथ नहीं।
JA4 का संरचित प्रारूप यहाँ मदद करता है। मानव-पठनीय उपसर्ग छोटे संस्करण बदलावों में स्थिर रहता है (cipher suites और extensions की संख्या अक्सर नहीं बदलती), इसलिए जब विस्तृत हैश बदलता भी है, तो उपसर्ग निरंतरता प्रदान करता है। हमारे बहु-स्तरीय पहचान तंत्र में, TLS फ़िंगरप्रिंट डेटा Tier 2 में रखा जाता है — पहचान में योगदान देने के लिए पर्याप्त स्थिर, लेकिन अपेक्षित बहाव को संभालने के लिए क्रॉस-सेशन मिलान के ज़रिए संसाधित।
सर्वर-साइड संग्रह
JavaScript निष्पादन की आवश्यकता वाले क्लाइंट-साइड संकेतों के विपरीत, TLS फ़िंगरप्रिंट पूरी तरह सर्वर-साइड पर एकत्र किए जाते हैं। हमारे edge सर्वर कच्चे TLS handshake का निरीक्षण करते हैं और कनेक्शन स्थापित होने से पहले Client Hello निकाल लेते हैं। इसका मतलब है कि TLS फ़िंगरप्रिंटिंग तब भी काम करती है जब JavaScript ब्लॉक हो, जब ब्राउज़र में प्राइवेसी एक्सटेंशन इंस्टॉल हों, या जब क्लाइंट बिल्कुल भी ब्राउज़र न हो।
यह सर्वर-साइड प्रकृति TLS फ़िंगरप्रिंट को स्पूफ़िंग के प्रति प्रतिरोधी भी बनाती है। हालाँकि सैद्धांतिक रूप से किसी विशिष्ट ब्राउज़र की नकल करने वाला कस्टम TLS Client Hello गढ़ना संभव है, ऐसा करने के लिए निम्न स्तर पर TLS लागू करना पड़ता है — जो user agent स्ट्रिंग बदलने की तुलना में कहीं अधिक मेहनत है। अधिकांश स्पूफ़िंग टूल इसका प्रयास नहीं करते।
डिवाइस पहचान के साथ एकीकरण
हमारे डिवाइस पहचान इंजन में, TLS फ़िंगरप्रिंट एक संकेत और एक वैलिडेटर दोनों के रूप में कार्य करता है। एक संकेत के रूप में, यह अपने स्वयं के पहचान भार के साथ समग्र डिवाइस फ़िंगरप्रिंट में योगदान देता है। एक वैलिडेटर के रूप में, यह दावा की गई ब्राउज़र पहचान के विरुद्ध एक क्रॉस-चेक प्रदान करता है। अगर JavaScript संकेत कहते हैं "macOS पर Chrome" पर TLS फ़िंगरप्रिंट कहता है "Linux पर Firefox," तो यह विसंगति हमारे Smart Signals विश्लेषण में एक छेड़छाड़ फ़्लैग सक्रिय कर देती है।