OpenVPN नियन्त्रण प्याकेट ट्रेस गर्दै: TLS अघि tls-auth

tls-auth असफलता सामान्यतया ह्यान्डसेक समस्या भनेर रिपोर्ट गरिन्छ, तर यो कहिल्यै त्यस्तो थिएन। कुनै पनि TLS प्रशोधन सुरु हुनुअघि नियन्त्रण प्याकेटमा HMAC जाँचिन्छ, त्यसैले नमिल्ने कुञ्जी वा दिशाले प्रमाणपत्र समस्याजस्तो देखिने र दुई तह अगावै टुङ्गो लाग्ने असफलता उत्पन्न गर्छ। खामलाई छुट्टै वस्तु मान्दा निदान छोटो हुन्छ: फिल्डहरू पढ्नुहोस्, जाँच सुरुमै चल्ने पुष्टि गर्नुहोस्, अनि दुवै छेउले सहमत हुनुपर्ने तीन कुरा तुलना गर्नुहोस्।

खाम बनाइने क्रममै पढ्नुहोस्

नियन्त्रण प्याकेटले सत्र पहिचानकर्ता, वैकल्पिक tls-auth HMAC, पुनरावृत्ति र स्वीकृति जानकारी, र भरपर्दो सन्देश पहिचानकर्ता बोक्छ, र त्यसपछि सन्देश प्रकारको पेलोड आउँछ। सन्देश ह्यान्डसेक सन्देश भए पेलोड TLS साइफरटेक्स्ट हुन्छ। सम्बन्ध यत्ति नै हो: TLS सामग्री खामले पहिल्यै सुरक्षित गर्ने सन्देशभित्र यात्रा गर्छ। हेर्नुहोस् OpenVPN सञ्जाल प्रोटोकल सन्दर्भ जसले नियन्त्रण च्यानलका फिल्डहरू त्यही क्रममा सूचीबद्ध गर्छ।

भरपर्दोपन तहलाई क्रिप्टोग्राफी सम्झनु सजिलो छ। स्वीकृतिहरू, पुनःपठन र सन्देश पहिचानकर्ता अविश्वसनीय यातायातमा नियन्त्रण सन्देशहरू एकैचोटि र क्रममा पुगून् भनेर छन्। ती प्रमाणीकरण होइनन्, र सही सन्देश पहिचानकर्ताले प्याकेट कसले पठायो भन्ने कुरा केही पनि प्रमाणित गर्दैन।

यो समूहीकरण अवधारणात्मक राख्नुहोस्। यो बाइट-क्रम चित्र होइन, र ट्याग गणना गर्न पर्याप्त छैन, किनकि HMAC मा पस्ने फिल्डहरू कार्यान्वयन, संस्करण र मोडमा निर्भर हुन्छन्।

जाँच ह्यान्डसेक अघि चल्ने देखाउनुहोस्

साझा कुञ्जी भएको प्राप्तकर्ताले HMAC जाँची नक्कली प्याकेट तुरुन्तै फाल्न सक्छ, ह्यान्डसेक अवस्था छुट्याउनु वा सार्वजनिक कुञ्जीको काम गर्नु नपरी। सुरक्षाले सुरुका ह्यान्डसेक प्याकेटहरू पनि ढाक्छ, र त्यसै कारण गलत कुञ्जी ढिलो प्रमाणीकरण त्रुटिको रूपमा होइन, असफल जडानको रूपमा देखिन्छ।

डेमनको वर्बोसिटी बढाउनुहोस् र tun यन्त्रको सट्टा नियन्त्रण च्यानल हेर्नुहोस्:

openvpn --config /etc/openvpn/server.conf --verb 6

तपाईंले खोजिरहनुभएको कुरा प्याकेट तहमा रिपोर्ट हुने नियन्त्रण-च्यानल HMAC प्रमाणीकरण असफलता हो, कुनै पनि TLS चेतावनी अघि। लगमा TLS चेतावनी भन्नुको अर्थ खाम स्वीकारियो र असफलता भित्र सर्यो, जुन अर्कै समाधान भएको अर्कै अन्वेषण हो।

दिशा व्यवस्थापन पनि यहीँ छ। स्थिर कुञ्जी फाइल tls-auth सँग प्रयोग गर्दा दुवै छेउले विपरीत कुञ्जी दिशा लिन्छन्, र प्रोटोकलले त्यो विभाजन प्रयोग गरेर समातिएको प्याकेट आफ्नो प्रेषकतिर फर्केर परावर्तन हुन नसक्ने बनाउँछ। दिशा उल्ट्याउँदा कुञ्जी उही रहन्छ र तैपनि हरेक प्याकेट असफल हुन्छ। एकपटकमा एउटा छेउ बदल्नुहोस्, अनि जोडी सँगै लोड होस् भनेर दुवै डेमन पुनः सुरु गर्नुहोस्।

दुवै छेउमा कुञ्जी, दिशा र digest मिलाउनुहोस्

तीन मान मिल्नुपर्छ र तीमध्ये एउटा मात्र फाइल हो। स्थिर कुञ्जीको सामग्री दुवै छेउमा समान हुनुपर्छ, दिशा विपरीत हुनुपर्छ, र HMAC का लागि प्रयोग हुने digest मिल्नुपर्छ। कुञ्जी सामग्री छुनुअघि कन्फिगरेसन जाँच्नुहोस्, किनकि एउटा उल्टो दिशाले बिग्रिएको फाइलभन्दा बढी असफलता व्याख्या गर्छ:

grep -E 'tls-auth|tls-crypt|key-direction|auth ' /etc/openvpn/server.conf

साझा रहस्य सम्पादकको सट्टा उपकरणले बनाउनुहोस्, र अनुमतिहरू कडा राख्नुहोस्:

openvpn --genkey secret /etc/openvpn/ta.key
chmod 600 /etc/openvpn/ta.key

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

tls-auth लाई tls-crypt सँग नमिसाउनुहोस्। दुवैले नियन्त्रण च्यानल सुरक्षित गर्छन्, तर tls-crypt ले यसलाई इन्क्रिप्ट पनि गर्छ र पर्यवेक्षकहरूबाट ह्यान्डसेक लुकाउँछ, र दिशा विभाजनलाई आफ्नै कुञ्जी व्यवस्थापनले प्रतिस्थापन गर्छ। एउटा प्रयोग गर्ने प्रोफाइल अर्कोका लागि कन्फिगर गरिएको साथीसँग काम गर्दैन, र कुनै पनि digest ट्युनिङले त्यो खाडल पुरिदैन।

ट्याग वास्तविक ढाँचाबाट मात्र पुनःउत्पादन गर्नुहोस्

बाइट-ठ्याक्कै पुनःउत्पादन VPN चलाउनुभन्दा छुट्टै काम हो, र यो वास्तविक इनपुटसँग मात्र चल्छ: प्याकेट बनाउने कार्यान्वयन र संस्करण, छानिएको digest, दिशा, र सत्र पहिचानकर्ता तथा स्वीकृति एरे सहितका वास्तविक बाइट। फिल्ड सूचीको पाठ्य प्रस्तुति ती बाइट होइनन्।

ट्यागको लम्बाइ digest बाट आउँछ, त्यसैले स्थिर लम्बाइको अनुमान कसैले यो बदल्ने क्षणमै टुट्छ। प्याकेटलाई कार्यान्वयनले गरेझैँ ह्यास गर्नुहोस्, ब्लग पोस्टको तालिकाले प्रस्तुत गरेझैँ होइन, र हातले निकालेको अपेक्षासँग होइन, त्यही साथीबाट लिइएको क्याप्चरसँग तुलना गर्नुहोस्।

यो अभ्यासलाई उत्पादन प्रोफाइलबाट टाढा राख्नुहोस्। ट्याग पुनःउत्पादन गर्नुमा कुनै तैनाथीले सुरक्षा सक्रिय गर्नुपर्छ कि भन्ने कुरा केही पनि बताउँदैन।

सुरक्षा नहटाई असमझदारी फर्काउनुहोस्

लोभ्याउने परीक्षण भनेको tls-auth मेटाउनु, जडान सफल भएको देख्नु र कुञ्जी गलत थियो भन्ने निष्कर्ष निकाल्नु हो। त्यो उत्तरले सुरक्षा खर्च गराउँछ र तीनमध्ये कुन मान नमिलेको थियो भन्ने केही सिकाउँदैन। त्यसको सट्टा सर्भर पक्षबाट स्वीकृत मिल्ने कन्फिगरेसन लिनुहोस् र त्यससँग तुलना गर्नुहोस्।

परिवर्तनलाई उल्टाउन सकिने गरी तयार पार्नुहोस्। अघिल्लो सर्भर कन्फिगरेसन र कुञ्जी फाइल राख्नुहोस्, सुधारिएको जोडी लागू गर्नुहोस्, कुनै क्लाइन्टले ह्यान्डसेक पूरा गर्छ भनी प्रमाणित गर्नुहोस्, र त्यसपछि मात्र ब्याकअप हटाउनुहोस्। परिवर्तनपछि क्लाइन्टहरू असफल भए, अवरोधका बेला तेस्रो प्रकार बनाउनुको सट्टा अघिल्ला फाइलहरू पुनःस्थापित गर्नुहोस्। पुनःस्थापन सुरु गर्नुअघि नै थाहा भएको एउटै आदेश हुनुपर्छ।

अन्तमा, उत्तीर्ण जाँचको अर्थ सम्झनुहोस्। यसले साथीसँग साझा कुञ्जी छ भनी प्रमाणित गर्छ, उसको प्रमाणपत्र वा खाता अधिकृत छ भनी होइन, र यसले वार्ता गरिएको डेटा-च्यानल साइफरबारे केही भन्दैन. अधिकार र डेटा सुरक्षा पछि स्थापित हुन्छन्, त्यसैले सफा खाम जाँच सुरुवाती बिन्दु हो, फैसला होइन।