सवाल क्या टीएलएस / एसएसएल से STARTTLS कम सुरक्षित है?


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

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

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

एसएसटीटीएलएस एसएसएल / टीएलएस से कम सुरक्षित है, क्योंकि यह मुझे सूचित किए बिना सादे पाठ में फॉलबैक कर सकता है?


43
2017-07-16 19:07


मूल




जवाब:


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

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

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

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

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

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


43
2017-12-01 16:43



आपका बिंदु निश्चित रूप से मान्य है, लेकिन एसएमटीपीएस (यानि एसएमटीपी + "निहित एसएसएल / टीएलएस" जहां एसएसएल / टीएलएस पहले स्थापित किया गया है) के संबंध में किसी भी आरएफसी या आधिकारिक विनिर्देश की कमी के कारण, एसएमटीपी / एसएमटीपीएस ग्राहक भी एक सादे कनेक्शन में गिरने का फैसला कर सकते हैं अगर वे बंदरगाह 465 पर एसएसएल / टीएलएस कनेक्शन शुरू करने का प्रबंधन नहीं कर सकते हैं। यह अभी भी पूरी तरह कार्यान्वयन विकल्प है। - Bruno
टीएलएस कनेक्शन स्थापित करने के लिए बहुत सारे आरएफसी हैं। आरएफसी के अनुरूप होने के विकल्प के रूप में कहीं भी "सादे-पाठ कनेक्शन की अनुमति नहीं है" (कम से कम यह कई लोगों के लिए खबर होगी)। इसलिए एसएमटीपीएस को एक अलग आरएफसी की आवश्यकता नहीं है जो STARTTLS से अधिक सुरक्षित हो। - Greg
टीएलएस (आरएफसी 5246 और पूर्ववर्ती), पीकेआई (आरएफसी 5280), नाम सत्यापन (आरएफसी 6125) के बारे में आरएफसी हैं, लेकिन एसएमटीपीएस आधिकारिक तौर पर AFAIK में एसएमटीपी और एसएसएल / टीएलएस के बीच बातचीत का वर्णन करने के लिए कुछ भी नहीं, जैसा कि आपको मिलता है एचटीटीपीएस के लिए एक नमूना: आरएफसी 2818. कोई कह सकता है "यह स्पष्ट है, बस पहले एसएसएल / टीएलएस कनेक्शन स्थापित करें", लेकिन इसके बारे में सबकुछ स्पष्ट नहीं है (विशेष रूप से पहचान सत्यापन पहलू, जिसे हाल ही में आरएफसी 6125 में औपचारिक रूप से औपचारिक रूप दिया गया है)। - Bruno


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

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

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

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

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


21
2017-07-16 19:40



यदि कनेक्शन एन्क्रिप्ट किया गया है, तो एसएसएल / टीएलएस और STARTTLS दोनों समान हैं, हां। लेकिन मैंने यही नहीं पूछा। मेरा मतलब था: अगर मैं STARTTLS का उपयोग करता हूं, तो मैं (उपयोगकर्ता के रूप में) कैसे जानता हूं कि मेरा कनेक्शन वास्तव में सुरक्षित है या नहीं? अगर मैं एसएसएल / टीएलएस का उपयोग करने की कोशिश करता हूं तो मैं कनेक्ट नहीं कर सकता अगर सर्वर इसका समर्थन नहीं करता है, लेकिन कम से कम कुछ भी सादे टेक्स्ट के रूप में नहीं भेजा जाता है। लेकिन अगर STARTTLS सादे टेक्स्ट पर वापस आ जाता है, तो मेरा मेल सादे टेक्स्ट में भेजा जाता है बिना मुझे यह जानकर कि यह सादे टेक्स्ट में भेजा गया था (मुझे लगता है कि जब मैं वास्तव में नहीं हूं तो मैं सुरक्षित हूं)। - Foo Bar
मुझे नहीं पता कि यह जवाब सही क्यों चुना गया था। यह गलत है। जैसा कि क्रिस्टोफर बताते हैं, STARTTLS टीएलएस से कम सुरक्षित है क्योंकि यह ग्राहकों को सुरक्षा की झूठी भावना देता है। - Greg
@greg प्रोटोकॉल के साथ कुछ भी गलत नहीं है। दोष उन क्लाइंट हैं जो आरएफसी का पालन नहीं करते हैं और कनेक्शन को एन्क्रिप्ट नहीं करते समय उपयोगकर्ता को चेतावनी नहीं देते हैं। - longneck
@ लोंगनेक तो ... शायद यह एक अर्थशास्त्र चीज है, लेकिन ग्राहक टीएलएस प्रोटोकॉल का "पालन नहीं कर सकते" और एक ईमेल, अवधि के माध्यम से जा सकते हैं। तो यह एक सार्थक अंतर है। - Greg
@ ब्रूनो "क्लाइंट बुरी तरह लागू होने पर यह केवल कम सुरक्षित है" <= आप बस मेरे लिए अपना मुद्दा बना रहे हैं। यदि कोई ऐसा काम है जो ग्राहक अभी भी एक कार्यशील कनेक्शन स्थापित करते समय कनेक्शन असुरक्षित बनाने के लिए कर सकता है, तो STARTTLS स्पष्ट टीएलएस (जहां यह संभव नहीं है) से कम सुरक्षित है। - Greg


विशेष रूप से जनवरी 2018 में ईमेल के लिए आरएफसी 8314 जारी किया गया था, जो स्पष्ट रूप से सिफारिश करता है कि "लागू टीएलएस" का उपयोग आईएमएपी, पीओपी 3, और एसएमटीपी सबमिशन के लिए STARTTLS तंत्र को प्राथमिकता में किया जाना चाहिए।

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

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

(महत्व दिया)


6
2018-02-01 19:38





उत्तर "सुरक्षित" से आपका मतलब है कि कुछ डिग्री पर निर्भर करता है।

सबसे पहले, आपका सारांश एसएसएल / टीएलएस और स्टार्ट टीएलएस के बीच अंतर को काफी प्रभावित नहीं करता है।

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

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

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

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

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

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

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


2
2018-02-02 09:29





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

तो ऐसी चीज क्यों मौजूद है? संगतता कारणों के लिए। यदि कोई पक्ष एन्क्रिप्शन का समर्थन नहीं करता है, तो भी आप कनेक्शन को ठीक से पूरा करना चाहते हैं।


1
2017-07-16 19:20



तो, STARTTLS के लिए सक्षम एक सर्वर हमेशा एसएसएल / टीएलएस के लिए सक्षम होगा, है ना? तो एसएसएल / टीएलएस पहले कोशिश करना हमेशा बेहतर होता है और देखें कि यह काम करता है या नहीं? - Foo Bar
@FooBar नहीं, कोई मतलब नहीं है कि दूसरा उपलब्ध है। वास्तव में, वे पूरी तरह से अलग प्रमाणीकरण डोमेन के साथ कॉन्फ़िगर किया जा सकता है। - longneck
STARTTLS मिटएम के लिए कमजोर नहीं है जबतक कि आप प्रमाण पत्र मान्य नहीं करते हैं या कमजोर लोगों का उपयोग नहीं करते हैं। प्रमाण पत्र अभी भी हमेशा के जैसा ही प्रस्तुत किया गया है, और ग्राहक को यह आवश्यक हो सकता है कि जारी रखने से पहले टीएलएस अपग्रेड सफल हो जाए। यह ध्यान देने योग्य है कि यह एसएसएल / टीएलएस जैसी ही स्थिति है। - Falcon Momot
पता नहीं क्यों लोग आपको कम कर रहे हैं, यह सही जवाब है, STTTLS टीएलएस की तुलना में कम सुरक्षित है, और यह सुरक्षा की झूठी भावना देता है। आईएसपी बस इसे छोड़ सकते हैं: arstechnica.com/tech-policy/2014/11/... - Greg
जहां तक ​​प्रोटोकॉल स्वयं जाता है, STTTLS टीएलएस से कम सुरक्षित है क्योंकि यह स्पष्ट रूप से उपयोगकर्ता को चेतावनी दिए बिना सादे-पाठ संचार की अनुमति देता है: serverfault.com/a/648282/207987 - Greg


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


1
2018-04-02 23:47





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

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

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

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

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


0
2018-02-02 10:10