मुझे पता है कि टीएलएस अनिवार्य रूप से एसएसएल का एक नया संस्करण है, और यह आमतौर पर असुरक्षित से सुरक्षित करने के लिए एक कनेक्शन को बदलने का समर्थन करता है (आमतौर पर एक STARTTLS कमांड के माध्यम से)।
मुझे समझ में नहीं आ रहा है कि टीएलएस आईटी प्रोफेशनल के लिए महत्वपूर्ण क्यों है, और मुझे जो विकल्प दिया गया है, उसे मैं क्यों चुनूंगा। क्या टीएलएस वास्तव में सिर्फ एक नया संस्करण है, और यदि यह एक संगत प्रोटोकॉल है?
आईटी प्रोफेशनल के रूप में: मैं कब प्रयोग करूं? मैं कब उपयोग नहीं करूं?
जवाबों:
संक्षिप्त जवाब:
SSL TLS का अग्रदूत है। एसएसएल एक मालिकाना प्रोटोकॉल था जिसे नेटस्केप कम्युनिकेशंस द्वारा विकसित किया गया था, जिसे बाद में आईईटीएफ के भीतर मानकीकृत किया गया और इसका नाम टीएलएस रखा गया। संक्षेप में, संस्करण इस क्रम में चलते हैं: SSLv2, SSLv3, TLSv1.0, TLSv1.1 और TLSv1.2।
एक अपेक्षाकृत व्यापक प्रसार धारणा के विपरीत, यह एसएसएल के साथ एक अलग पोर्ट पर सेवा चलाने और टीएलएस के साथ सादे-पाठ संस्करण के समान पोर्ट पर सक्षम होने के बारे में बिल्कुल भी नहीं है। एसएसएल और टीएलएस दोनों का उपयोग दो दृष्टिकोणों के लिए किया जा सकता है। यह कनेक्शन पर एसएसएल / टीएलएस के बीच अंतर के बारे में है (कभी-कभी "अंतर्निहित एसएसएल / टीएलएस" के रूप में संदर्भित) और एसएसएल / टीएलएस एक प्रोटोकॉल स्तर पर जारी किए जाने के बाद, आमतौर पर STARTTLS(कभी-कभी "स्पष्ट एसएसएल / टीएलएस" के रूप में संदर्भित किया जाता है) । इसमें मुख्य शब्द STARTTLS"START" है, TLS नहीं। यह एप्लिकेशन प्रोटोकॉल स्तर पर एक संदेश है, यह इंगित करने के लिए कि एसएसएल / टीएलएस पर स्विच करने की आवश्यकता है, अगर इसे किसी भी एप्लिकेशन प्रोटोकॉल एक्सचेंज से पहले शुरू नहीं किया गया है।
या तो मोड का उपयोग करना समतुल्य होना चाहिए, बशर्ते ग्राहक SSL / TLS से एक या दूसरे तरीके की अपेक्षा करने के लिए कॉन्फ़िगर किया गया हो, ताकि सादे-पाठ कनेक्शन से डाउनग्रेड न किया जा सके।
दीर्घ उत्तर:
जहाँ तक मेरी जानकारी है, SSLv1 ने कभी भी प्रयोगशाला नहीं छोड़ी। SSLv2 और SSLv3 नेटस्केप द्वारा विकसित प्रोटोकॉल थे। SSLv2 को कुछ समय के लिए असुरक्षित माना गया है, क्योंकि यह डाउनग्रेड हमलों का खतरा है। SSLv3 आंतरिक (3,0)रूप से अपने संस्करण संख्या ( ClientHelloसंदेश के भीतर ) के रूप में उपयोग करता है ।
टीएलएस IETF के भीतर एक अधिक खुले प्रोटोकॉल के रूप में मानकीकरण का परिणाम है। (मुझे लगता है कि मैंने कहीं पढ़ा है, शायद ई। रेसकोरला की किताब में, कि नाम इस तरह से चुना गया था कि सभी प्रतिभागी इससे समान रूप से नाखुश थे, इसलिए किसी विशेष कंपनी का पक्ष लेने के लिए नहीं: यह मानकों में काफी आम है। body।) जिन लोगों को संक्रमण कैसे हुआ, इसमें रुचि रखने वाले SSL- टॉक लिस्ट FAQ पढ़ सकते हैं ; इस दस्तावेज़ की कई प्रतियां हैं, लेकिन अधिकांश लिंक (से netscape.com) पुराने हैं।
टीएलएस बहुत समान संदेशों का उपयोग करता है (प्रोटोकॉल असंगत बनाने के लिए पर्याप्त रूप से अलग है, हालांकि यह एक सामान्य संस्करण पर बातचीत करना संभव है )। TLS 1.0 , 1.1 और 1.2 ClientHello संदेशों का उपयोग (3,1), (3,2), (3,3)संस्करण संख्या, जो स्पष्ट रूप से एसएसएल से निरंतरता से पता चलता इंगित करने के लिए।
इस उत्तर में प्रोटोकॉल अंतर के बारे में अधिक विवरण हैं ।
मैं कब उपयोग करूं? मैं कब उपयोग नहीं करूं?
यदि संभव हो तो उच्चतम संस्करण का उपयोग करें। व्यवहार में, एक सेवा प्रदाता के रूप में, इसके लिए आपके उपयोगकर्ताओं के पास इन संस्करणों का समर्थन करने वाले ग्राहकों की आवश्यकता होगी। हमेशा की तरह, यह हमेशा एक जोखिम-आकलन अभ्यास है (यदि उपयुक्त हो तो व्यावसायिक मामले में समर्थित है)। यह कहा जा रहा है, वैसे भी SSLv2 को काट दें।
इसके अलावा, ध्यान दें कि एसएसएल / टीएलएस द्वारा प्रदान की गई सुरक्षा केवल आपके द्वारा उपयोग किए जाने वाले संस्करण के बारे में नहीं है, यह उचित कॉन्फ़िगरेशन के बारे में भी है: यह निश्चित रूप से एक कमजोर (या) के साथ TLSv1.0 की तुलना में एक मजबूत सिफर सूट के साथ एसएसएलवी 3 का उपयोग करना बेहतर है। अनाम / अशक्त-एन्क्रिप्शन) सिफर सुइट। बहुत कमजोर माने जाने वाले कुछ सिफर सुइट्स, टीएलएस के नए संस्करणों द्वारा स्पष्ट रूप से मना किए गए हैं। यदि आप अधिक विवरण चाहते हैं, तो जावा 7 सनजेसीई प्रदाता (और उनके फुटनोट्स) की सारणियाँ दिलचस्पी की हो सकती हैं।
टीएलएस 1.1 का कम से कम उपयोग करना बेहतर होगा, लेकिन सभी ग्राहक अभी तक दुर्भाग्य से उनका समर्थन नहीं करते हैं (जैसे जावा 6)। 1.1 के तहत एक संस्करण का उपयोग करते समय, यह निश्चित रूप से BEAST भेद्यता को कम करने में देखने लायक है ।
मैं आमतौर पर एरिक रेस्कॉर्ला की पुस्तक - एसएसएल और टीएलएस: डिज़ाइनिंग एंड बिल्डिंग सिक्योर सिस्टम, एडिसन-वेस्ले, 2001 आईएसबीएन 0-201-61598-3 की अनुशंसा करता हूं, जो वास्तव में अधिक विवरण चाहते हैं।
एक कहावत है कि TLS आपको उसी पोर्ट का उपयोग करने की अनुमति देता है जबकि SSL नहीं कर सकता। यह सच नहीं है (और मैं इस चर्चा के लिए बंदरगाह एकीकरण छोड़ दूँगा )। दुर्भाग्य से, यह मिथक इस तथ्य से उपयोगकर्ताओं के लिए प्रचारित किया गया है कि एमएस आउटलुक जैसे कुछ एप्लिकेशन कभी-कभी अपने कॉन्फ़िगरेशन विकल्पों में एसएसएल और टीएलएस के बीच एक विकल्प प्रदान करते हैं, जब वे वास्तव में अंतर्निहित और स्पष्ट एसएसएल / टीएलएस के बीच एक विकल्प चुनते हैं। (माइक्रोसॉफ्ट में एसएसएल / टीएलएस विशेषज्ञ हैं, लेकिन ऐसा लगता है कि वे आउटलुक यूआई में शामिल नहीं थे।)
मुझे लगता है कि STARTTLSमोड के कारण यह भ्रम होता है । कुछ लोगों को लगता है कि इसे STARTTLS= टीएलएस के रूप में समझा गया है , लेकिन ऐसा नहीं है। इसमें मुख्य शब्द STARTTLS"START" है, TLS नहीं। इसे क्यों नहीं बुलाया गया STARTSSLया STARTSSLORTLSइसलिए क्योंकि इन एक्सटेंशनों को IETF के भीतर निर्दिष्ट किया गया था, जो केवल इसके विनिर्देशों में उपयोग किए जाने वाले नामों का उपयोग करते थे (यह मानते हुए कि टीएलएस नाम अंततः एकमात्र खड़ा होगा, मुझे लगता है)।
आजकल, अधिकांश HTTPS सर्वर TLS को संभाल सकते हैं, लेकिन कुछ साल पहले, अधिकांश लोग HTTPS के लिए SSLv3 का उपयोग कर रहे थे। HTTPS (सख्ती से बोलकर, HTTP पर TLS के रूप में मानकीकृत ) आमतौर पर टीसीपी कनेक्शन पर SSL / TLS कनेक्शन स्थापित करता है, और फिर SSL / TLS परत पर HTTP संदेश का आदान-प्रदान करता है। बीच में एक HTTP प्रॉक्सी का उपयोग करते समय इसका अपवाद है। इस स्थिति में, क्लाइंट स्पष्ट रूप से (आमतौर पर पोर्ट 3128 पर) HTTP प्रॉक्सी से जुड़ता है, फिर CONNECTHTTP कमांड जारी करता है और, बशर्ते प्रतिक्रिया सफल रही हो, एसएसएल / टीएलएस हैंडशेक को एक टीएच भेजकर आरंभ करता है।ClientHelloसंदेश। यह सब उसी पोर्ट पर होता है जहां तक ब्राउज़र और प्रॉक्सी के बीच संबंध है (जाहिर है कि प्रॉक्सी और लक्ष्य सर्वर के बीच नहीं है: यह एक ही मशीन भी नहीं है)। यह SSLv3 के साथ ठीक काम करता है। प्रॉक्सी के पीछे की स्थितियों में हम में से कई ने इसका उपयोग उन सर्वरों के खिलाफ किया होगा जो कम से कम टीएलएस 1.0 का समर्थन नहीं करते थे।
यह स्पष्ट रूप से विनिर्देशों से बाहर है, लेकिन व्यवहार में, यह अक्सर काम करता है। STARTTLS कमांड का उपयोग करने के बाद TLS (SSL नहीं) पर स्विच करने के बारे में कड़ाई से बोलते हुए विनिर्देशों के बारे में बात करें। व्यवहार में, एसएसएल अक्सर भी काम करता है (जैसे "HTTP ओवर टीएलएस" कल्पना भी टीएलएस के बजाय एसएसएल का उपयोग करके शामिल है)। आप इसे खुद से आजमा सकते हैं। मान लें कि आपके पास एक SMTP या IMAP सर्वर है जो STARTTLS का समर्थन करता है, थंडरबर्ड का उपयोग करें, वरीयताओं में जाएं, उन्नत विकल्प, कॉन्फ़िगरेशन संपादक और बंद करें security.enable_tls। कई सर्वर अभी भी कनेक्शन को स्वीकार करेंगे, केवल इसलिए कि उनके कार्यान्वयन SSL / TLS परत को SSL / TLS लाइब्रेरी में दर्शाते हैं, जो आम तौर पर SSL और TLS को उसी तरह से हैंडल करने में सक्षम होंगे, जब तक कि ऐसा न किया जाए। OpenLDAP FAQ के रूप में इसे कहते हैं, "जबकि तंत्र TLSv1 के साथ उपयोग के लिए डिज़ाइन किया गया है, यदि आवश्यक हो तो अधिकांश कार्यान्वयन SSLv3 (और SSLv2) में वापस आ जाएंगे। "। यदि आप निश्चित नहीं हैं, तो Wireshark जैसे उपकरण के साथ जांचें।
कई क्लाइंट प्रोटोकॉल के लिए टीएलएस 1.0 (कम से कम) का उपयोग कर सकते हैं जहां सुरक्षित संस्करण एक अलग पोर्ट पर है। जाहिर है, HTTPS के लिए TLS 1.0 (या इससे ऊपर) का समर्थन करने वाले कई ब्राउज़र और वेब सर्वर हैं। इसी तरह, SMTPS, IMAPS, POPS और LDAPS TLS का भी उपयोग कर सकते हैं। वे एसएसएल तक सीमित नहीं हैं।
मैं कब उपयोग करूं? मैं कब उपयोग नहीं करूं?
स्पष्ट और निहित SSL / TLS के बीच, यह वास्तव में मायने नहीं रखता है। क्या मायने रखता है कि आपका ग्राहक जानता है कि क्या करना है और ऐसा करने के लिए उचित रूप से कॉन्फ़िगर किया गया है। अधिक महत्वपूर्ण बात, यह SSL या TLS कनेक्शन की अपेक्षा करते हुए सादे पाठ कनेक्शन को अस्वीकार करने के लिए कॉन्फ़िगर किया जाना चाहिए, चाहे वह अंतर्निहित या स्पष्ट हो ।
स्पष्ट और अंतर्निहित SSL / TLS के बीच मुख्य अंतर कॉन्फ़िगरेशन सेटिंग्स की स्पष्टता में होगा।
उदाहरण के लिए, LDAP के लिए, यदि क्लाइंट एक Apache Httpd सर्वर है ( mod_ldap- इसका दस्तावेज़ीकरण SSL और TLS के बीच के अंतर को भी गलत बताता है, तो दुर्भाग्यवश, आप ldaps://URL का उपयोग करके अंतर्निहित SSL / TLS का उपयोग कर सकते हैं (जैसे AuthLDAPURL ldaps://127.0.0.1/dc=example,dc=com?uid?one) या स्पष्ट SSL का उपयोग करें / एक अतिरिक्त पैरामीटर (जैसे AuthLDAPURL ldap://127.0.0.1/dc=example,dc=com?uid?one TLS) का उपयोग करके टीएलएस ।
वहाँ शायद आम तौर पर एक थोड़ा कम जोखिम बोल जब यूआरएल स्कीम का सुरक्षा प्रोटोकॉल को निर्दिष्ट (है https, ldaps, ...) जब SSL / TLS सक्षम करने के लिए एक अतिरिक्त सेटिंग करने के लिए ग्राहक की उम्मीद की तुलना में, क्योंकि वे भूल सकते हैं। यह यकीनन है। एक बनाम दूसरे के कार्यान्वयन की शुद्धता में भी समस्याएं हो सकती हैं (उदाहरण के लिए, मुझे लगता है कि जावा एलडीएपी क्लाइंट होस्ट नाम सत्यापन का उपयोग करते समय ldaps://, जब यह चाहिए, नहीं करता है, जबकि यह ldap://+ StartTLS के साथ समर्थित है )।
संदेह में, और यदि संभव हो तो अधिक ग्राहकों के साथ संगत होने के लिए, यह दोनों सेवाओं की पेशकश करने में कोई नुकसान नहीं करता है जब सर्वर इसका समर्थन करता है (आपका सर्वर बस एक ही समय में दो बंदरगाहों पर सुन रहा होगा)। प्रोटोकॉल के लिए कई सर्वर कार्यान्वयन जो दोनों मोड के साथ उपयोग किए जा सकते हैं, दोनों का समर्थन करेंगे।
क्लाइंट की जिम्मेदारी है कि वह खुद को प्लेन-टेक्स्ट कनेक्शन में डाउनग्रेड न होने दे। सर्वर प्रशासक के रूप में, डाउनग्रेड हमलों को रोकने के लिए तकनीकी रूप से आपकी ओर से ऐसा कुछ भी नहीं किया जा सकता है (इसके अलावा क्लाइंट-सर्टिफिकेट की आवश्यकता होती है)। क्लाइंट को यह जांचना होगा कि एसएसएल / टीएलएस सक्षम है, चाहे वह कनेक्शन पर हो या एक STARTTLS-जैसे कमांड के बाद । एक ब्राउज़र में ही देना चाहिए के रूप में उसी तरह से पुनः निर्देशित किया https://करने के लिए http://एक प्रोटोकॉल है जो समर्थन के लिए, एक ग्राहक STARTTLS
यकीन है कि प्रतिक्रिया सकारात्मक और एसएसएल था बनाना चाहिए / TLS कनेक्शन किसी भी आगे बढ़ने से पहले सक्षम किया गया था। एक सक्रिय MITM हमलावर अन्यथा कनेक्शन को आसानी से डाउनग्रेड कर सकता है।
उदाहरण के लिए, थंडरबर्ड के पुराने संस्करणों में इसके लिए एक बुरा विकल्प था, जिसे "टीएलएस का उपयोग करें, यदि उपलब्ध हो" कहा जाता है , जो अनिवार्य रूप से निहित है कि यदि कोई एमआईटीएम हमलावर सर्वर संदेशों को बदलने में सक्षम था, तो यह STARTTLS, क्लाइंट के लिए समर्थन का विज्ञापन नहीं करता था चुपचाप अपने आप को एक सादे-पाठ कनेक्शन से डाउनग्रेड कर दिया जाएगा। (यह असुरक्षित विकल्प अब थंडरबर्ड में उपलब्ध नहीं है।)
TLS SSL की तुलना में एक नया प्रोटोकॉल है (लेकिन AFAIK, यह SSL v3 के साथ संगत है)। आमतौर पर, केवल एक अंतर है जिसके बारे में आपको चिंता करने की आवश्यकता है:
SSL'ed प्रोटोकॉल में आमतौर पर एक अलग पोर्ट होता है - उदाहरण के लिए, HTTP के लिए 80 और HTTPS (HTTP / SSL) के लिए 443। जब आप SSL पोर्ट से कनेक्ट करते हैं, तो पूरा सत्र एन्क्रिप्ट किया जाता है।
TLS SSL की तुलना में नया है, और इसके लिए अलग पोर्ट की आवश्यकता नहीं है - इसके बजाय क्लाइंट से बातचीत करनी होगी .. उदाहरण के लिए, आप IMAP पोर्ट 143 पर चला सकते हैं, और यदि मेल सर्वर और क्लाइंट दोनों TLS, क्लाइंट का समर्थन करते हैं एक STARTTLSकमांड भेजेगा और उसके बाद ही एन्क्रिप्शन को सक्षम करेगा। इस तरह आपको एसएसएल-कम अनुप्रयोगों के साथ संगत रहते हुए एक अलग एसएसएल-केवल पोर्ट की आवश्यकता नहीं है।
सारांश:
एसएसएल : थोड़ा पुराना। सादे और एन्क्रिप्टेड कनेक्शन के लिए अलग पोर्ट। SSL पोर्ट पर सभी ट्रैफ़िक को हमेशा एन्क्रिप्ट किया जाता है।
TLS : सादा और एन्क्रिप्टेड कनेक्शन दोनों के लिए सिंगल पोर्ट। एन्क्रिप्शन केवल क्लाइंट द्वारा एक STARTTLSआदेश जारी करने के बाद सक्षम किया जाता है ।
STARTTLSकुछ प्रोटोकॉल का उपयोग करने से एक ही कनेक्शन पर टीएलएस पर स्विच करने में सक्षम होता है, एसएसएल और टीएलएस के बीच कोई अंतर नहीं है। तकनीकी रूप से आप SSLv3 को उसी तरह से बदल सकते हैं।
TLS, SSL का एक नया संस्करण है। जब आपके पास विकल्प हो तो TLS का उपयोग करें। अधिक, हमेशा की तरह, विकिपीडिया पर ।
इस इंडियाना यूनिवर्सिटी नॉलेज बेस लेख से:
SSL का मतलब सिक्योर सॉकेट लेयर है। नेटस्केप ने मूल रूप से इस प्रोटोकॉल को निजी तौर पर सूचना प्रसारित करने, संदेश की अखंडता सुनिश्चित करने और सर्वर पहचान की गारंटी देने के लिए विकसित किया था। एसएसएल मुख्य रूप से डेटा पर सार्वजनिक / निजी कुंजी एन्क्रिप्शन का उपयोग करके काम करता है। यह आमतौर पर वेब ब्राउज़र पर उपयोग किया जाता है, लेकिन एसएसएल का उपयोग ईमेल सर्वर या किसी भी तरह के क्लाइंट-सर्वर लेनदेन के साथ भी किया जा सकता है। उदाहरण के लिए, कुछ इंस्टेंट मैसेजिंग सर्वर बातचीत की सुरक्षा के लिए एसएसएल का उपयोग करते हैं।
टीएलएस का मतलब ट्रांसपोर्ट लेयर सिक्योरिटी है। इंटरनेट इंजीनियरिंग टास्क फोर्स (IETF) ने TLS को SSL का उत्तराधिकारी बनाया। यह अक्सर ईमेल कार्यक्रमों में सेटिंग के रूप में उपयोग किया जाता है, लेकिन एसएसएल की तरह, टीएलएस की किसी भी क्लाइंट-सर्वर लेनदेन में भूमिका हो सकती है।
दो प्रोटोकॉल के बीच अंतर बहुत मामूली और बहुत ही तकनीकी हैं, लेकिन वे अलग-अलग मानक हैं। टीएलएस मजबूत एन्क्रिप्शन एल्गोरिदम का उपयोग करता है और विभिन्न बंदरगाहों पर काम करने की क्षमता रखता है। इसके अतिरिक्त, टीएलएस संस्करण 1.0 एसएसएल संस्करण 3.0 के साथ हस्तक्षेप नहीं करता है।
TLS SSL का नया संस्करण है। हालांकि कुछ जगहों पर इन शब्दों का मतलब सिर्फ प्रोटोकॉल के अलावा कुछ हो सकता है, इसलिए कृपया अपने प्रश्न को स्पष्ट करें।