OpenVPN tls-crypt-v2: क्लायंट की आणि गुंडाळलेला blob काय करतात
tls-crypt-v2 प्रोफाइलमध्ये क्लायंटची नियंत्रण की आणि फक्त सर्व्हर उघडू शकणारी गुंडाळलेली प्रत असते. प्रत्येक ऑब्जेक्ट आणि मागे घेण्याची प्रत्येक पायरी वेगळी ठेवा.
tls-crypt-v2 प्रोफाइल तिकिटात चिकटवणे, फाइलमध्ये काय आहे याची गणती करेपर्यंत निरुपद्रवी वाटते। क्लायंटची नियंत्रण-चॅनेल की त्याच कीच्या एन्क्रिप्टेड प्रतीजवळ बसते, आणि तिसरा ऑब्जेक्ट, गुंडाळणारी की, स्वीकारणाऱ्या सर्व्हरला कधीही सोडत नाही। हे तीनजण कोठार, सामायिकरण आणि मागे घेणे याबद्दल वेगवेगळ्या प्रश्नांची उत्तरे देतात। त्यांना वेगळे ठेवल्यास बहुतेक धोरणविषयक वाद सुरू होण्यापूर्वीच मिटतात।
प्रोफाइलमध्ये प्रत्यक्षात काय असते
tls-crypt-v2 चा क्लायंट अर्धा भाग म्हणजे की आणि तिची गुंडाळलेली प्रत। क्लायंट नियंत्रण-चॅनेलच्या संरक्षणासाठी साधी की वापरतो आणि सेटअपच्या वेळी गुंडाळलेली प्रत सर्व्हरला देतो, त्यामुळे सर्व्हर प्रत्येक क्लायंटसाठी स्पष्ट मजकूर प्रत साठवल्याशिवाय तीच की पुन्हा मिळवतो। गुंडाळणारी की ती पुनर्प्राप्ती शक्य करते आणि फक्त स्वीकारणाऱ्या बाजूची असते। खालील सर्व काही ते तीन ऑब्जेक्ट कुठे राहतात यावरून येते।
| Object | Where it lives | What can open it | What a leak costs |
|---|---|---|---|
| Server wrapping key | accepting servers only | the unwrap step inside the server | every wrapped copy issued to that group becomes readable |
| Wrapped client key | inside the client profile | the server wrapping key | it names a client and exposes its metadata, but not the key inside |
| Client control key | inside the client profile, usable as-is | the client that owns it | someone can open handshakes as that client until the server refuses the key |
तक्ता नावाने नव्हे, तर कोठाराने वाचा आणि परिणाम स्वतः स्पष्ट होतात। गुंडाळणारी की गमावणे ही महागडी घटना आहे, कारण प्रोफाइलमधील काहीही ती पुन्हा तयार करू शकत नाही आणि प्रामाणिक पुनर्प्राप्ती म्हणजे गट पुन्हा जारी करणे। गळलेले प्रोफाइल स्वस्त पण खूप सामान्य आहे, कारण गुंडाळलेली प्रत फाइल सामायिक करण्यास सुरक्षित करते असे मानणारे लोक प्रोफाइल तिकिटांमध्ये चिकटवतात। दोन अपयशांना वेगळ्या प्रतिक्रिया लागतात, म्हणूनच ऑब्जेक्ट वेगळे ठेवले जातात।
गुंडाळलेली प्रत संपूर्ण कथा का नाही
प्रोफाइल उपयुक्त क्लायंट सामग्री तिच्या गुंडाळलेल्या जोडीदारासह वाहते, म्हणून सर्व्हरसाठी प्रतीचे संरक्षण फाइलच्या संरक्षणाबद्दल काहीही सांगत नाही। Blob पाठवण्यास सुरक्षित आणि प्रकाशित करण्यास असुरक्षित आहे। त्यातील मेटाडेटा blob मिळणाऱ्या प्रत्येकाला दिसतो, ती चिकटवलेले तिकिट नंतर वाचणाऱ्यालाही।
प्रोफाइलला कॉन्फिगरेशन नमुना नव्हे, तर ओळखपत्र माना। गळलेली फाइल तिच्या धारकाला सर्व्हर ती ओळख स्वीकारणे थांबवेपर्यंत चालणारी क्लायंट ओळख देते, आणि गुंडाळणी त्या खिडकीबद्दल काहीही करत नाही। प्रत्येक क्लायंटसाठी एक प्रोफाइल जारी करा जेणेकरून मागे घेणे एका फाइलचा निर्णय राहील, आणि गुंडाळणाऱ्या कीचा बॅकअप ती सक्षम करणाऱ्या सर्व्हर कॉन्फिगरेशनपासून वेगळा ठेवा। दोन्ही सवयी छेडलेले प्रोफाइल दुरुस्त करत नाहीत, पण दोन्ही पुढील प्रोफाइल किती लवकर आटोक्यात येईल हे ठरवतात।
हँडशेकमध्ये पडताळणी हुक कुठे बसतो
पडताळणी हुक TLS स्टॅक उघडण्यापूर्वी चालतो, आणि त्याचे काम गुंडाळलेल्या blobमध्ये वाहून नेलेला मेटाडेटा तपासणे आहे। त्याला तो मेटाडेटा आणि लहान, दस्तऐवजीकृत वातावरण मिळते, आणि प्रमाणीकरण हुकपेक्षा त्याच्याकडे काम करण्यासाठी कमी सामग्री असते। तो वापरकर्तानावे, सत्र स्थिती किंवा प्लगइन चल पाहू शकतो असे गृहीत धरणे हा हुक वाईट लिहिण्याचा नेहमीचा मार्ग आहे। दुसऱ्या हुककडून अपेक्षा उसनवार घेण्याऐवजी हुकचा स्वतःचा पुस्तिका विभाग वाचा।
त्याची निर्गमन स्थिती हा निर्णय आहे: शून्य नसलेला निकाल क्लायंटला नाकारतो आणि शून्य निकाल हँडशेक सुरू ठेवू देतो। म्हणून धोरणाने मेटाडेटा गहाळ, विश्लेषण करता न येणारा किंवा अनपेक्षित असताना काय होते ते सांगितले पाहिजे। आधी नकाराचा मार्ग लिहा, मग कोणती मूल्ये स्वीकार्य आहेत ते ठरवा।
tls-crypt-v2 /etc/openvpn/server/tcv2-server.key
tls-crypt-v2-verify /etc/openvpn/server/verify-client-metadata.shत्या दोन ओळी सर्व्हरवरील धोरणाचा पृष्ठभाग आहेत: एक गुंडाळणाऱ्या कीचे नाव घेते, दुसरी प्रत्येक क्लायंटचा निर्णय करणाऱ्या कार्यक्रमाचे। मनोरंजक सर्व काही स्क्रिप्टमध्ये आहे, जी आवृत्ती नियंत्रण आणि इतर कोणत्याही प्रवेश नियमासारखे पुनरावलोकन पात्र आहे।
खाते, प्रमाणपत्र आणि नियंत्रण की वेगवेगळ्या मागे घेतल्या जातात
नियंत्रण-चॅनेलची लवकर स्वीकृती हे प्रमाणीकरण नाही, कारण ती TLS ओळख तपासणीपूर्वी आणि कोणत्याही खाते अधिकृततेपूर्वी होते। खाते बंद करणे, प्रमाणपत्र रद्द करणे आणि क्लायंट नियंत्रण की नाकारणे या तीन यंत्रणा असलेल्या तीन क्रिया आहेत। त्यातील फक्त एक करणाऱ्या तैनातीत धोरणाऐवजी पोकळी असते। तीनही जाणूनबुजून जुळवा, आणि कोणती पायरी कोणता अधिकार वापरते ते नोंदवा।
वेळ हा दुसरा फरक आहे। बदललेली स्वीकृती यादी नवीन हँडशेकवर लागू होते, तर आधीच स्थापित सत्रे काही त्यांना संपवेपर्यंत चालू राहतात। नवीन यादीतील नोंदी जुन्या सत्रे संपल्याचा पुरावा म्हणून मोजणे हा काढून टाकलेला क्लायंट तासन्तास जोडलेला राहण्याचा मार्ग आहे।
न जुळवलेले अधिकार सरावात सहज सापडणारी दोन छिद्रे सोडतात। खाते बंद असतानाही त्याची नियंत्रण की अजूनही हँडशेक उघडते, आणि प्रमाणपत्र रद्द असतानाही मेटाडेटा धोरण तोच क्लायंट अजूनही स्वीकारते। दोन्ही वेगवेगळ्या ठिकाणची एकच चूक आहेत, कारण ऑपरेटरने एक यादी संपूर्ण अधिकार मानली। काढण्याच्या वेळी तीन याद्या शेजारी ठेवा आणि चूक दिसू लागते।
प्रोफाइल जारी करणे आणि मागे घेणे
जारी करणे सोपा अर्धा भाग आहे: स्वीकारणाऱ्या बाजूला क्लायंट की तयार करा, प्रोफाइल नेमक्या एका मालकाला द्या, गुंडाळणारी सामग्री मर्यादित ठेवा, आणि प्रत्येक स्वीकारणाऱ्या सर्व्हरवर तोच पडताळणी कार्यक्रम चालवा। स्वस्त प्रवेश संपूर्ण गटाचा गुणधर्म आहे, सर्वात नव्या होस्टचा नाही। जुन्या किंवा सैल स्क्रिप्ट असलेला दुसरा सर्व्हर शांतपणे तैनातीतील सर्वात कमकुवत मार्ग बनतो।
मागे घेण्यासाठी तीन पायऱ्या जाणूनबुजून क्रमाने लागतात। नवीन हँडशेक अपयशी व्हावेत म्हणून पडताळणी हुकमध्ये क्लायंटला नाकारा, PKI वापरली जात असेल तर त्याचे प्रमाणपत्र रद्द करा, आणि खाते बंद करा जेणेकरून पुढील अधिकृतीकडे अधिकृत करण्यासाठी काहीही उरणार नाही। मग जुन्या स्वीकृतीने परवानगी दिलेली सत्रे संपवा, कारण ती तीनपैकी काहीही लक्षात घेणार नाहीत। तोडू शकता अशा क्लायंटवर हा क्रम सरावा।
प्रोफाइलमधील मेटाडेटा त्या धोरणासाठी इनपुट आहे, प्रवेश नियंत्रण आधीच आहे याचा पुरावा नाही। OpenVPN 2.6 चा रचना दस्तऐवज ऑब्जेक्ट आणि त्यांनी ओढलेली सीमा वर्णन करतो, तर त्यांची अंमलबजावणी ऑपरेटरकडेच राहते।