मिरर से VPN इंस्टॉलर? पहले प्रकाशक की जाँच करें

टनल ने काम किया, इंटरफ़ेस आया और सत्र एक सप्ताह तक स्थिर रहा। इनमें से कोई भी बात नहीं बताती कि इंस्टॉलर किसने बनाया। VPN क्लाइंट रूट फिर से लिखने और क्रेडेंशियल पढ़ने के लिए पर्याप्त विशेषाधिकारों के साथ चलता है, इसलिए प्रकाशक ख़तरे के मॉडल का हिस्सा है, फुटनोट नहीं।

जाँचें क्रम में करें और पहली असफल जाँच पर रुकें। वे सस्ती हैं, और हर एक अलग खाई बंद करती है।

पहला चरण: उसी चैनल से डाउनलोड करें जिसका नाम प्रोजेक्ट बताता है

हर प्रोजेक्ट दर्ज करता है कि उसके रिलीज़ कहाँ रहते हैं, और वही पेज संदर्भ है। सामुदायिक बिल्ड, स्टोर सूचियाँ और विक्रेता पोर्टल सभी वैध चैनल हैं। हर एक तभी वैध है जब प्रोजेक्ट खुद उसकी ओर इशारा करे। यही परीक्षा है, और यह आधिकारिक दिखने जैसा नहीं है।

प्रोजेक्ट के नाम पर रखी फ़ाइल कुछ साबित नहीं करती। इंस्टॉलर का नाम बदलना एक सेकंड का काम है, और नाम ही वह चीज़ है जो खोज परिणाम पहले दिखाता है।

दूसरा चरण: ज्ञात पहचान के विरुद्ध हस्ताक्षर सत्यापित करें

हस्ताक्षर सत्यापन एक संकीर्ण प्रश्न का अच्छा उत्तर देता है। यह बताता है कि किसी विशेष पहचान ने इस बाइनरी पर हस्ताक्षर किए और वह बाइनरी तब से नहीं बदली। यह एक प्रश्न का उत्तर देता है और दूसरे से इनकार करता है। यह नहीं बता सकता कि वह पहचान वही है जिस पर आप भरोसा करना चाहते थे।

# macOS: who signed this app, and is the signature intact?
codesign -dv --verbose=4 /Applications/Tunnel.app
spctl -a -vvv -t install /Applications/Tunnel.app

# Windows: signature and publisher of the installer
Get-AuthenticodeSignature .\tunnel-setup.exe | Format-List Status, SignerCertificate

# Linux: detached signature from the project's release page
gpg --verify tunnel-1.4.2.tar.gz.asc tunnel-1.4.2.tar.gz

पहचान पढ़ें, स्थिति-शब्द नहीं। वैध प्रमाणपत्र वाला असंबंधित डेवलपर भी वैध हस्ताक्षर बनाता है। मान्यता प्राप्त प्रकाशक की सूचना देने वाला ऑपरेटिंग सिस्टम केवल यह बताता है कि किसी ने प्रमाणपत्र के लिए भुगतान किया।

तीसरा चरण: हैश की तुलना स्वतंत्र स्रोत से करें

चेकसम संदर्भ मान से मेल साबित करता है। यदि संदर्भ डाउनलोड के साथ आया है, तो दोनों एक साथ ग़लत हो सकते हैं और तुलना फिर भी पास हो जाती है। अधिकांश ट्यूटोरियल में विफलता का यही तरीका है। हैश उसी पेज पर होता है जिस पर वह फ़ाइल होती है जिसका वह वर्णन करता है।

# Linux and macOS
shasum -a 256 tunnel-1.4.2.dmg

# compare against the value published on the project's own release page
# not against a value copied from the same mirror

जब कोई प्रोजेक्ट हस्ताक्षरित चेकसम या हस्ताक्षरित रिलीज़ मैनिफ़ेस्ट प्रकाशित करता है, तो हस्ताक्षर हर फ़ाइल पर अलग से नहीं बल्कि सूची पर सत्यापित करें। इस तरह एक भरोसेमंद संदर्भ पूरे रिलीज़ को कवर करता है।

इंस्टॉलेशन के बाद: अपडेट पथ बनाए रखें

इंस्टॉलेशन पूरा होने के बाद भी समर्थित चैनल महत्वपूर्ण रहता है। पुनः पैकेज किए गए बिल्ड अपना अपडेटर लेकर आ सकते हैं, और वही अपडेटर तय करता है कि अगले महीने क्या चलेगा। जो बिल्ड कभी अपडेट नहीं होता वह अधिक सुरक्षित नहीं है। वह बस पुराना है।

लिखिए कि क्लाइंट को कैसे अपडेट होना चाहिए और क्या कोई प्रबंधन प्रणाली उस चरण की मालिक है। यदि उत्तर किसी फ़ोरम से मैन्युअल डाउनलोड है, तो आपूर्ति श्रृंखला का प्रश्न कभी वास्तव में बंद नहीं हुआ।

दो उत्पत्तियाँ, एक नहीं

क्लाइंट डेवलपर और प्रोफ़ाइल जारीकर्ता अलग पक्ष हैं। किसी आधिकारिक क्लाइंट का असंबंधित ऑपरेटर से प्रोफ़ाइल आयात करना सामान्य व्यवस्था है, और प्रोफ़ाइल अपनी जाँच का हक़दार है: किसने जारी किया, कैसे पहुँचाया गया, और क्या सर्वर प्रमाणपत्र उस नाम से मेल खाता है जिसकी आप अपेक्षा करते हैं।

अपने नोट्स में दोनों उत्पत्तियों को पहचानने योग्य रखें। जिस पल क्लाइंट बदला जाता है या डिवाइस बैकअप से बहाल किया जाता है, वही दो पंक्तियाँ अज्ञात बिल्ड या अज्ञात प्रोफ़ाइल को बाकी डेटा के साथ लौटने से रोकती हैं।