WebRTC IP लीक डिटेक्शन: बग से फीचर तक

WebRTC — Web Real-Time Communication — को ब्राउज़र में सीधे वीडियो कॉल, फ़ाइल शेयरिंग और पीयर-टू-पीयर डेटा ट्रांसफर सक्षम करने के लिए डिज़ाइन किया गया था। इन कनेक्शनों को स्थापित करने के लिए ब्राउज़रों को अपने नेटवर्क इंटरफ़ेस खोजने और रिमोट पीयर के साथ कनेक्टिविटी पर बातचीत करने की ज़रूरत होती है। इस प्रक्रिया में STUN (Session Traversal Utilities for NAT) और TURN (Traversal Using Relays around NAT) सर्वर शामिल होते हैं, जो ब्राउज़रों को उनके पब्लिक IP पते खोजने और NAT फ़ायरवॉल पार करने में मदद करते हैं।

इसका साइड इफ़ेक्ट शक्तिशाली है: भले ही कोई उपयोगकर्ता VPN के माध्यम से जुड़ा हो, ब्राउज़र का WebRTC स्टैक टनल के पीछे का असली IP पता उजागर कर सकता है। ऐसा इसलिए होता है क्योंकि WebRTC ICE (Interactive Connectivity Establishment) कैंडिडेट में लोकल नेटवर्क इंटरफ़ेस के पते शामिल होते हैं जिन्हें VPN छिपा नहीं पाता।

लीक कैसे काम करता है

जब कोई ब्राउज़र RTCPeerConnection बनाता है और ICE कैंडिडेट इकट्ठा करता है, तो वह अपना पब्लिक-फेसिंग IP खोजने के लिए STUN सर्वर से पूछताछ करता है। लेकिन साथ ही वह लोकल नेटवर्क इंटरफ़ेस भी सूचीबद्ध करता है — जिसमें फ़िज़िकल अडैप्टर का प्राइवेट IP भी शामिल है। यदि VPN केवल IP लेयर पर ट्रैफ़िक टनल करता है लेकिन ब्राउज़र के WebRTC स्टैक को विशेष रूप से टनल इंटरफ़ेस उपयोग करने के लिए कॉन्फ़िगर नहीं करता, तो असली IP होस्ट कैंडिडेट के ज़रिए लीक हो जाता है।

tracio.ai पर, हम इस व्यवहार को सावधानी से प्रोब करते हैं। हमारा IP Intelligence सिस्टम एक नियंत्रित STUN अनुरोध बनाता है और ब्राउज़र द्वारा लौटाए गए ICE कैंडिडेट का विश्लेषण करता है। जब STUN से मिला पब्लिक IP हमारे सर्वर पर दिखने वाले IP से अलग होता है, तो हम VPN या प्रॉक्सी का फ़्लैग लगाते हैं। जब लोकल इंटरफ़ेस IP एक ऐसी प्राइवेट नेटवर्क रेंज उजागर करता है जो कथित भौगोलिक स्थान का खंडन करती है, तो हम संदेह स्कोर बढ़ा देते हैं।

बग से डिटेक्शन सिग्नल तक

अधिकांश प्राइवेसी-केंद्रित ब्राउज़रों ने इस लीक को पैच कर दिया है — Chrome WebRTC के लिए स्पष्ट उपयोगकर्ता अनुमति की मांग करता है, और Firefox नॉन-प्रॉक्सीड UDP को अक्षम करने की सेटिंग्स प्रदान करता है। लेकिन यह होड़ जारी है: कुछ VPN क्लाइंट WebRTC को ठीक से कॉन्फ़िगर नहीं करते, पुराने ब्राउज़र संस्करण अभी भी संवेदनशील हैं, और एक "पैच किए गए" बनाम "लीक करने वाले" WebRTC रिस्पॉन्स का व्यवहार पैटर्न अपने आप में एक उपयोगी सिग्नल है।

हमारा तरीका WebRTC रिस्पॉन्स को एक संयुक्त सिग्नल के रूप में मानता है: होस्ट कैंडिडेट की मौजूदगी, लौटाए गए ICE कैंडिडेट की संख्या, कैंडिडेट के प्रकार (host, srflx, relay), और रिस्पॉन्स टाइमिंग — सभी डिवाइस फ़िंगरप्रिंट में योगदान करते हैं। जब कोई IP लीक नहीं होता, तब भी WebRTC व्यवहार का पैटर्न विशिष्ट होता है।

TURN सर्वर प्रोबिंग

STUN के अलावा, हम TURN सर्वर व्यवहार को भी प्रोब करते हैं। TURN रिले आमतौर पर तब उपयोग होते हैं जब सीधे पीयर-टू-पीयर कनेक्शन विफल हो जाते हैं — जो सख़्त फ़ायरवॉल के पीछे कॉर्पोरेट नेटवर्कों में आम है। TURN एलोकेशन रिस्पॉन्स रिले पथ के बारे में जानकारी उजागर करता है: ट्रांसपोर्ट प्रोटोकॉल (UDP बनाम TCP बनाम TLS), रिले पता, और एलोकेशन लाइफ़टाइम।

हमारा SignalProbe सिस्टम हमारे अपने रिले सर्वरों को सावधानी से तैयार किए गए TURN एलोकेशन अनुरोध भेजता है। रिस्पॉन्स समय, समर्थित ट्रांसपोर्ट, और एलोकेशन की सफलता/विफलता के पैटर्न नेटवर्क परिवेश के अनुसार भिन्न होते हैं और डिवाइस फ़िंगरप्रिंटिंग के लिए अतिरिक्त सिग्नल विविधता प्रदान करते हैं।

प्राइवेसी संबंधी विचार

हम स्पष्ट करना चाहते हैं: tracio.ai उपयोगकर्ताओं की पहचान उजागर करने के लिए WebRTC लीक का दुरुपयोग नहीं करता। हमारा सिस्टम पता लगाता है कि कब VPN उपयोग में है और इसे एक जोखिम सिग्नल के रूप में रिपोर्ट करता है। हम कभी भी लीक हुए IP पते को संग्रहीत या उजागर नहीं करते। यह सिग्नल बाइनरी है: "WebRTC असंगति के साथ VPN का पता चला" या "WebRTC व्यवहार सीधे कनेक्शन के अनुरूप"।

यह तरीका फ्रॉड रोकथाम टीमों को वह जानकारी देता है जिसकी उन्हें ज़रूरत है — कि एक विज़िटर अपने असली स्थान को छिपा रहा है — बिना व्यक्तिगत प्राइवेसी से समझौता किए। यह सिग्नल उन समन्वित फ्रॉड हमलों का पता लगाने में मदद करता है जहाँ कई खाते एक ही छिपे हुए स्थान से उत्पन्न होते हैं।