क्या STARTTLS TLS / SSL से कम सुरक्षित है?

Question

थंडरबर्ड में (और मैं कई अन्य ग्राहकों को भी मानता हूं), मेरे पास "एसएसएल / टीएलएस" और "STARTTLS" के बीच चयन करने का विकल्प है।

जहाँ तक मैं इसे समझता हूँ, "STARTTLS" का अर्थ है सरल शब्दों में "एन्क्रिप्ट यदि दोनों टीएलएस का समर्थन करते हैं, अन्यथा स्थानांतरण को एन्क्रिप्ट न करें" । और "एसएसएल / टीएलएस" का अर्थ है सरल शब्दों में "हमेशा एन्क्रिप्ट या बिल्कुल भी कनेक्ट न करें" । क्या ये सही है?

या दूसरे शब्दों में:

क्या SSL / TLS की तुलना में STARTTLS कम सुरक्षित है, क्योंकि यह मुझे सूचित किए बिना प्लेनटेक्स में वापस आ सकता है?

Answer 1

SMTP ( RFC 3207 ) के लिए STARTTLS RFC पर आधारित उत्तर है:

टीएलएस की तुलना में STARTTLS कम सुरक्षित है।

इसके बजाय अपने आप में बात कर कर के, मैं आरएफसी, खुद के लिए बात करने के लिए चार प्रासंगिक में प्रकाश डाला बिट्स के साथ की अनुमति देगा बोल्ड :

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

यदि टीएलएस वार्ता विफल हो जाती है या यदि ग्राहक को 454 प्रतिक्रिया मिलती है, तो ग्राहक को यह तय करना होगा कि आगे क्या करना है। तीन मुख्य विकल्प हैं: शेष SMTP सत्र के साथ आगे बढ़ें , [...]

जैसा कि आप देख सकते हैं, RFC स्वयं बताता है (बहुत स्पष्ट रूप से, लेकिन स्पष्ट रूप से पर्याप्त नहीं) कि एक सुरक्षित कनेक्शन स्थापित करने और एक सुरक्षित कनेक्शन विफल होने पर उपयोगकर्ताओं को सूचित करने के लिए ग्राहकों की आवश्यकता नहीं है। यह स्पष्ट रूप से क्लाइंट को सादा-पाठ कनेक्शन को चुपचाप स्थापित करने का विकल्प देता है ।

Comments

आपकी बात निश्चित रूप से मान्य है, लेकिन SMTPS (यानी SMTP + "अंतर्निहित SSL / TLS" जहां SSL / TLS पहले स्थापित है) के बारे में किसी भी RFC या आधिकारिक विनिर्देश के अभाव में, SMTP / SMTPS ग्राहक भी सादे कनेक्शन पर वापस आने का निर्णय ले सकते हैं यदि वे पोर्ट 465 पर SSL / TLS कनेक्शन शुरू करने का प्रबंधन नहीं कर सकते हैं। यह अभी भी पूरी तरह से कार्यान्वयन विकल्प है।

— ब्रूनो

टीएलएस कनेक्शन स्थापित करने के लिए बहुत सारे आरएफसी हैं। कहीं भी आरएफसी (कम से कम जो कई लोगों को खबर होगी) के अनुरूप होने के विकल्प के रूप में "प्लेन-टेक्स्ट कनेक्शन की अनुमति दें" मौजूद है। इसलिए SMTPS को STARTTLS से अधिक सुरक्षित होने के लिए एक अलग RFC की आवश्यकता नहीं है।

— ग्रेग

TLS (RFC 5246 और पूर्ववर्तियों), PKI (RFC 5280), नाम सत्यापन (RFC 6125) के बारे में RFC हैं, लेकिन SMTL और SSL / TLS के बीच SMT आधिकारिक तौर पर AFAIK के बीच की बातचीत का वर्णन करने के लिए कुछ भी नहीं, उसी तरह से नहीं जैसे आप प्राप्त करते हैं HTTPS: RFC 2818 के लिए एक युक्ति। कोई यह कह सकता है कि "यह स्पष्ट है, बस SSL / TLS कनेक्शन पहले स्थापित करें", लेकिन इसके बारे में सब कुछ स्पष्ट नहीं है (विशेष रूप से पहचान सत्यापन पहलू, RFC 6125 में हाल ही में औपचारिक रूप से)।

— ब्रूनो

Answer 2

दो विकल्पों के बीच सुरक्षा में कोई अंतर नहीं है।

• एसएसएल / टीएलएस पहले एक एसएसएल / टीएलएस कनेक्शन खोलता है, फिर एसएमटीपी लेनदेन शुरू करता है। यह उस पोर्ट पर होना चाहिए जिसमें पहले से चल रहा नॉन-एसएसएल / टीएलएस एसएमटीपी सर्वर नहीं है; प्रोटोकॉल की प्रकृति के कारण सादे पाठ और एन्क्रिप्टेड कनेक्शन दोनों को संभालने के लिए एक एकल पोर्ट को कॉन्फ़िगर करना असंभव है।

• STARTTLS ने SMTP लेनदेन शुरू किया और EHLO की प्रतिक्रिया में TLS के लिए दूसरे छोर से समर्थन की तलाश करता है। यदि क्लाइंट समर्थित कमांड सूची में STARTTLS देखता है, तो वह STARTTLS भेजता है और एन्क्रिप्शन के लिए बातचीत शुरू करता है। यह सब (और आमतौर पर) 25 के मानक SMTP पोर्ट पर होता है, आंशिक रूप से पश्चगामी संगतता के लिए, लेकिन यह भी समापन बिंदुओं के बीच अवसरवादी एन्क्रिप्शन के लिए अनुमति देने के लिए है कि दोनों इसे समर्थन करते हैं लेकिन जरूरी नहीं है।

आम तौर पर, एसएसएल / टीएलएस केवल एंड-क्लाइंट और सर्वर के बीच उपयोग किया जाता है। इंटर-सर्वर ट्रांसपोर्ट को सुरक्षित करने के लिए एमटीए के बीच STARTTLS का आमतौर पर उपयोग किया जाता है।

उन दो कार्यान्वयनों को देखते हुए, STARTTLS को असुरक्षित माना जा सकता है यदि उपयोगकर्ता या व्यवस्थापक यह मान रहे हैं कि कनेक्शन एन्क्रिप्ट किया गया है, लेकिन वास्तव में एन्क्रिप्शन की आवश्यकता के लिए इसे कॉन्फ़िगर नहीं किया गया है। हालाँकि, उपयोग किया जाने वाला एन्क्रिप्शन एसएसएल / टीएलएस के समान है और इसलिए इस प्रकार की कॉन्फ़िगरेशन त्रुटि से परे मैन-इन-द-मिडिल हमले के लिए कम या ज्यादा असुरक्षित नहीं है।

Comments

यदि कनेक्शन एन्क्रिप्ट किया गया है, तो SSL / TLS और STARTTLS दोनों समान हैं, हाँ। लेकिन मैंने ऐसा नहीं पूछा। मेरा मतलब था: अगर मैं STARTTLS का उपयोग करता हूं, तो मैं (एक उपयोगकर्ता के रूप में) कैसे जान सकता हूं कि क्या मेरा कनेक्शन वास्तव में सुरक्षित है? यदि मैं एसएसएल / टीएलएस का उपयोग करने की कोशिश करता हूं तो मैं बस कनेक्ट नहीं कर सकता यदि सर्वर इसका समर्थन नहीं करता है, लेकिन कम से कम कुछ भी प्लेनटेक्स्ट के रूप में नहीं भेजा जाता है। लेकिन अगर STARTTLS वापस सादे संदर्भ में आता है, तो मेरे मेल को मेरे बिना सादे संदर्भ में भेज दिया जाता है, यह जानते हुए कि यह सादे में भेजा गया था (मुझे लगता है कि मैं सुरक्षित हूं जब मैं वास्तव में नहीं हूं)।

— फू बार

मुझे नहीं पता कि इस उत्तर को सही क्यों चुना गया। यह गलत है। जैसा कि क्रिस्टोफर बताते हैं, टीएलएस की तुलना में STARTTLS कम सुरक्षित है क्योंकि यह ग्राहकों को सुरक्षा की झूठी भावना देता है।

— ग्रेग

@ स्पष्ट है कि प्रोटोकॉल में कुछ भी गलत नहीं है। दोष क्लाइंट है जो आरएफसी का पालन नहीं करता है और कनेक्शन एन्क्रिप्ट नहीं होने पर उपयोगकर्ता को चेतावनी नहीं देता है।

— लॉन्गनेक

@ लॉन्गनेक तो ... शायद यह शब्दार्थ की बात है, लेकिन ग्राहक टीएलएस प्रोटोकॉल का "पालन नहीं" कर सकते हैं और एक ईमेल से गुजर सकते हैं। तो यह एक सार्थक अंतर है।

— ग्रेग

@ ब्रूनो "यह केवल कम सुरक्षित है अगर ग्राहक बुरी तरह से लागू होता है" <= आप सिर्फ मेरे लिए अपनी बात बना रहे हैं। यदि कुछ भी है जो क्लाइंट अभी भी कार्यशील कनेक्शन स्थापित करते समय कनेक्शन को असुरक्षित बनाने के लिए कर सकता है, तो STARTTLS स्पष्ट TLS (जहां यह संभव नहीं है) की तुलना में कम सुरक्षित है।

— ग्रेग

Answer 3

विशेष रूप से ईमेल के लिए, जनवरी 2018 में RFC 8314 जारी किया गया था, जो स्पष्ट रूप से यह कहता है कि IMAP, POP3 और SMTP सबमिशन के लिए STARTTLS तंत्र को वरीयता देने के लिए "Implicit TLS" का उपयोग किया जाता है।

संक्षेप में, यह ज्ञापन अब अनुशंसा करता है कि:

• TLS संस्करण 1.2 या उससे अधिक का उपयोग सभी ट्रैफ़िक के लिए MUAs और मेल सबमिशन सर्वर के बीच, और MUAs और मेल सर्वर फ़ेडरेशन सर्वर के बीच भी किया जाता है।
• MUAs और मेल सेवा प्रदाता (MSPs) (a) मेल एक्सेस और मेल सबमिशन के लिए क्लीयरटेक्स्ट प्रोटोकॉल के उपयोग को हतोत्साहित करते हैं और (b) इन उद्देश्यों के लिए क्लीयरटेक्ट प्रोटोकॉल के उपयोग को जल्द से जल्द व्यावहारिक रूप से दर्शाते हैं।
• मेल सबमिशन सर्वर और मेल एक्सेस सर्वर के कनेक्शन "क्लीयरटेक्स्ट" पोर्ट से कनेक्ट करने के लिए और टीएलएस को स्टार्ट करने के लिए STARTTLS कमांड या इसी तरह के कमांड का उपयोग करते हुए "इंप्लिकेंट टीएलएस" (जैसा कि नीचे परिभाषित किया गया है) का उपयोग करके बनाया जा सकता है ।

(महत्व दिया)

Answer 4

उत्तर कुछ हद तक इस बात पर निर्भर करता है कि आपको "सुरक्षित" से क्या मतलब है।

सबसे पहले, आपके सारांश में SSL / TLS और STARTTLS के बीच का अंतर नहीं है।

• एसएसएल / टीएलएस के साथ, क्लाइंट एक "टीसीपी कनेक्शन" के लिए टीसीपी कनेक्शन खोलता है जिसे उस एप्लिकेशन प्रोटोकॉल को सौंपा जाता है जिसे वह उपयोग करना चाहता है, और तुरंत टीएलएस बोलना शुरू करता है।
• STARTTLS के साथ, क्लाइंट "क्लीयरटेक्स्ट पोर्ट" से एक टीसीपी कनेक्शन खोलता है जो एप्लिकेशन प्रोटोकॉल से जुड़ा होता है जिसे वह उपयोग करना चाहता है, फिर सर्वर से पूछता है "आप किस प्रोटोकॉल एक्सटेंशन का समर्थन करते हैं?"। सर्वर तब एक्सटेंशन की सूची के साथ प्रतिक्रिया करता है। यदि उन एक्सटेंशनों में से एक "STARTTLS" है, तो ग्राहक फिर "ठीक है, चलो TLS का उपयोग करें" और दोनों TLS बोलना शुरू कर सकते हैं।

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

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

तो इसका सरल उत्तर यह है कि यदि आप एक ऐसे सर्वर से जुड़ रहे हैं, जिसे आप पहले से ही जानते हैं कि टीएलएस का समर्थन करता है (जैसा कि ईमेल भेजते समय या पढ़ते समय होना चाहिए), तो आपको एसएसएल / टीएलएस का उपयोग करना चाहिए। यदि कनेक्शन पर हमला किया जा रहा है, तो कनेक्शन का प्रयास विफल हो जाएगा, लेकिन आपका पासवर्ड और ईमेल समझौता नहीं किया जाएगा।

दूसरी ओर, यदि आप किसी ऐसी सेवा से जुड़ रहे हैं, जिसे आप नहीं जानते हैं कि वह टीएलएस का समर्थन करती है, तो STARTTLS थोड़ा बेहतर हो सकता है।

जब STARTTLS का आविष्कार किया गया था, तो "निष्क्रिय" सुनने वाले केवल हमले बहुत आम थे, "सक्रिय" हमले जिसमें हमलावर कम सुरक्षा के प्रयास करने के लिए ट्रैफ़िक को इंजेक्ट करेंगे, कम आम थे। तब से 20 या इतने वर्षों में, सक्रिय हमले अधिक संभव और अधिक सामान्य हो गए हैं।

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

Answer 5

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

तो ऐसा क्यों होता है? अनुकूलता कारणों से। यदि दोनों ओर एन्क्रिप्शन का समर्थन नहीं करता है, तो आप अभी भी कनेक्शन ठीक से पूरा कर सकते हैं।

Comments

तो, STARTTLS में सक्षम सर्वर भी हमेशा SSL / TLS के लिए सक्षम होगा, है ना? इसलिए पहले एसएसएल / टीएलएस को आज़माना बेहतर है और देखें कि क्या यह काम करता है?

— फू बार

@FooBar नहीं, एक का मतलब यह नहीं है कि दूसरा उपलब्ध है। वास्तव में, उन्हें पूरी तरह से अलग प्रमाणीकरण डोमेन के साथ कॉन्फ़िगर किया जा सकता है।

— लॉन्गनेक जूल 16'13

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

— फाल्कन मोमेंट

पता नहीं क्यों लोग आपको नीचा दिखा रहे हैं, यह सही उत्तर है, टीएलएस की तुलना में STARTTLS कम सुरक्षित है, और यह सुरक्षा की झूठी भावना देता है। आईएसपी बस इसे स्टिप कर सकते हैं: arstechnica.com/tech-policy/2014/11/…

— ग्रेग

जहां तक ​​प्रोटोकॉल खुद ही चला जाता है, टीएलटीएस की तुलना में STARTTLS कम सुरक्षित है क्योंकि यह स्पष्ट रूप से उपयोगकर्ता को चेतावनी दिए बिना सादे-पाठ संचार की अनुमति देता है: serverfault.com/a/648282/207987

— ग्रेग

Answer 6

@Greg से सहमत हैं। उन पर हमला संभव है। हालांकि एमटीए को "अनिवार्य टीएलएस" का उपयोग करने के लिए (एमटीए के आधार पर) कॉन्फ़िगर किया जा सकता है, न कि "अवसरवादी टीएलएस"। इसका मतलब यह है कि ईमेल लेनदेन के लिए TLS और केवल TLS का उपयोग किया जाता है (इसमें STARTTLS भी शामिल है)। यदि दूरस्थ MTA STARTTLS का समर्थन नहीं करता है, तो ईमेल बाउंस हो जाता है।

Answer 7

नहीं, यह कम सुरक्षित नहीं है , जब आपका एप्लिकेशन इसे सही ढंग से संभालता है।

टीएलएस को संभालने के लिए चार रास्ते हैं और कई कार्यक्रम आपको चुनने की अनुमति देते हैं:

• कोई टीएलएस नहीं
• समर्पित बंदरगाह पर टीएलएस (केवल टीएलएस की कोशिश करता है)
• यदि उपलब्ध हो तो टीएलएस का उपयोग करें ( starttlsविफल होने पर अनएन्क्रिप्टेड कनेक्शन का उपयोग करता है)
• हमेशा टीएलएस का उपयोग करें ( starttlsयदि यह काम नहीं करता है तो विफल रहता है)

एक समर्पित पोर्ट पर टीएलएस का लाभ यह है कि, आप यह सुनिश्चित कर सकते हैं कि जब आप किसी प्रोग्राम का उपयोग नहीं करते हैं, जिसमें आपको अभी तक पता नहीं है या जो इसके पहले-प्रारंभ विज़ार्ड में त्रुटि से निपटने के लिए विस्तार सेटिंग्स को उजागर नहीं करता है, तो कोई कमबैक नहीं है।

लेकिन सामान्य तौर पर सुरक्षा सुरक्षा त्रुटियों से निपटने पर निर्भर करती है। जब टीएलएस-पोर्ट पर टीएलएस विफल हो जाता है तो एक प्रोग्राम प्लेनटेक्स्ट पोर्ट पर स्विच करने का निर्णय ले सकता है। आपको यह जानना होगा कि यह क्या करेगा और सुरक्षित सेटिंग्स का चयन करेगा। और कार्यक्रमों को सुरक्षित चूक का उपयोग करना चाहिए।