0x की 0s? ipsec.secrets मधील PSK स्वरूप समजून घेणे

एक क्लायंट सामायिक की ने प्रमाणीकरण करतो आणि दुसरा ती नाकारतो, तरी तुम्ही चिकटवलेली अक्षरे दोन्ही बाजूंना सारखीच दिसतात. बहुधा ती तीच अक्षरे आहेत; फरक एवढाच की फाइल त्यांच्यावर कोणता डीकोडिंग नियम लागू करते. उद्धरण चिन्हांतील स्ट्रिंग शब्दशः घेतला जातो, 0x ने सुरू होणारे टोकन हेक्साडेसिमल म्हणून वाचले जाते, आणि 0s ने सुरू होणारे टोकन Base64 म्हणून वाचले जाते. या तीन लेखनपद्धतींपैकी फक्त एकच तुमचा हेतू दर्शवते, त्यामुळे दुरुस्ती सहसा चांगला पासवर्ड नसून रूपांतरण असते.

लक्षण सिफरकडे नाही, एन्कोडिंगकडे निर्देश करते

जेव्हा दोन्ही टोके वेगवेगळे बाइट ठेवतात, वाटाघाटी तरीही यशस्वी होते आणि पुरावा नंतर अयशस्वी होतो. तेव्हा लॉग अल्गोरिदमच्या विसंगतीऐवजी अखंडता किंवा HMAC अयशस्वी नोंदवतो, कारण प्रस्ताव निवडला गेला होता आणि प्रमाणीकरणाची पायरी जुळली नाही. ती ओळ कधीही रहस्याचा आकार सांगत नाही.

टप्पाच हा सुगावा आहे. निवडलेल्या प्रस्तावानंतर येणारे अयशस्वी होणे म्हणजे दोन्ही बाजूंनी की सामग्रीशिवाय सर्व गोष्टींवर सहमती दर्शवली, तर «कोणताही प्रस्ताव निवडला नाही» हे धोरण किंवा सिफर संचांशी संबंधित आहे. पासवर्ड बरोबर दिसत असताना अयशस्वी होणारी अखंडता तपासणी हे एन्कोडिंग विसंगतीचे दृश्य स्वरूप आहे.

एक रहस्य, फाइल ते वाचू शकते अशा तीन पद्धती

चार बाइटच्या मूल्यासाठी key1 हेक्साडेसिमल आणि Base64 हे त्याच बाइटचे दोन पुन्हा-एन्कोडिंग आहेत, आणि फक्त सुरुवातीची अक्षरे पार्सरला सांगतात की त्याच्याकडे कोणते आहे. swanctl क्रेडेन्शियल्सही तीच प्रथा पाळतात, त्यामुळे दोन इंटरफेसांमध्ये हलवलेले मूल्य त्याचा अर्थ तेव्हाच टिकवते जेव्हा त्याचा उपसर्ग त्याच्यासोबत जातो.

10.20.0.5 %any : PSK "key1"
10.20.0.5 %any : PSK 0x6b657931
10.20.0.5 %any : PSK 0sa2V5MQ==

त्या ब्लॉकमधील दोन तपशील सर्वाधिक वेळ घेतात. हेक्साडेसिमल अंक दोन्ही केस स्वीकारतात, त्यामुळे 0x6b657931 आणि 0x6B657931 हे एकच मूल्य आहे, पण विषम संख्येने अक्षरे नाकारली न जाता शांतपणे चुकीची वाचली जातात, ज्यामुळे कापणीनंतरचा प्रत्येक बाइट सरकतो. Base64 पॅडिंग मूल्याचा भाग आहे, त्यामुळे शेवटच्या = चिन्हांशिवाय चिकटवलेला स्ट्रिंग मोठ्याने अयशस्वी न होता वेगळ्या बाइटमध्ये डीकोड होतो.

ज्या प्रोफाइलने मूल्य एकदा डीकोड केले आहे ते ते आधीच रूपांतरित करून टाकले आहे, त्यामुळे पुन्हा डीकोड केल्यास वेगळे बाइट आणि चुकीच्या पासवर्डसारखे दिसणारे प्रमाणीकरण अयशस्वी होते. अस्पष्ट गोष्टींसाठी उद्धरण चिन्हे ही सुरक्षित दिशा आहे, कारण सामग्री एन्कोडिंग चिन्हाने सुरू झाली तरी शब्दशः राहते.

Base64 मजकूर कुठून येतो

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

दोन्ही दिशा प्रत्येकी एक आदेश आहेत, आणि ज्या नेमक्या क्रियेने साठवलेले मूल्य तयार झाले त्या स्वरूपात त्या तिकिटात ठेवणे योग्य आहे. त्या या क्रमाने चालवा:

printf '%s' 'a2V5MQ==' | base64 -d
printf '%s' 'key1' | base64

एन्कोड केलेला मजकूर साधा मजकूर असल्यासारखा चिकटवणे ही महागडी चूक आहे. फाइल अक्षरे जशी लिहिली आहेत तशीच हॅश करते, व्युत्पन्न की सहकाऱ्याने गणलेल्या कीपेक्षा सुमारे एक तृतीयांश लांब येते, आणि प्रत्येक प्रयत्न कोणत्याही इशाऱ्याशिवाय त्याच पद्धतीने अयशस्वी होतो, कारण पार्सरने दिलेला नियम पाळला.

प्रत्येक सहकाऱ्याने प्रत्यक्षात कोणते बाइट वापरले ते तपासा

त्रुटीच्या स्ट्रिंगमधून कारण अंदाजण्याऐवजी आधी डेमनचे कनेक्शनबद्दलचे दृश्य आणि नंतर प्रमाणीकरणाचा निकाल वाचा. साठवलेली लांबी तुलना करणे ही जलद विचारपूर्वक तपासणी आहे, कारण एन्कोड केलेला मजकूर त्याने दर्शविलेल्या बाइटपेक्षा लांब असतो. नंतर कोणती ओळ जुळली ते तपासा, कारण चुकीच्या सहकाऱ्याखाली ठेवलेले बरोबर रहस्य चुकीच्या सारखेच अयशस्वी होते. ओळींचा क्रम हे ठरवतो: पहिले जुळणी जिंकते, त्यामुळे वरच्या जवळची रुंद %any ओळ तुम्ही नुकतीच संपादित केलेली विशिष्ट ओळ शांतपणे बदलते.

फाइल बरोबर झाल्यावर पुन्हा सुरू करण्याऐवजी पुन्हा लोड करा. ipsec rereadsecrets IKE डेमनची प्रत ताजी करते, आणि swanctl संरचना आपल्या स्वतःच्या आदेशाने क्रेडेन्शियल्स लोड करते. पुन्हा सुरू केल्याने प्रत्येक स्थापित संबंध सोडला जातो आणि तुम्ही करू पाहत असलेली तुलना नष्ट होते.

यापैकी कोणतीही तपासणी रहस्य उघड करण्याची मागणी करत नाही. लांबी, ओळख निवडक आणि ओळीचे स्थान या प्रकारच्या बहुतेक अयशस्वी घटना स्पष्ट करतात, कोणालाही हेक्स डंपची गरज पडण्यापूर्वी.

निकाल लपविल्याशिवाय फाइल बदला

फाइल डेमनच्या खात्यापुरती मर्यादित ठेवा, आणि जिवंत रहस्ये तिकिटे, चॅट आणि स्क्रीनशॉटपासून दूर ठेवा, कारण चिकटवलेली की ही गळती आहे, निदान नाही. ती तिला तयार करणाऱ्या घटनेपेक्षाही जास्त काळ टिकते.

ज्याची संरचना तुमच्या नियंत्रणात आहे अशा क्लायंटमधून चाचणी करा, प्रमाणीकरण यशस्वी होते याची खात्री करा, आणि नंतर बोगदा रहदारी वाहतो याची खात्री करा. जे पुन्हा-लोड हस्तांदोलन दुरुस्त करते पण मार्गनिर्देशन तुटलेले राहते ती वेगळी समस्या आहे, आणि रहस्य हलणे थांबताच ती दिसू लागते.