टीएलएस के वैकल्पिक संस्करणों की निरंतर पीढ़ी पुराने प्रोटोकॉल के ossification की समस्या को हल करेगी

टीएलएस 1.3 प्रोटोकॉल के नए संस्करण पर काम लगभग पूरा हो गया है। मार्च 2018 में चार साल की चर्चा के बाद, IETF ने प्रस्तावित मानक के रूप में मसौदे के 28 वें संस्करण को मंजूरी दे दी, इसलिए अंतिम विनिर्देशों को अपनाने से पहले यह अंतिम होना चाहिए।

टीएलएस 1.3 इस बिंदु पर कई चरणों को जोड़कर लगभग आधे से एक सुरक्षित कनेक्शन स्थापित करने की प्रक्रिया को गति देता है। इसके अलावा, यह पंचांग कुंजियों (ईसी) डीएच के माध्यम से पूर्ण प्रत्यक्ष गोपनीयता की व्यवस्था लागू करता है। यह मोड दीर्घकालिक चाबियों के समझौते के मामले में भी सत्र कुंजी की सुरक्षा की गारंटी देता है।

कई अन्य सुधारों को लागू किया गया है, जिसमें ChaCha20 स्ट्रीम सिफर, डिजिटल सिग्नेचर एल्गोरिदम Ed25519 और Ed448, प्रमुख एक्सचेंज प्रोटोकॉल x25519 और x448, इत्यादि अप्रचलित हैश फ़ंक्शन MD5 और SHA-224 के लिए हटाए गए समर्थन, कमजोर और शायद ही कभी इस्तेमाल किए जाने वाले अण्डाकार घटता के लिए समर्थन शामिल हैं।

लेकिन सबसे दिलचस्प है नया विचार जो IETF पर चर्चा कर रहा है। Google विशेषज्ञ समय-समय पर अनियमित परिवर्तनों के साथ TLS प्रोटोकॉल का एक नया संस्करण उत्पन्न करने का सुझाव देते हैं। यह विचार यह है कि लगातार अपडेट खतरनाक ओस्सिफिकेशन के लिए एक एंटीडोट होगा।

यह समस्या क्या है?

तथाकथित "ऑसीफिकेशन" एक ऐसी स्थिति है जब प्रोटोकॉल डेवलपर्स को अचानक पता चलता है कि पुराने संस्करण के व्यापक वितरण के कारण किसी भी सुधार को पेश करना मुश्किल है, जो किसी कारण से उपयोगकर्ताओं को सूट करता है। वास्तव में, पुराना संस्करण अब आधुनिक सुरक्षा आवश्यकताओं और नए विनिर्देशों को पूरा नहीं करता है, लेकिन इसे वास्तविक रूप से लागू नहीं किया जा सकता है।

यह माना जाता है कि तथाकथित मध्यवर्ती नोड्स, अर्थात् "सुरक्षा" के क्षेत्र में समाधान के विक्रेता, विशेष रूप से टीएलएस 1.3 के कार्यान्वयन के साथ मुख्य "ब्रेक" बन गए। वे अपने ग्राहकों को टीएलएस के साथ हाथ मिलाते समय प्रमाणपत्र स्कैनिंग के साथ विशिष्ट फ़ायरवॉल नियमों को निर्धारित करने की सलाह देते हैं। मानक के नए संस्करण में, SSL प्रमाणपत्र एन्क्रिप्ट किए गए हैं, जिससे बिचौलिये अब उन्हें स्कैन नहीं कर पाएंगे।

निरंतर अद्यतन कैसे प्रोटोकॉल के ossification की समस्या को हल करेगा?

प्रत्येक छह सप्ताह में लगातार अपडेट करना क्रोम ब्राउज़र का एक परिचित पैटर्न है। इस स्थिति में, "कलाकार" को विनिर्देशों के अनुपालन के लिए मजबूर किया जाता है , क्योंकि असंगत कार्यान्वयन उपयोगकर्ताओं के एक बड़े अनुपात के लिए काम नहीं करेगा।

IETF मेलिंग सूची पर, यह विचार क्रोमियम परियोजना के डेविड बेंजामिन द्वारा सुझाया गया था। वह लिखते हैं कि टीएलएस 1.3 एक एक्स्टेंसिबल प्रोटोकॉल है जो टीएलएस 1.2 के साथ पिछड़ा संगत है। यह धीरे-धीरे लुढ़का जा सकता है, टीएलएस 1.2 के वर्तमान कार्यान्वयन को अद्यतन करता है। और यहां समस्याएं हैं। कई असंगत सर्वर टीएलएस 1.3 क्लाइंटहेलो चरण में संचार स्थापित करने में सक्षम नहीं होंगे, इसलिए आपको समर्थित प्रोटोकॉल संस्करण का उपयोग करके संचार स्थापित करने के लिए वापस रोल करना होगा।

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

लेकिन अभ्यास से पता चलता है कि विनिर्देशों में आवश्यक व्यवहार का वर्णन करना पर्याप्त नहीं है। क्लाइंटहेलो प्रोसेसिंग के प्रमुख नियम को पूरा करने के लिए इंटरमीडिएट नोड्स को कैसे बाध्य किया जाए - गैर-मान्यता प्राप्त मापदंडों को अनदेखा करने के लिए? इसके लिए GREASE मेथड प्रस्तावित है।

महान: ossification के खिलाफ मारक

GREASE (जनरेट रैंडम एक्सटेंशन्स और सस्टेनेन्स एक्स्टेंसिबिलिटी) TLS में रैंडम एक्सटेंशन जेनरेट करने और प्रोटोकॉल के नए वर्जन को लगातार जारी रखने का एक तरीका है। डेविड बेंजामिन ने छह सप्ताह के मानक चक्र को स्थापित करने का प्रस्ताव रखा, जो क्रोम के नए संस्करणों के रिलीज के साथ मेल खाएगा।

बड़ी संख्या में ऐसे "कचरा" की रिहाई सर्वरों को अपरिचित मापदंडों को अनदेखा करने के लिए क्लाइंटहेलो प्रसंस्करण के प्रमुख नियम का पालन करने के लिए मजबूर करेगी। यह मध्यवर्ती नोड्स में भी फैल जाएगा। ताकि वे क्लाइंट और सर्वर के बीच संचार में हस्तक्षेप न करें, उनके लिए मुख्य नियम यह है: यदि आपने एक क्लाइंटहेलो अनुरोध नहीं भेजा है, तो आपके पास प्रतिक्रिया को संसाधित करने का अधिकार नहीं है। इसी तरह, पारिस्थितिकी तंत्र को बड़ी संख्या में ऐसी प्रतिक्रियाओं से भरा होना चाहिए।

बेंजामिन कहते हैं, "संक्षेप में, हम नियमित रूप से टीएलएस के नए संस्करणों (और शायद एक्सटेंशन जैसे अन्य संवेदनशील मापदंडों) पर मुहर लगाने की योजना बनाते हैं।" - क्रोम रिलीज़ शेड्यूल के अनुसार, लगभग हर छह हफ्ते। फिर क्रोम, Google के सर्वर और अन्य सभी जो भाग लेना चाहते हैं, वे TLS 1.3 के दो (या अधिक) संस्करणों का समर्थन करेंगे: मानक स्थिर 0x0304 और अस्थायी वैकल्पिक संस्करण। हर छह सप्ताह में, हम बेतरतीब ढंग से एक नया कोड बिंदु चुनते हैं। अन्य सभी मामलों में, ये संस्करण 1.3 के समान हैं, जिनमें चाबियों को अलग करने और क्रमिक परिवर्तनों की अनुमति देने के लिए मामूली विवरण के संभावित अपवाद हैं। लक्ष्य टीएलएस के भविष्य के संस्करणों के लिए उन्हें नक़ल (नकारात्मक एक मसौदा) का मार्ग प्रशस्त करना है। ”

इस तरह की योजना में कुछ जोखिम होते हैं, जिसमें कोड बिंदुओं की टक्कर भी शामिल है। इसके अलावा, सावधानियां विकसित की जानी चाहिए, क्योंकि कार्य टीएलएस की व्यापकता को बनाए रखना और बनाए रखना है, और प्रोटोकॉल के विकास में हस्तक्षेप नहीं करना है। एहतियाती उपायों से:

• सभी कोड बिंदुओं का विस्तृत दस्तावेज़ीकरण (जब डेढ़ महीने में एक बिंदु पर काम करना होता है, तो वे 7000 से अधिक वर्षों के लिए पर्याप्त होंगे)।
• सक्रिय टकराव से बचाव: उन संख्याओं को अस्वीकार करना जो IETF चुन सकती हैं।
• बोरिंगएसएसएल डिफ़ॉल्ट रूप से इस विकल्प को सक्षम नहीं करेगा। इसे केवल वहीं सक्षम किया जाएगा जहां इसे निष्क्रिय किया जा सकता है: सर्वर पर और ब्राउज़र में। वास्तव में, सबसे अधिक संभावना है, समय पर प्रत्येक क्षण में, केवल अंतिम कुछ कोड बिंदुओं का उपयोग किया जाएगा। क्योंकि वे तेजी से बदल रहे हैं, पारिस्थितिकी तंत्र को ऐसे किसी भी अस्थायी विस्तार से नहीं जोड़ा जाना चाहिए, और कार्यान्वयन एक-दूसरे के साथ संगत रहेंगे।
• यदि किसी कारण से विधि काम नहीं करती है, तो प्रयोग को किसी भी समय रोका जा सकता है।

यह विचार दिलचस्प है, और अगर Google इस तरह से कार्य करना शुरू कर देता है, तो यह "सुरक्षा" और अन्य विशिष्ट कॉर्पोरेट सिस्टम के क्षेत्र में समाधान के विक्रेताओं के कारण पारिस्थितिकी तंत्र को खतरनाक "ऑसिफिकेशन" से बचा सकता है। Cloudflare के एक प्रतिनिधि ने इस प्रस्ताव का समर्थन किया। किसी भी मामले में, उन्होंने कहा, टीएलएस 1.3 को लागू करने की कोशिश करते समय हमें जो समस्या आई थी, उससे बचने के लिए कम से कम कुछ करने की आवश्यकता है। IETF वर्किंग ग्रुप के एक अन्य सदस्य ने इसे "शानदार विचार" कहा और सुझाव दिया कि Google एक विकी पेज बनाता है जो उन कोड बिंदुओं का वर्णन करता है जो इसका उपयोग करता है या भविष्य में उपयोग करने की योजना बनाता है।

---