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आउटपुटमा दिइएको सूचीको सट्टा छानिएका एल्गोरिदम पढ्नुहोस्। जवाफ नीतिले चाहेभन्दा कमजोर भए सुधार एक वा अर्को पक्षको प्रस्ताव कन्फिगरेसनमा हुन्छ, र आधुनिक कार्यान्वयनमा असमझदारी सामान्यतया शान्त अवनति नभई असफल वार्ताका रूपमा देखिन्छ।
त्यसपछि सुइटले के समेट्दैन सम्झनुहोस्। मार्ग, अनुप्रयोग अनुमति, लगिङ र अवधारण आफ्नै समीक्षा भएका छुट्टै निर्णय हुन्, र अनुकूल क्रिप्टोग्राफिक व्यवस्थाले तिनीहरूबारे केही भन्दैन। साइफरको बहस गर्न लायक छ, तर यसले धेरै मानिसले साँच्चै सोध्ने प्रश्नभन्दा साँघुरो प्रश्नको जवाफ दिन्छ।
शब्दावली सटीक राख्नुहोस् र तर्क छोटो हुन्छ। सुइट भनेको एउटा तहमा भूमिकाहरूको समूह हो, साइफर एउटा घटक हो, र वार्ता भएको नतिजा मात्र त्यो कुरा हो जसले तपाईंसँग साँच्चै भएको जडानको वर्णन गर्छ। तुलनामा बाँकी सबै सजावट हो।