AES-256 किसी VPN एन्क्रिप्शन सूट का वर्णन क्यों नहीं करता
एक सूट चार भूमिकाएँ निभाता है: थोक एन्क्रिप्शन, अखंडता, कुंजी स्थापन और सहकर्मी प्रमाणीकरण। एक सिफ़र नाम उनमें से एक को, एक परत पर कवर करता है।
पूछिए कि VPN कौन सा एन्क्रिप्शन इस्तेमाल करता है और जवाब आम तौर पर एक शब्द में आता है: AES-256, या ChaCha20, या शायद WireGuard। वह जवाब एक परत के एक घटक का नाम लेता है, जबकि कनेक्शन को वास्तव में बचाने वाली चीज़ चार अलग भूमिकाएँ निभाने वाले एल्गोरिदम का समूह है। घटक को व्यवस्था से मिला देना इन बातचीतों में सबसे आम गलती है, और इससे ऐसी तुलनाएँ बनती हैं जिन्हें सुलझाया नहीं जा सकता।
एक कनेक्शन के भीतर चार काम
थोक एन्क्रिप्शन डेटा चैनल के लिए सादे पाठ को सिफ़र पाठ में बदलता है, और उसकी कुंजी भेजी नहीं जाती बल्कि व्युत्पन्न की जाती है। अखंडता सुरक्षा बदलाव का पता लगाती है, जो अलग काम है, भले ही एक ही रचना दोनों करे। कुंजी स्थापन साझा ट्रैफ़िक सामग्री बनाता है, और सहकर्मी प्रमाणीकरण तय करता है कि दूसरे सिरे पर कौन है। इनमें से कोई एक भी छूटे तो कनेक्शन सुरक्षित नहीं है, बचा हुआ हिस्सा कितना भी मज़बूत हो।
कुछ डिज़ाइन दो भूमिकाओं को एक में जोड़ते हैं। AES-GCM और ChaCha20-Poly1305 प्रमाणित एन्क्रिप्शन रचनाएँ हैं, इसलिए गोपनीयता और अखंडता साथ आती हैं; AES-CBC नहीं है, और उसे अपनी कुंजी वाला अलग संदेश प्रमाणीकरण कोड चाहिए। इसलिए प्रस्ताव को स्वतंत्र संख्याओं की थैली की तरह पढ़ना उन्हें गलत पढ़ता है जो जोड़ों के रूप में बनाए गए थे।
भूमिकाएँ अलग अलग परतों पर भी होती हैं, इसीलिए एक ही शब्द दो उत्पादों में अलग बात कह सकता है। ESP के भीतर ब्लॉक सिफ़र और TLS के भीतर ब्लॉक सिफ़र अलग बातचीत में एक ही मूल तत्व हैं। इसलिए मोड और परत के बिना मूल तत्व का हवाला देना कुछ भी न कहने से बुरा हो सकता है।
सिफ़र का नाम लगभग कुछ क्यों नहीं कहता
AES-256 वाक्यांश को एक पल गंभीरता से लीजिए: यह ब्लॉक सिफ़र और कुंजी आकार बताता है। यह कार्य मोड, अखंडता मिलती है या नहीं, कुंजियाँ कैसे स्थापित हुईं या सहकर्मी का प्रमाणीकरण कैसे हुआ इस पर कुछ नहीं कहता। दो उत्पाद दोनों AES-256 का विज्ञापन कर सकते हैं और बाकी हर बात में अलग हो सकते हैं, जिनमें एक अप्रमाणित मोड के साथ और दूसरा आधुनिक कुंजी विनिमय के साथ AEAD मोड इस्तेमाल करता है।
TLS 1.3 ने इस अलगाव को मानक में लाया, जो पुरानी शब्दावली सीखने वाले हर व्यक्ति के लिए उपयोगी सुधार है। इसके सिफ़र सूट केवल AEAD और हैश का नाम लेते हैं, जबकि कुंजी विनिमय समूह और हस्ताक्षर एल्गोरिदम अलग पैरामीटर के रूप में बातचीत होते हैं। इसलिए TLS 1.3 सूट का नाम TLS 1.2 सूट के नाम से समान आधार पर तुलनीय नहीं है, हालाँकि दोनों कॉन्फ़िगरेशन फ़ाइल के एक ही फ़ील्ड में दिखते हैं। जो दो स्ट्रिंग की सीधी तुलना करता है वह ऐसा निष्कर्ष निकालता है जिसे प्रोटोकॉल समर्थन नहीं देता। बातचीत वाला समूह और हस्ताक्षर पैरामीटर भी पढ़िए, वरना तुलना अधूरी है।
WireGuard उलटा रास्ता चुनता है और बातचीत को लगभग पूरी तरह हटा देता है: प्रोटोकॉल एक निश्चित एल्गोरिदम समूह तय करता है, इसलिए दो कार्यान्वयन या तो साथ काम करते हैं या नहीं। यह वैध डिज़ाइन विकल्प है, और इसका यह भी अर्थ है कि WireGuard कौन सा सूट बातचीत करता है इस प्रश्न का तुलना योग्य जवाब नहीं है। अगर आप इसका ऑडिट कर रहे हैं, विनिर्देश एक बार पढ़िए और फिर बातचीत के बजाय उसके आसपास की कुंजी व्यवस्था का ऑडिट कीजिए।
परत शब्दावली तय करती है
IPsec परिनियोजन दो बार बातचीत करता है: नियंत्रण चैनल के लिए IKE प्रस्ताव और डेटा के लिए ESP रूपांतरण, और दोनों वैध रूप से अलग हो सकते हैं। पहले को पढ़कर मान लेना कि वह दूसरे का वर्णन करता है, ऑडिट के दौरान भ्रम का आम स्रोत है, क्योंकि कॉन्फ़िगरेशन फ़ाइल दोनों का ज़िक्र करती है और दिलचस्प दूसरा है।
| Layer | What is negotiated there | What it does not cover |
|---|---|---|
| IKE proposal | Algorithms and groups for the control channel that builds the tunnel | The algorithms protecting the data itself |
| ESP transform | Encryption and integrity for tunneled packets | Peer identity, which authentication already settled |
| TLS handshake | AEAD and hash, plus separately negotiated groups and signatures | Routing, authorization or retention policy |
| WireGuard | Nothing; the algorithm set is fixed by the protocol | Everything above the cryptographic arrangement |
एक लाइब्रेरी में उपलब्ध नाम दूसरे डेटा पथ के लिए अपने आप लागू नहीं होता। इसलिए यह दावा कि हमारा उत्पाद AES-256 का समर्थन करता है, सुनने में जितना लगता है उससे कमज़ोर है, और इसीलिए अंतर संचालनीयता की समस्या आम तौर पर दोनों ओर हर पुराने एल्गोरिदम को सक्षम करने के बजाय बनाए रखे गए प्रतिच्छेदन को खोजकर हल की जाती है।
TLS 1.3 का विनिर्देश इस अलगाव का सबसे स्पष्ट प्रकाशित उदाहरण है, क्योंकि यह सूट को जोड़ी के रूप में परिभाषित करता है और बाकी को उसकी अपनी बातचीत में भेजता है। एक बार वह आकार परिचित हो जाए, तो IPsec प्रस्ताव और एकमात्र निश्चित WireGuard समूह एक ही विचार के रूपांतर के रूप में पढ़े जाते हैं।
बातचीत का नतीजा पढ़िए, फिर रुकिए
कॉन्फ़िगर किया गया प्रस्ताव इस बात का प्रमाण नहीं है कि दो सहकर्मियों ने क्या चुना। जीवित सत्र में जवाब होता है, और हर मुख्यधारा का कार्यान्वयन पैकेट कैप्चर के बिना उसकी सूचना दे सकता है।
openssl s_client -connect vpn.example.net:443 -brief
ipsec statusall
wg showआउटपुट में दी गई सूची के बजाय चुने गए एल्गोरिदम पढ़िए। अगर जवाब नीति की मंशा से कमज़ोर है, तो सुधार किसी एक पक्ष के प्रस्ताव कॉन्फ़िगरेशन में है, और आधुनिक कार्यान्वयनों में असंगति आम तौर पर विफल बातचीत के रूप में दिखती है, चुपचाप गिरावट के रूप में नहीं।
फिर याद रखिए कि सूट क्या कवर नहीं करता। रूट, ऐप अनुमतियाँ, लॉगिंग और प्रतिधारण अपनी समीक्षा वाले अलग निर्णय हैं, और संगत क्रिप्टोग्राफ़िक व्यवस्था उनके बारे में कुछ नहीं कहती। सिफ़र की चर्चा की जानी चाहिए, लेकिन यह उस सवाल से संकरा जवाब देती है जो ज़्यादातर लोग असल में पूछते हैं।
शब्दावली सटीक रखिए और तर्क छोटा हो जाता है। सूट एक परत पर भूमिकाओं का समूह है, सिफ़र एक घटक है, और बातचीत का नतीजा ही एकमात्र चीज़ है जो उस कनेक्शन का वर्णन करती है जो आपके पास असल में है। तुलना में बाकी सब सजावट है।