सुरक्षा और प्रमाणीकरण: एसएसएल बनाम SASL

Question

मेरे समझ है कि SSL एक एन्क्रिप्शन एल्गोरिथ्म एक प्रमुख एक्सचेंज विधि (Diffier-हेलमैन की तरह) के साथ जोड़ती है (एईएस, डेस, आदि) पर दो समाप्ति बिंदुओं के बीच सुरक्षित एन्क्रिप्शन और पहचान सेवाएं प्रदान करने के लिए है एक गैर-सुरक्षित नेटवर्क (इंटरनेट की तरह)।

मेरी समझ यह है कि एसएएसएल एक एमडी 5/केर्बेरोज प्रोटोकॉल है जो काफी कुछ करता है।

तो मेरा प्रश्न: दोनों चुनने के लिए पेशेवर/विपक्ष क्या हैं और कौन से परिदृश्य या तो अधिक बेहतर होते हैं? असल में, मैं एसएसएल चुनते समय या एसएएसएल के साथ जाने के लिए कुछ दिशानिर्देशों का पालन करना चाहता हूं। अग्रिम में धन्यवाद!

Answer 1

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

इसके अतिरिक्त, आप केर्बेरोज का उल्लेख कर रहे हैं, जो वास्तव में एक प्रमाणीकरण प्रोटोकॉल है (जिसका उपयोग एसएसएल/टीएलएस या एसएएसएल या स्वतंत्र रूप से दोनों के साथ किया जा सकता है)। आपका प्रश्न यह सुझाव देता है कि मुख्य उप-समस्याओं में से एक केर्बेरोज का उपयोग करना है या नहीं, आपको पहले चुनना चाहिए।

SASL एक अविवेक परत प्लगेबल प्रमाणीकरण प्रणाली और मौजूदा अनुप्रयोग प्रोटोकॉल में डेटा सुरक्षा (जैसे LDAP, एसएमटीपी, सबवर्सन, ...) के लिए अनुमति देने के लिए है, हालांकि इन प्रोटोकॉल इस विस्तार के बारे में पता करने की आवश्यकता है अनिवार्य रूप से है (उदाहरण के SMTP auth) । चाहे यह और कैसे सुरक्षित प्रमाणीकरण और डेटा एन्क्रिप्शन प्रदान करता है, इस ढांचे के भीतर underlying mechanism पर भारी निर्भर करता है। यहां svnserve documentation का एक उदाहरण दिया गया है: "अंतर्निहित सीआरएएम-एमडी 5 तंत्र एन्क्रिप्शन का समर्थन नहीं करता है, लेकिन डीआईजीईटी-एमडी 5 करता है"। यदि आप एसएएसएल के साथ केर्बेरोस का उपयोग करना चाहते हैं, तो आपको संकेत के दूसरे स्तर की आवश्यकता होगी: GSS-API (जिसका उपयोग आमतौर पर केर्बेरोज के साथ किया जाता है, लेकिन अन्य तंत्रों के लिए भी अनुमति दे सकता है)। (ध्यान दें कि SASL के संदर्भ में GSSAPI, वैसे भी करबरोस मतलब लगता है अपने GS2 successor के विपरीत है।)

SSL/TLS के सामान्य लक्ष्य एक ग्राहक और एक सर्वर के बीच संचार (अखंडता और गोपनीयता) सुरक्षित करने के लिए है। ग्राहक को हमेशा एसएसएल/टीएलएस सर्वर की पहचान की जांच करनी चाहिए, और यह क्लाइंट की पहचान की जांच करने के लिए सर्वर के लिए तंत्र भी प्रदान करता है। यह क्या कर सकता है इस पर निर्भर करता है कि यह कैसे कॉन्फ़िगर किया गया है। एसएसएल/टीएलएस का उपयोग आमतौर पर X.50 9 प्रमाणपत्रों के साथ किया जाता है: इस प्रकार ब्राउज़र एक HTTPS सर्वर की पहचान की जांच कर सकता है। सर्वर को क्लाइंट से खुद को पहचानने के लिए प्रमाणपत्र का उपयोग करने के लिए कॉन्फ़िगर किया जा सकता है (क्लाइंट-प्रमाणपत्र प्रमाणीकरण)। हालांकि, यदि आप केर्बेरोस का उपयोग करना चाहते हैं, तो आप टीएलएस Kerberos cipher suites का उपयोग कर सकते हैं। यह बहुत कम आम है, लेकिन वे implemented in the JSSE हैं।

इसके कार्यान्वयन आमतौर पर सादे टीसीपी कनेक्शन के साथ प्राप्त होने वाले एपीआई प्रदान करते हैं: जावा में, एक बार कॉन्फ़िगर किया गया है, तो आप SSLSocket का उपयोग कर सकते हैं क्योंकि आप एक सादा Socket का उपयोग करेंगे। इसे सॉकेट के शीर्ष पर प्रोटोकॉल द्वारा विशिष्ट जागरूकता की आवश्यकता नहीं होती है, हालांकि कुछ प्रोटोकॉल में एक सादे कनेक्शन (Implicit v.s. Explicit SSL/TLS) से SSL/TLS पर स्विच करने के लिए स्पष्ट आदेश होते हैं। यह प्रमाणीकरण भी प्रदान कर सकता है। जावा में, JSSE डिफ़ॉल्ट SSL/TLS कार्यान्वयन है, जो आपको SSLSocket (या SSLEngine तक पहुंच देता है यदि आप पर्याप्त बहादुर हैं)।

आप जो इसी तरह की है "When to use Java GSS-API vs. JSSE" पढ़ने के लिए, चाहते हो सकता है के लिए "SASL बनाम SSL/TLS" (हालांकि यह थोड़ी देर के लिए अद्यतन किया गया है, के बाद से JSSE समर्थन Kerberos सिफ़र सुइट करता प्रतीत नहीं होता अब, कम से कम ओरेकल जावा 6 के बाद से)।

मैं स्वीकार करूंगा कि मैं एसएसएल/टीएलएस के मुकाबले एसएएसएल के बारे में कम जानता हूं, लेकिन एसएएसएल के माध्यम से डेटा एन्क्रिप्शन करना जैसे लगता है कि यह और अधिक काम करेगा। ऐसा लगता है कि Perfect Forward Secrecy offered by EDH cipher suites जैसे कुछ SSL/TLS सुविधाएं नहीं हैं। example that uses SASL with GSSAPI (Kerberos here) in the JGSS tutorial है: आपको डेटा को स्पष्ट रूप से लपेटने/खोलने की आवश्यकता है, जिसे SSLSocket एस का उपयोग करते समय आपको करना नहीं होगा।

मुझे लगता है कि आपकी मुख्य चिंता यह तय करना चाहिए कि आप किस प्रमाणीकरण तंत्र का उपयोग पहले स्थान पर करना चाहते हैं: केर्बेरोस, एक्स.50 9 प्रमाणपत्र, या कुछ और। इससे आपके समग्र आर्किटेक्चर पर अधिक असर पड़ेगा, और दोनों का उपयोग एसएएसएल और एसएसएल/टीएलएस के साथ किया जा सकता है (अधिक यदि आप एसएसएल/एसएलएल/टीएलएस कनेक्शन के शीर्ष पर EXTERNAL तंत्र के साथ एसएएसएल का उपयोग करते हैं)।

• केर्बेरोज बहुत केंद्रीकृत है। आपके आवेदन सर्वर से संपर्क करने में सक्षम होने के अलावा ग्राहक को प्रमाणित करने के लिए केडीसी से संपर्क करने में सक्षम होना होगा। ग्राहकों को केडीसी का उपयोग करने के लिए भी कॉन्फ़िगर करने की आवश्यकता होगी। उपयोगकर्ता के दृष्टिकोण से, वे पासवर्ड का उपयोग कर सकते हैं।
• एक्स.50 9 अधिक विकेन्द्रीकृत है। हालांकि, आपको अपने उपयोगकर्ता प्रमाण पत्र के लिए प्रमाणन प्राधिकरण (या एक वाणिज्यिक उपयोग का उपयोग) तैनात करने की आवश्यकता हो सकती है। उपयोगकर्ताओं को प्रमाणपत्र और निजी कुंजी दी जानी चाहिए, जिन्हें कुछ बहुत जटिल लग सकते हैं।

जेएएएस इसमें आता है क्योंकि प्रमाणीकरण और प्रमाणीकरण से निपटने के लिए यह सामान्य जावा ढांचा है। यह सुरक्षा प्रबंधकों की धारणा से बहुत निकटता से जुड़ा हुआ है। यह आपको Subject and Principal की धारणा देता है। यह सीधे प्रोटोकॉल या संचार से जुड़ा नहीं है, बल्कि जिस तरह से आप अपने आवेदन के भीतर प्रमाणीकरण और प्रमाणीकरण मॉडल करते हैं। (यह आपको ऐसा करने के लिए कक्षाओं का एक मानक सेट देता है।)

(मैं आमतौर पर Java reference documents के माध्यम से जाने का सुझाव देता हूं जो आपके बाद के शब्दों का उल्लेख करता है: जेजीएसएस, एसएएसएल, ..., हालांकि वे पढ़ने के लिए जरूरी नहीं है।)

Answer 2

एसएएसएल प्रोटोकॉल नहीं है बल्कि कुछ ऑथ तंत्र के लिए एक अमूर्त परत है। यदि आप अपने एसएएसएल तंत्र के रूप में डाइजेस्ट-एमडी 5 या जीएसएस-एपीआई का उपयोग करते हैं तो आप अपने डेटा यातायात को पूरी तरह से एन्क्रिप्ट करने के लिए एसएएसएल से अनुरोध कर सकते हैं। उदाहरण के लिए यह है कि मैं आपके सक्रिय निर्देशिका सर्वर से बात करने के लिए क्या करता हूं। आपको एसएसएल की आवश्यकता नहीं होगी। आपका उपयोग केस क्या है। कृपया विस्तार से बताएं!

Answer 3

एसएसएल बनाम SASL

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

एसएसएल परिवहन परत पर किया जाता है और यह सामान्यतः प्रोटोकॉल के नीचे पारदर्शी है। उदाहरण के लिए, आप एलडीएपी या HTTP पर एसएसएल का उपयोग कर सकते हैं। हालांकि, कुछ मामलों में, सुरक्षित मोड में स्विच करने के लिए मौजूदा प्रोटोकॉल में संशोधन आवश्यक है। उदाहरण के लिए, एसएसएल के उपयोग को शुरू करने के लिए पीओपी 3 और आईएमएपी को STARTTLS कमांड के लिए बढ़ाया गया है। उस कोण से, यह एसएएसएल क्या कर रहा है के समान है।

दूसरी तरफ, एसएएसएल क्षमता प्रदान करने के लिए कई प्रोटोकॉल भी बढ़ाए जाते हैं। Here प्रोटोकॉल की सूची है। फिर, पीओपी 3 और आईएमएपी उनमें से दो हैं और वे प्रमाणीकरण शुरू करने के लिए विभिन्न आदेशों का उपयोग कर रहे हैं।

तो, हमें एसएसएल का उपयोग कब करना चाहिए और हमें एसएएसएल का उपयोग कब करना चाहिए?

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

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

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

कुछ मामलों में, आप एसएसएल का उपयोग करना चाहते हैं लेकिन एसएएसएल नहीं। उदाहरण के लिए, प्रोटोकॉल को विस्तारित करना एक विकल्प नहीं है या आप प्रोटोकॉल के नीचे उपयोग किए गए प्रत्येक एकल पैकेट को एन्क्रिप्ट करना चाहते हैं।

कैसे जीएसएसएपीआई करबरोस और SASL

से संबंधित है इस wiki page के अनुसार, दोनों जीएसएसएपीआई और करबरोस SASL में mechansim समर्थित हैं। जीएसएसएपीआई एक सामान्य प्रोग्रामिंग इंटरफ़ेस है। विचार है कि आवेदन लेखक को एक ही सामान्य एपीआई का प्रमाणीकरण, एन्क्रिप्शन इत्यादि करने के लिए उपयोग करना है, भले ही प्रोटोकॉल का उपयोग किस प्रकार किया जाता है। जीएसएसएपीआई केर्बेरो लागू करता है। तो, आप केर्बेरोस प्रमाणीकरण करने के लिए जीएसएसएपीआई का उपयोग कर सकते हैं।

कैसे JAAS SASL

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