OpenConnect लॉगिन कुकी को टनल में कैसे बदलता है?

OpenConnect दो अलग-अलग अदान-प्रदानों को एक ही अल्पकालिक मान से जोड़ता है: वेब लॉगिन और VPN टनल। पहला अदान-प्रदान सामान्य HTTPS है: क्रेडेंशियल, एक SAML चक्कर या टोकन गेटवे तक जाता है, और जवाब प्रमाणीकरण कुकी लाता है। दूसरा अदान-प्रदान उसी कुकी को उसी गेटवे के सामने इस बात का सबूत बनाकर पेश करता है कि वेब चरण पहले ही हो चुका है, और तभी टनल ऊपर आता है।

लॉगिन के दौरान टनल के बारे में कुछ भी तय नहीं होता। यही वह हिस्सा है जिसे समझना ज़रूरी है, क्योंकि ज़्यादातर स्क्रिप्ट गलतियाँ मान लेती हैं कि कुकी कोई सहेजा जाने वाला पासवर्ड है, या ऐसी कुंजी है जो ट्रैफ़िक की रक्षा करती है, जबकि वह असल में किसी खास गेटवे सत्र के लिए एक वाहक टिकट है।

क्लाइंट और गेटवे क्रम से क्या अदान-प्रदान करते हैं

प्रमाणीकरण चरण एक सामान्य सुरक्षित वेबसाइट जैसा दिखता है। OpenConnect उपयोगकर्ता के क्रेडेंशियल भेजता है, या गेटवे के रीडायरेक्ट का पालन करते हुए किसी पहचान प्रदाता तक जाता है, और गेटवे ऐसे दस्तावेज़ से जवाब देता है जिसमें प्रमाणीकरण कुकी अंतर्निहित होती है। AnyConnect प्रोटोकॉल में यह मान अगले अनुरोधों में एक कुकी हेडर में जाता है, आम तौर पर webvpn जैसे नाम के नीचे, और मैनुअल इसे वह क्रेडेंशियल मानता है जो सत्र को आगे ले जाता है।

दूसरा चरण गेटवे के VPN एंडपॉइंट पर उस कुकी के साथ एक CONNECT अनुरोध है। गेटवे उसे जाँचता है, एक पता सौंपता है, और क्लाइंट TLS के ऊपर CSTP शुरू करता है, जबकि सत्र बन जाने पर DTLS एक वैकल्पिक तेज़ डेटा पथ है। केवल इसी बिंदु पर टनल के पैरामीटर, रूट, DNS सेटिंग्स और सत्र की ट्रैफ़िक कुंजियाँ स्थापित होती हैं। कुकी ने क्लाइंट को दरवाज़े से निकाला; उसने कुछ भी एन्क्रिप्ट नहीं किया।

यही क्रम समझाता है कि openconnect --authenticate क्यों मौजूद है। इसे चलाएँ और यह वेब चरण करता है, COOKIE, HOST, CONNECT_URL और FINGERPRINT जैसे शेल चरों का छोटा ब्लॉक छापता है, और फिर कोई टनल बनने से पहले बाहर निकल जाता है। इसके बाद एक रैपर स्क्रिप्ट उन मानों के साथ वास्तविक कनेक्शन शुरू कर सकती है, और हेडलेस या दो-कंटेनर परिनियोजन को ठीक इसी बँटवारे की ज़रूरत होती है।

कुकी सत्र का वाहक है, कुंजी नहीं

इस मान के साथ वैसे ही व्यवहार करें जैसे किसी वेब एप्लिकेशन में सत्र पहचानकर्ता के साथ करते हैं। जिसके पास अपने जीवनकाल में यह हो, वह गेटवे से वह टनल माँग सकता है जिसकी उस सत्र को हक़ है, इसलिए इसकी गोपनीयता ज़रूरी है। लेकिन इसे कॉपी करने से ट्रैफ़िक उजागर नहीं होता, क्योंकि टनल की गोपनीयता TLS हैंडशेक और उससे व्युत्पन्न कुंजियों से आती है, कुकी की शृंखला से नहीं।

यह स्थायी अनुमति भी नहीं है। गेटवे और पहचान प्रदाता तय करते हैं कि सत्र कितने समय जीवित रहेगा, और अभी भी लॉगिन दिखाने वाला ब्राउज़र इस बारे में कुछ नहीं कहता कि टनल सत्र अभी वैध है या नहीं। समाप्ति के बाद फिर से जुड़ने का मतलब है वेब चरण दोहराना और नई कुकी बनाना, और पुनःप्रमाणीकरण का यही उद्देश्य है, इंजीनियरिंग से बचने लायक झंझट नहीं।

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

कॉपियाँ छोड़े बिना कुकी पास करना

लिनक्स पर सबसे सुरक्षित यांत्रिक हैंडऑफ़ मानक इनपुट है। --cookie-on-stdin मान को stdin से पढ़ता है, इसलिए कुकी कभी प्रक्रिया की आर्ग्युमेंट सूची में नहीं दिखती, जहाँ कोई भी स्थानीय उपयोगकर्ता उसे ps से पढ़ सकता है। एक प्रक्रिया में प्रमाणीकरण करके दूसरी में टनल को खिलाने वाली पाइपलाइन मान को फ़ाइल या पर्यावरण चर के बजाय पाइप में रखती है।

आर्ग्युमेंट और पर्यावरण चर अलग-अलग कारणों से कमज़ोर हैं। आर्ग्युमेंट क्लाइंट के पूरे जीवनकाल तक प्रक्रिया तालिका में दिखता है और अक्सर शेल इतिहास में पहुँच जाता है। पर्यावरण चर संतान प्रक्रियाओं को विरासत में मिलता है, और यूनिट फ़ाइल में उसे सेट करने वाली systemd यूनिट रहस्य को पठनीय कॉन्फ़िगरेशन में रखती है। अगर फ़ाइल ज़रूरी हो, तो उसे सेवा खाते तक सीमित रखें और सत्र खत्म होने पर हटा दें।

विशेषाधिकार सीमा भी जानबूझकर रखें। जो प्रक्रिया पहचान प्रदाता से बात करती है और शायद ब्राउज़र खोलती है, उसे उसी उपयोगकर्ता के रूप में चलना चाहिए जिसका यह लॉगिन है। जो प्रक्रिया रूट, DNS और टनल डिवाइस कॉन्फ़िगर करती है, उसे ज़्यादा विशेषाधिकार चाहिए हो सकते हैं। root के स्वामित्व वाले टनल के लिए कुकी उपलब्ध कराने हेतु पूरा ब्राउज़र root के रूप में चलाना ग़लत सौदा है, और आधुनिक OpenConnect सेटअप उस सीमा के पार मान स्पष्ट रूप से दे सकते हैं।

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

दूसरे चरण में सत्यापन और समाप्ति

दूसरे चरण को अभी भी सर्वर सत्यापित करना है। --authenticate जो FINGERPRINT छापता है वह pin-sha256: रूप में प्रमाणपत्र पिन है, और उसे --servercert के साथ टनल कॉल को देना जाँच को उसी गेटवे पर लंगरित रखता है जिसके सामने आपने प्रमाणीकरण किया। स्क्रिप्ट आसान बनाने के लिए प्रमाणपत्र जाँच बंद करना इस बात का एकमात्र सबूत हटा देता है कि कुकी इच्छित होस्ट को दी जा रही है।

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

इसे स्वचालित करने से पहले चार बातें सत्यापित करें: टनल सही खाते के अंतर्गत चलता है, कुकी stdin से आती है, प्रमाणपत्र की फ़िंगरप्रिंट पिन है, और टनल बंद होने पर सत्र छोड़ दिया जाता है। इनमें से कोई भी न हो तो स्वचालन ने मैनुअल प्रवाह को दोहराने के बजाय कुकी पर भरोसा बढ़ा दिया है।