SSL / TLS को आधुनिक ऑपरेटिंग सिस्टम में क्यों नहीं बनाया गया है?

Question

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

लेकिन जब एसएसएल या टीएलएस की बात आती है, तो किसी को तीसरे पक्ष के पुस्तकालय जैसे कि ओपनएसएसएल या मोज़िला एनएसएस की ओर मुड़ना पड़ता है।

एसएसएल एक अपेक्षाकृत पुराना प्रोटोकॉल है, और यह मूल रूप से टीसीपी / आईपी के रूप में सर्वव्यापी के रूप में एक उद्योग मानक है, इसलिए इसे अपने ऑपरेटिंग सिस्टम में क्यों नहीं बनाया गया है?

Comments

-अंतर्निहित ’और with बंडल के साथ’ के बीच व्यावहारिक अंतर क्या है? जहाँ तक मुझे पता है, सभी OSes किसी न किसी तरह SSL / TLS के बंडल कार्यान्वयन के साथ आते हैं।

— zneak

अंतर यह है कि टीसीपी और डीएनएस को कर्नेल कोड में लागू किया जाता है। लेकिन एसएसएल केवल तीसरे पक्ष के पुस्तकालयों के माध्यम से उपलब्ध है। हालांकि यह आमतौर पर एसएसएल समर्थन को स्थापित करने के लिए एक तुच्छ मामला है, और कई ओएस यहां तक ​​कि इसके साथ आउट-ऑफ-द-बॉक्स भी हैं, अभी भी व्यावहारिक नुकसान हैं: उदाहरण के लिए, यदि मैं एक पुस्तकालय लिखता हूं जो एक विशेष एसएसएल कार्यान्वयन का उपयोग करता है, (जैसे OpenSSL, NSS, GnuTLS, इत्यादि) मेरे सॉफ्टवेयर में अब एक निर्भरता है जो उपयोगकर्ताओं को निपटानी होगी। यह एक गैर-मुद्दा होगा यदि एसएसएल ओएस में बनाया गया था। मेरा मतलब है, यह मुझे पसंद नहीं है अगर मेरे किसी भी उपयोगकर्ता को टीसीपी के लिए समर्थन स्थापित करने की आवश्यकता होगी।

— Channel72

मुझे नहीं लगता कि अंतर्निहित SSL आपके द्वारा बताई गई समस्या को हल करेगा। अब, विशिष्ट पुस्तकालयों के आधार पर, आप विशिष्ट ऑपरेटिंग सिस्टम पर निर्भर होंगे।

— zneak

जेपीईजी पुस्तकालय क्यों नहीं हैं? एक ही प्रभावी प्रश्न। आप स्टैक के गलत स्थान को देख रहे हैं। एसएसएल समर्थन प्रदान करने के लिए सभी आधुनिक ओएस में कुछ बंडल है। (MSFT के पास .NET SDK है,

— लिनेक्स

क्या आप वास्तव में इसे कर्नेल में चाहते हैं? यह मुझे पहले से ही भारी भीड़ लगती है।

— मैथ्यू एम।

Answer 1

मुझे लगता है कि यह मुख्य रूप से "ओएस" के रूप में आपके द्वारा देखे जाने पर निर्भर करता है। यदि यह कर्नेल है, तो मेरा उत्तर होगा: यह क्यों होना चाहिए? मैं गलत हो सकता हूं, लेकिन क्या DNS लिनक्स सिस्टम पर ग्लिब का हिस्सा नहीं है, जो एक थ्रिड-पार्टी लाइब्रेरी है?

यदि यह कर्नेल या उपयोगकर्ता स्थान के बारे में नहीं है, तो लगभग हर OS / प्लेटफ़ॉर्म में SSL / TLS स्टैक होता है, कुछ में एक से अधिक हो सकते हैं।

इसे एक लाभ के रूप में भी देखा जा सकता है। यदि कोई ओपनएसएसएल नहीं था, तो आपको विंडोज, मैक और लिनक्स (और ...) एपीआई के अनुकूल होना होगा। टीएलएस ओएस का हिस्सा नहीं होने पर क्रॉस प्लेटफॉर्म टीएलएस एप्लिकेशन लिखने की अनुमति देता है। बस एक टीएलएस पुस्तकालय चुनें, जो आपके लक्ष्य प्लेटफार्मों का समर्थन करता है।

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

अफसोस की बात है कि सुरक्षा कभी मुफ्त में नहीं मिलती। यह प्रोग्रामर के लिए प्रयास है और उपयोगकर्ताओं के लिए असुविधा है।

Comments

अधिकांश सुरक्षा प्लंबिंग बिना किसी उपयोगकर्ता सहभागिता के हो सकती है। असुविधा केवल तब होती है जब लोग उन प्रमाणपत्रों का उपयोग करते हैं जिन पर भरोसा नहीं किया जा सकता है।

— zneak

यह सच है। लेकिन वहाँ बहुत सारे स्व-हस्ताक्षरित समारोह हैं। IMO, केंद्रीकृत अधिकारियों के पूरे मॉडल को मापता नहीं है। कैसे तय करें कि कौन सी जड़ पर भरोसा करें? कोई भी उपयोगकर्ता इस पर फैसला नहीं करेगा। वे सभी आशा करते हैं कि प्रोग्रामर ने समझदारी से चयन किया।

— पज़तुलियो

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

— zneak

Answer 2

कानूनी समस्या है। कुछ देशों ने क्रिप्टोग्राफी को एक ही समूह में हथियार के रूप में रखा। क्रिप्टोग्राफिक कोड को कर्नेल में डालना फिर कर्नेल कोड के किसी भी निर्यात को अधिक कठिन बना देता है।

Answer 3

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

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

Answer 4

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

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

Answer 5

मैं एक विंडोज़ डेवलपर हूं, इसलिए मैं अन्य ओएस के लिए बात नहीं कर सकता, लेकिन विंडोज पर उन्होंने एसएसएल को बहुत लंबे समय के लिए बनाया था। वे इसे SChannel कहते हैं और जब इसका समर्थन किया जाता है, तो यह अधिक गूढ़ एपीआई में से एक है जिसे कभी भी पता लगाना होगा।

Answer 6

एसएसएल एक निचले स्तर के प्रोटोकॉल के शीर्ष पर एक परत है। उदाहरण के लिए SSL टीसीपी के शीर्ष पर चलता है (जो कि आईपी के शीर्ष पर है)।

OS कहाँ रुकता है?

यह तर्क करना बहुत आसान है कि ओएस बुनियादी सेवाएं प्रदान करता है जैसे कि एक बिंदु तक नेटवर्किंग जहां ओएस का एक ग्राहक "सामान करता है"। और वो सामान जो चाहे वो हो सकता है।

इसकी बहुत संभावना नहीं है कि कर्नेल में एसएसएल बड़े पैमाने पर प्रदर्शन का नेतृत्व करने जा रहा है, इसलिए परेशान क्यों हो?

आधुनिक ओएस कर्नेल कोड की लाखों पंक्तियों तक चलते हैं, और अधिक जोड़ने से जटिलता और अधिक डीबगिंग समय जुड़ जाता है। ओएस से उच्च परत प्रोटोकॉल सामान जैसी चीजों को छोड़ना ओएस के विकास को आसान बनाता है और अंत में फ़ंक्शन या अंतिम-अनुप्रयोग के प्रदर्शन पर बहुत कम फर्क पड़ता है। (यह अंतिम आवेदन के लिए डेवलपर्स को थोड़ा अधिक दर्दनाक बना सकता है।)

Answer 7

क्रिप्टो और एसएसएल के लिए कुछ कर्नेल समर्थन है। यह समझ में आता है क्योंकि कर्नेल हार्डवेयर के साथ अधिक कुशलता से इंटरफ़ेस कर सकता है और यह किसी भी एप्लिकेशन से क्रेडेंशियल्स की रक्षा करने के लिए भी आश्वस्त है। अच्छे उदाहरण हैं kssl, सोलारिस में कर्नेल-लेवल रिवर्स-एसएसएल प्रॉक्सी या कर्नेल में विभिन्न क्रिप्टो लाइब्रेरी (वीपीएन के लिए उदाहरण के लिए प्रयुक्त)। एक विशिष्ट हार्डवेयर त्वरित क्रिप्टो इंजन में एक कर्नेल मॉड्यूल भी होता है (और PKCS # 11 या OS विशिष्ट क्रिप्टो इंटरफेस पर पहुंच योग्य है)।

कुछ कारण जो आप इसे अधिक बार नहीं देखते हैं, यह है कि कुछ एप्लिकेशन प्रोटोकॉल ठीक से स्तरित नहीं होते हैं (STARTLS सोचते हैं) या हैंडशेक (क्लाइंट सर्टिफिकेट और CRL चेकिंग के बारे में सोचें) के निर्णय की आवश्यकता होती है या बस एक नियमित विकास में होते हैं।