OpenVPN EC विरुद्ध ED: ही नावे ताकदीची शिडी का नाहीत
EC, ED, ECDHE आणि auth वेगवेगळ्या प्रश्नांची उत्तरे देतात. काहीही तुलना किंवा बदल करण्यापूर्वी OpenVPN प्रोफाइल प्रत्येक नावाच्या कामानुसार लावा.
एका प्रोफाइलमध्ये ec, ed, ecdh, ecdsa, auth आणि TLS सिफरची यादी शेजारी शेजारी ठेवा, आणि फाइल सहा स्थानांच्या ताकद-डायलसारखी दिसू लागते। पण तसे नाही। प्रत्येक नाव वेगळ्या प्रश्नाचे उत्तर देते, आणि त्यांपैकी एकात वेगळे असणारे दोन प्रोफाइल एकमेकांपेक्षा जास्त मजबूत किंवा कमकुवत असतीलच असे नाही। नावे त्यांच्या कामानुसार लावण्यास सुमारे पाच मिनिटे लागतात आणि चालू असलेल्या कॉन्फिगरेशनमध्ये लोक करतात त्या बहुतेक वाईट बदलांना ते प्रतिबंध करते।
खालील मांडणी गोंधळापासूनच सुरू होते आणि नंतर बाहेरच्या बाजूला, प्रोफाइलच्या त्या भागांकडे जाते जे तुमचा रहदारी खरोखर कशामुळे सुरक्षित राहतो हे ठरवतात। प्रत्येक भाग एक एक चुकीचे वाचन घेतो आणि नाव खरोखर कशाशी जोडलेले आहे ते दाखवतो।
दोन अक्षरे, दोन वेगळे प्रश्न
सर्वाधिक वाद घालणारी जोडी EC आणि ED आहे, आणि वाद सहसा असे गृहीत धरतो की ती एकाच प्रश्नाची स्पर्धक उत्तरे आहेत। ती एकाच अक्षावरही नाहीत। EC गणिताचे एक कुटुंब वर्णन करते: लंबवर्तुळीय वक्र गुप्तलेखन, जिथे सुरक्षा मोठ्या मर्यादित क्षेत्रातून नाही तर वक्रावरील विविक्त लघुगणकाच्या कठिणतेतून येते।
ED त्या कुटुंबातील वक्राचा आकार वर्णन करते। Twisted Edwards वक्रे हे वेग आणि अनेक अंमलबजावणीच्या चुकांविरुद्ध प्रतिकार यासाठी निवडलेले निरूपण आहे, आणि Ed25519 हे लोक सहसा म्हणतात ते नाव। वक्र हे लंबवर्तुळीय वक्र गुप्तलेखनाचे स्पर्धक नाही; ते लंबवर्तुळीय वक्र लिहिण्याचा एक मार्ग आहे। ED ला "नवीन, अधिक मजबूत EC" म्हणून वाचणे हे पहिले चुकीचे वळण आहे, आणि त्यानंतरचे सर्व त्याच दिशेने चुकीचे ठरण्याचा संभव असतो।
सही करणे आणि देवाणघेवाण करणे वेगवेगळी कामे आहेत
कुटुंबाचा प्रश्न निकाली निघाल्यावर, उर्वरित नावे दोन स्तंभांत विभागली जातात जे कधीही एकमेकांना बदलत नाहीत। एक स्तंभ सही करतो, दुसरा सामायिक गुप्ततेवर सहमत होतो।
| Name in the profile | Job it does | What it is not |
|---|---|---|
ecdsa | Signature scheme using elliptic-curve keys | Not a key-exchange method |
eddsa, Ed25519 | Signature scheme for twisted Edwards curves | Not interchangeable with ECDSA |
ecdh, X25519 | Ephemeral key agreement | Not a signature and not a cipher |
auth | HMAC digest for packet authentication | Not the data cipher |
EdDSA आणि ECDSA दोन्ही सही करतात, पण त्या वेगवेगळ्या किल्ली स्वरूपांच्या वेगळ्या योजना आहेत, म्हणून एकासाठी जारी केलेले प्रमाणपत्र दुसऱ्यासाठी वापरता येत नाही। EdDSA थोड्या वक्रांच्या संचासाठी परिभाषित आहे; P-256 त्यांपैकी एक नाही, म्हणून P-256 प्रमाणपत्र ECDSA ने तपासले जाते आणि कधीही Ed25519 ने नाही।
देवाणघेवाण स्तंभात EdDH नावाचे समतुल्य नाही। Curve25519 किल्लीवरील तात्पुरता करार X25519 आहे, आणि तो विशिष्ट वक्रासह ECDH आहे, P-256 प्रमाणेच। Ed25519 काटेकोरपणे सही योजना दर्शवते, तरी दोन्ही वक्रे संबंधित असल्याने हे नाव देवाणघेवाणीसाठीही सैलपणे वापरले जाते: सहीसाठी वापरले जाणारे Edwards स्वरूप आणि X25519 साठी वापरले जाणारे Montgomery स्वरूप एकाच मूलभूत गटाचे वर्णन करतात।
EC प्रोफाइलमध्ये dh फाइल का नाही
dh फाइलमध्ये मर्यादित क्षेत्र Diffie-Hellman साठी आधीच तयार केलेले मापदंड असतात, आणि ते मापदंड असतात कारण मोठी मूळ संख्या आणि जनरेटर कुठूनतरी यायला हवे। लंबवर्तुळीय वक्राच्या देवाणघेवाणीला ते लागत नाहीत: नामांकित वक्र हा मापदंडांचा संच आहे, आणि दोन्ही बाजूंना तो आधीच माहीत आहे। EC प्रोफाइल निर्देश वगळू शकण्याचे हेच संपूर्ण कारण आहे।
दुसऱ्या दृष्टीने आधुनिक दिसणाऱ्या प्रोफाइलमध्ये दोन परिस्थिती अजूनही dh ओळ तयार करतात। पहिली म्हणजे मर्यादित क्षेत्रातील गटांवर खरोखर वाटाघाटी करणारा दुसरा श्रोता किंवा जुना सहकारी। दुसरी म्हणजे RSA युगातील टेम्पलेटमधून कॉपी केलेला आणि कधीही काढला न गेलेला उरलेला मजकूर। देवाणघेवाणीसाठी वक्र नामांकित करूनही 2048-बिट dh फाइल लोड करणारे प्रोफाइल त्यामुळे अधिक सुरक्षित होत नाही; ते न वापरलेली वस्तू बाळगत असते।
TLS 1.3 ने नावातून किल्ली देवाणघेवाण काढून टाकली
TLS_AES_256_GCM_SHA384 ची TLS-ECDHE-ECDSA-WITH-AES-256-GCM-SHA384 शी तुलना करा आणि लहान नाव घट असल्यासारखे वाटते। हे नाव बदलणे आहे, आणि कारण रचनात्मक आहे: TLS 1.3 ने स्थिर RSA आणि मर्यादित क्षेत्रातील Diffie-Hellman किल्ली देवाणघेवाण काढून टाकली, त्यामुळे तात्पुरती लंबवर्तुळीय वक्र देवाणघेवाण हा उरलेला एकमेव बिगर-PSK पर्याय आहे। प्रत्येक सूटमध्ये त्याचे नाव देणे हीच गोष्ट डझनभर वेळा पुन्हा सांगण्यासारखे ठरेल।
प्रमाणपत्राचा प्रकार नावातून संबंधित कारणाने गायब झाला। 1.3 मध्ये प्रमाणपत्र हस्तांदोलनाच्या सहीची प्रमाणितता ठरवते, किल्ली कराराची नाही, म्हणून ते आता सूट निवडत नाही। म्हणूनच कॉन्फिगरेशनमध्ये 1.3 साठी वेगळी सिफर यादी आहे: सूटची नावे बदलली गेली आणि पुनर्रचना झाली, कमकुवत केली गेली नाहीत।
एक परिणाम स्पष्टपणे सांगण्यासारखा आहे। ECDHE हा किल्ली देवाणघेवाणीचा अल्गोरिदम आहे आणि कधीही सिफर नाही। "लंबवर्तुळीय" असे वर्णन केलेली सूट दोन बाजू सामायिक किल्लीपर्यंत कशा पोहोचल्या याबद्दल काही सांगते, आणि त्यानंतर पेलोड काय गुप्त करते याबद्दल काहीही सांगत नाही।
auth पॅकेट प्रमाणित करते, पेलोड नाही
auth निर्देश तो HMAC डायजेस्ट निवडतो जो पॅकेट प्रमाणित करतो, आणि त्याचे ऐतिहासिक मूलभूत मूल्य SHA1 आहे। बिगर-AEAD डेटा सिफरसह OpenVPN गुप्त मजकुरावर डायजेस्ट काढून तो जोडते, ही एन्क्रिप्ट-नंतर-MAC मांडणीच पॅडिंगशी छेडछाड अव्यवहार्य करते।
इथला गैरसमज असा आहे की auth SHA512 पर्यंत वाढवल्याने बोगदा मजबूत होतो। त्याने गुप्तलेखनाची ताकद वाढत नाही, आणि ठरलेला डेटा सिफर AES-256-GCM सारखा AEAD मोड असल्यास डायजेस्ट डेटा पॅकेटवर अजिबात लागू होत नाही। GCM टॅग आधीच त्यांना प्रमाणित करतो, आणि auth मूल्य नियंत्रण वाहिनीच्या HMAC साठी आणि अजून वापरल्या जाणाऱ्या कोणत्याही बिगर-AEAD सिफरसाठी राहते।
म्हणून निर्देश महत्त्वाचा आहे, पण फाइलमधील त्याच्या जागेचा जो इशारा मिळतो त्यापेक्षा अरुंद जागी तो महत्त्वाचा आहे। खरंच कोणता सिफर ठरला हे तपासल्यास तो अजिबात लागू होतो का हे कळते।
प्रोफाइल स्तंभानुसार वाचा, क्रमानुसार नाही
तीन प्रश्न थर स्वच्छ वेगळे करतात, आणि प्रत्येकाचे उत्तर ठरलेल्या सत्राचा वेगळा भाग देतो। कोणता सिफर पेलोडचे रक्षण करतो? कोणता टॅग किंवा डायजेस्ट प्रत्येक पॅकेटची हमी देतो, आणि वापरल्या जाणाऱ्या सिफरला तो अजिबात आवश्यक आहे का? कोणाच्या प्रमाणपत्राने हस्तांदोलन बंद केले, आणि नियंत्रण वाहिनी याशिवाय tls-auth किंवा tls-crypt ने संरक्षित आहे का?
EC किंवा ED लेबलमध्ये काहीही त्या तीनपैकी एकही ठरवत नाही, आणि सूटचे नाव एकटेही त्यांपैकी काहीही ठरवत नाही। ठरलेला निकाल हाच एकमेव पुरावा आहे, म्हणून शब्दसंग्रहातून ताकद ओढण्याऐवजी तो वाचा:
openssl x509 -in client.crt -noout -text | grep -E 'Signature Algorithm|Public Key Algorithm'
grep -i 'control channel' /var/log/openvpn.logपहिला आदेश तुमचे प्रमाणपत्र खरोखर कोणती सही योजना वापरते हे सांगतो, आणि तुम्ही ECDSA चालवता की Ed25519 हे जाणण्याचा तोच एकमेव विश्वासार्ह मार्ग आहे। दुसरा क्लायंटने सत्रासाठी नोंदवलेली नियंत्रण वाहिनीची ओळ दाखवतो, त्यात TLS आवृत्ती आणि तो ज्या सूटवर थांबला ती सूट समाविष्ट आहे। प्रोफाइलमधील बदल या दोन आउटपुटपैकी एकानेही न्याय्य ठरत नसेल, तर तो कदाचित गुणधर्माचा नाही तर नावाचा बदल आहे।