WebRTC लीक: प्रॉक्सी के पीछे भी आपका असली पता क्यों दिख सकता है
WebRTC इसलिए है कि ब्राउज़र कॉल और स्क्रीन शेयरिंग के लिए एक-दूसरे से सीधे बात कर सकें। इसके लिए उन्हें वे पते खोजने पड़ते हैं जिन पर उन तक पहुँचा जा सकता है, और “WebRTC लीक” इसी खोज की प्रक्रिया को कहते हैं।
एक अनुच्छेद में ICE कैंडिडेट
जब कोई पेज RTCPeerConnection बनाता है और ऑफ़र शुरू करता है, तो ब्राउज़र कैंडिडेट इकट्ठा करता है: ऐसे तरीक़े जिनसे कोई दूसरा पीयर उस तक पहुँच सके। होस्ट कैंडिडेट स्थानीय इंटरफ़ेस का पता होता है। सर्वर-रिफ़्लेक्सिव (srflx) कैंडिडेट वह सार्वजनिक पता है जिससे STUN सर्वर ने रिक्वेस्ट आती देखी। रिले कैंडिडेट TURN सर्वर का पता होता है। हर कैंडिडेट पेज को टेक्स्ट की ऐसी पंक्ति में दिया जाता है जिसमें पता होता है, और इसी से कोई स्क्रिप्ट उसे पढ़ सकती है, बिना कोई कॉल किए।
लीक कहाँ है
srflx कैंडिडेट ही मायने रखता है। उसे पाने के लिए ब्राउज़र STUN सर्वर को एक छोटा UDP पैकेट भेजता है, जो जवाब में वह पता लौटाता है जो उसने देखा। अगर आपका HTTP ट्रैफ़िक प्रॉक्सी से गुज़रता है पर आपका UDP ट्रैफ़िक नहीं, तो STUN सर्वर आपका असली कनेक्शन देखता है, और पेज के पास अब ऐसा पता है जो वेब सर्वर के देखे पते से अलग है। यही असहमति क्लासिक लीक है। डायग्नोस्टिक पेज दोनों की तुलना करके इसे दिखा सकता है।
ध्यान दीजिए कि क्या हो रहा है और क्या नहीं। कोई मीडिया कैप्चर नहीं होता। माइक्रोफ़ोन या कैमरे की कोई अनुमति शामिल नहीं है। पैकेट उसी STUN सर्वर के पास जाता है जिसका नाम पेज ने दिया, इसलिए वह सर्वर, आपके संपर्क किए किसी भी सर्वर की तरह, आपका पता देखता है।
ब्राउज़रों ने क्या बदला
होस्ट कैंडिडेट पहले निजी LAN पते उजागर करते थे, जैसे 192.168.1.23, जो घरेलू नेटवर्क की फ़िंगरप्रिंटिंग के लिए उपयोगी थे। आधुनिक ब्राउज़र उनकी जगह .local पर ख़त्म होने वाले यादृच्छिक mDNS नाम रख देते हैं, इसलिए पेज को पता नहीं बल्कि अपारदर्शी नाम दिखता है। जो डायग्नोस्टिक “ब्राउज़र द्वारा छिपाया गया” बताता है, वह इन्हीं का वर्णन कर रहा होता है। Firefox और Brave ऐसी सेटिंग भी देते हैं जो प्रॉक्सी के बाहर कैंडिडेट इकट्ठा करना रोक देती हैं, और कुछ एक्सटेंशन WebRTC को पूरी तरह रोक देते हैं।
प्रॉक्सी-सुरक्षित कॉन्फ़िगरेशन
तीन तरीक़े काम करते हैं, अलग-अलग क़ीमत के साथ। WebRTC बंद करने से लीक रुक जाता है और हर वह साइट टूट जाती है जिसे उसकी ज़रूरत है। WebRTC को सिर्फ़ प्रॉक्सी के रूट का इस्तेमाल करने के लिए मजबूर करना (कुछ ब्राउज़रों में “प्रॉक्सी-सुरक्षित” मोड) कॉल चालू रखता है अगर प्रॉक्सी UDP या TURN का समर्थन करती है, और नहीं तो कोई सार्वजनिक कैंडिडेट ही नहीं देता। WebRTC को सामान्य रूप से चलने देना तभी सही है जब प्रॉक्सी सारा ट्रैफ़िक ले जाती हो, जैसा सिस्टम-स्तर का VPN आमतौर पर करता है।
कौन-सा सही है, यह काम पर निर्भर है। जिस अलग-थलग ब्राउज़र प्रोफ़ाइल को एक ही जगह मौजूद दिखना है, उसके लिए नियम सरल है: WebRTC जो पता उजागर करे वह वही हो जो वेब सर्वर देखता है, या कोई पता न हो। इसके अलावा कुछ भी ऐसा विरोधाभास है जिसे साइट बिना किसी विशेष टूल के नोटिस कर सकती है।
नतीजा पढ़ना
डायग्नोस्टिक कुछ सेकंड के भीतर जो कैंडिडेट उसने देखे उन्हें दिखाता है और किसी भी सार्वजनिक कैंडिडेट की तुलना उस पते से करता है जिससे पेज तक पहुँचा गया था। कुछ छिपे हुए कैंडिडेट के साथ “कोई उजागर नहीं” उस ब्राउज़र के लिए सामान्य, स्वस्थ नतीजा है जो WebRTC को प्रॉक्सी के भीतर रखता है। पेज के पते से अलग सार्वजनिक पता वह चीज़ है जिसे ठीक करना है।
