tls-auth बनाम tls-crypt: OpenVPN में कौन क्या सुरक्षित करता है

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

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

साझा कुंजी वास्तव में किसकी रक्षा करती है

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

tls-auth उस रहस्य का उपयोग नियंत्रण पैकेटों पर HMAC गणना करने के लिए करता है। वैध हस्ताक्षर के बिना पैकेट अधिक महँगे TLS प्रोसेसिंग तक पहुँचने से पहले ही गिरा दिया जाता है, इसलिए इस विकल्प को अक्सर TLS का विकल्प नहीं, बल्कि पहला फ़िल्टर कहा जाता है।

tls-crypt आगे बढ़ता है और सुरक्षित नियंत्रण ट्रैफ़िक को प्रमाणित करने के साथ-साथ एन्क्रिप्ट भी करता है। प्रमाणपत्रों की सामग्री, तय किए गए साइफ़र नाम और हैंडशेक के अन्य विवरण अब नेटवर्क पर दिखाई नहीं देते, और बिना कुंजी वाला प्रेक्षक यह भी नहीं देख सकता कि कौन-सा TLS संस्करण आज़माया जा रहा है। ऐसी तैनाती के लिए जिसे अपनी VPN पहचान उजागर होने की चिंता है, यही गुण इसे चुनने का मुख्य कारण है। यह फिर भी समूह रहस्य है, प्रति उपयोगकर्ता कोई क्रेडेंशियल नहीं।

कोई भी तंत्र पहचान जारी नहीं करता। साझा कुंजी एक समूह रहस्य है, और जिसके पास यह है वह जाँच की उस परत को पूरा कर सकता है।

दोनों विकल्प कहाँ भिन्न हैं

दिखने वाला अंतर यह है कि प्रेक्षक क्या देखता है। tls-auth के साथ हैंडशेक दिखाई देता है लेकिन कुंजी के बिना सत्यापित नहीं किया जा सकता। tls-crypt के साथ हैंडशेक उस हर व्यक्ति के लिए अपारदर्शी है जिसके पास कुंजी नहीं है।

विन्यास भी भिन्न है। tls-auth दिशा मान के साथ प्रयुक्त होता है, इसलिए एक पक्ष कुंजी सामग्री का एक आधा उपयोग करता है और दूसरा पक्ष दूसरा आधा। tls-crypt दोनों दिशाओं में एक ही कुंजी उपयोग करता है, इसलिए दिशा निर्देश उसकी व्यवस्था का हिस्सा नहीं है।

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

एक नया रूप, tls-crypt-v2, प्रत्येक क्लाइंट को उसकी अपनी लिपटी कुंजी से बाँधता है ताकि एक क्लाइंट को रद्द करने के लिए समूह कुंजी फिर से जारी न करनी पड़े। यह जानने योग्य है, पर यह अलग विकल्प है और यहाँ के दोनों में से किसी का पर्याय नहीं।

क्यों असंगति ऐसी दिखती है जैसे कुछ हो ही नहीं रहा

जब साझा सामग्री मेल नहीं खाती, तो दूसरा सिरा पैकेटों को बिना भेजने वाले को कारण बताए गिरा देता है। पढ़ने के लिए कोई प्रमाणीकरण त्रुटि नहीं होती, क्योंकि पैकेट उस परत तक कभी पहुँचा ही नहीं जो उसे बनाती।

क्लाइंट फिर कोशिश करता है, सर्वर कुछ नहीं कहता, और लक्षण नेटवर्क समस्या जैसा दिखता है। फिर लोग सेवा पुनः आरंभ करते हैं, खाते का पासवर्ड दोबारा लिखते हैं, या «परीक्षण» के लिए सुरक्षा निर्देश हटा देते हैं, जो निदान करने के बजाय तैनाती बदल देता है।

सर्वर लॉग में अंतिम पुनः प्रयास पंक्ति के बजाय पैकेट-स्तर की पहली शिकायत पढ़ें। पुष्टि करें कि दोनों पक्ष समान कुंजी सामग्री के साथ वही विकल्प रखते हैं और कुंजी फ़ाइल केवल एक ही पक्ष पर फिर से नहीं बनी।

निर्देश हटाना सुरक्षित मरम्मत नहीं है। यह हर क्लाइंट के लिए सुरक्षा की एक परत बंद कर देता है, और उसके बाद चलने वाली सुरंग केवल यह साबित करती है कि वही परत असंगति थी।

अभी भी क्या अलग से कॉन्फ़िगर करना होगा

ये विकल्प यह सत्यापित नहीं करते कि दूसरा सिरा कौन है। प्रमाणपत्र सत्यापन, विश्वास आधार और अपेक्षित सर्वर नाम अलग आवश्यकताएँ बने रहते हैं, और साझा कुंजी होने से इनमें से कोई वैकल्पिक नहीं होता।

वे डेटा साइफ़र भी नहीं चुनते। यह एक अलग बातचीत है जिसे दोनों सिरों की डेटा-चैनल सेटिंग्स नियंत्रित करती हैं, और tls-crypt से सुरक्षित सुरंग फिर भी ऐसा साइफ़र उपयोग कर सकती है जो आपका इरादा नहीं था।

अंत में, साझा कुंजी को स्वयं संभालने की ज़रूरत है। इसे रहस्य मानें, स्वीकृत चैनल से वितरित करें, और जब कोई भी इसे रखने वाला चला जाए तो इसे बदल दें। चूँकि यह साझा है, इसका उजागर होना इसका उपयोग करने वाले हर सिरे का उजागर होना है।