सवाल एसएमटीपी के लिए एन्क्रिप्शन लागू करना एक अच्छा विचार है (अभी तक)?


मैं एक ईमेल सर्वर चला रहा हूं जो वर्तमान में ईमेल भेजते और प्राप्त करते समय टीएलएस का उपयोग करने के लिए सेट अप किया गया है।

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

लेकिन क्या यह अभी भी एक मुद्दा है जिसके बारे में सोचना चाहिए या यह कहना सुरक्षित है कि एन्क्रिप्शन लागू करना अब कोई समस्या नहीं होगी?

क्या संभवतः कुछ बड़ा प्रदाता है जो पहले से ही ऐसा कर रहा है या आप इन दिनों सबसे अच्छा अभ्यास क्यों करते हैं?


36
2017-10-18 12:33


मूल




जवाब:


व्यावहारिक समस्या यह है कि प्रत्येक एसएमटीपी-अनुरूप नहीं (आरएफसी काफी पुराना है) सर्वर आपके सर्वर पर टीएलएस बोल सकता है, इसलिए आप कुछ ईमेल संदेश प्राप्त करना याद कर सकते हैं।

इसके साथ दार्शनिक समस्या यह है कि यह बताने में असंभव है कि ईमेल आपके सर्वर पर आने के बाद (या इससे पहले) कैसे रिले किया जाता है।

इसका अर्थ यह है कि ईमेल पहले से ही एक रिले के माध्यम से सादा पाठ में प्रेषित किया जा सकता है।

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

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

संपादित करें: यह रिलेइंग के प्रयोजनों के लिए एसएमटीपी प्रवर्तन को संदर्भित करता है, नहीं ईमेल जमा करना मेल सबमिशन एन्क्रिप्शन में लागू किया जाना चाहिए क्योंकि एसएमटीपी वार्तालाप (वास्तविक ईमेल नहीं) में संभवतः प्रमाणीकरण प्रमाण-पत्र शामिल हैं।


34
2017-10-18 12:43



मुझे नहीं लगता कि यह सबसे अच्छा जवाब है। यह सही नीचे-रेखा निष्कर्ष पर जाता है, लेकिन गलत कारणों से। यह "तर्क के अच्छे दुश्मन बनने के लिए सही" दे रहा है। मुझे लगता है कि बेहतर जवाब यह है कि यदि आपको एन्क्रिप्शन की आवश्यकता है, तो आप कुछ वैध ईमेल को प्राप्त करने से रोक देंगे (क्योंकि कुछ एसएमटीपी सर्वर एन्क्रिप्ट नहीं कर सकते हैं)। अगर यह उस कारक के लिए नहीं था, तो एन्क्रिप्शन लागू करना होगा लाभकारी हो, भले ही आप इसे सूचीबद्ध करने के सभी कारणों के लिए सही नहीं हैं - यह कुछ भी नहीं होगा, भले ही यह सही न हो। - D.W.
मैं केवल उपनिवेशों के अतिरिक्त पूर्णता पर असहमत हूं; फिर भी मैंने आरएफसी के अनुरूप सर्वरों की संभावित-तकनीकी-असंगतता पर बल देने के लिए उत्तर में एक संपादन सबमिट किया लेकिन टीएलएस का समर्थन नहीं किया। - Alex Mazzariol
आपके उत्तर के लिए धन्यवाद! सबसे पहले मैंने नहीं सोचा था कि मेरे सर्वर ने अगले सर्वर पर मेल भेजने के बाद क्या किया, या जैसा कि आपने कहा था, जहां संदेश मेरे पास पहुंचने से पहले "पहले से ही" हो चुका है। निस्संदेह एन्क्रिप्शन को लागू करने में कोई समझ नहीं है, अगर प्राप्त करने वाला पक्ष इसे सादे पाठ में भेजता है (शायद उसी कंपनी के सबसेवर पर लेकिन फिर भी इंटरनेट पर)। - comfreak
मैंने इस उत्तर को स्वीकार किए गए एक के रूप में चुना क्योंकि यह सबसे अच्छा स्पष्ट करता है कि मेरे सर्वर पर एन्क्रिप्शन लागू करने से प्रेषक से प्राप्तकर्ता को संदेश के सुरक्षित / एन्क्रिप्टेड स्थानांतरण की गारंटी नहीं मिलेगी, बल्कि केवल मेरे सर्वर से अगले तक। - comfreak
मुझे लगता है कि यह जवाब अच्छा है, लेकिन यह उल्लेख करने में विफल रहता है कि एन्क्रिप्शन अभी भी वांछित है क्योंकि केवल सीमित मामलों में कोई व्यक्ति आपको मूर्ख बनाने के लिए प्रेषक के क्लीयरएक्स्ट संदेश को रोकने के लिए बहुत अधिक समय तक जाता है। यदि आप सीआईए / एनएसए से छिप रहे हैं तो सुनिश्चित करें कि आपकी मदद नहीं कर सकता है। लेकिन बेहतर होगा, एन्क्रिप्शन को लागू करने के लिए, ताकि प्रेषक संदेश को पढ़ने / इसे रोकने में स्पष्ट रुचि वाले कोई भी व्यक्ति न हो और जब तक कोई तृतीय पक्ष आपके ऊपर स्नूप करने का प्रयास नहीं करता है या आपके सभी संदेशों को एनएसए सर्वर पर संग्रहीत करने का प्रयास करता है ताकि वह एक दिन, वे न केवल शुरू कर सकते हैं ... - momo


नहीं

आरएफसी 821 33 साल का है। आप मर्जी STARTTLS को समर्थन देने वाले प्रोग्राम्स द्वारा रिले किए गए ईमेल ढूंढें। कभी-कभी वे ईमेल प्रेषक (उदाहरण के लिए आंतरिक स्क्रिप्ट), कभी-कभी पूर्ण पुराने सिस्टम होंगे जो पुराने होते हैं, टीएलएस अक्षम / संकलित नहीं होते हैं, पर्याप्त एन्ट्रॉपी के बिना सिस्टम ...

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

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

वहाँ है https://www.eff.org/starttls-everywhere परियोजना smtp सर्वर की एक सूची प्रदान करती है जिसके लिए आप (चाहिए?) आत्मविश्वास से स्टार्टल उपयोग को लागू कर सकते हैं।


20
2017-10-18 17:49



उत्तर के लिए धन्यवाद और उस लिंक को पोस्ट करने के लिए धन्यवाद! यह एक अनएन्क्रिप्टेड वार्तालाप के कनेक्शन को डाउनग्रेड करने वाले व्यक्ति-में-मध्य-हमले के मुद्दे को हल करने के लिए एक अच्छा दृष्टिकोण प्रतीत होता है। - comfreak


एन्क्रिप्शन-अक्षम करने योग्य सहकर्मियों से ईमेल को अस्वीकार करने के लिए यह पूरी तरह से व्यर्थ है, और संभवतः सक्रिय रूप से हानिकारक है।

जब तक आपका सर्वर किसी भी सहकर्मी के साथ अवसरवादी एन्क्रिप्शन करने के लिए स्थापित होता है, तो आप दोनों दुनिया के सर्वश्रेष्ठ प्राप्त करते हैं: यह उपलब्ध होने पर एन्क्रिप्शन, और जब यह नहीं होता है तो सादे टेक्स्ट पर ईमेल करें।

जब तक ऐसे सर्वर होते हैं जो एन्क्रिप्शन का समर्थन नहीं करते हैं, तो इसका अर्थ यह है कि वे आपसे बात नहीं कर सकते हैं; यह बुरी बात है। एक बार जब हर कोई इसका समर्थन करता है, तो अवसरवादी और अनिवार्य एन्क्रिप्शन के बीच कोई अंतर नहीं होता है।

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


11
2017-10-18 15:38



मैं तर्क दूंगा कि दोनों दुनिया के सर्वश्रेष्ठ आपको वेब पर एक एसएसएल पेज के "लॉक" के समान अंतर देखने की अनुमति देंगे, ताकि आप जान सकें कि कौन से ई-मेल अवरुद्ध किए गए हैं, क्या आपने टीएलएस को मजबूर कर दिया था - user2813274
@ user2813274 मैं सहमत हूं, और यह करता है। अपने शीर्षलेखों की जांच करें; वे आपको दिखाएंगे कि ट्रांसमिशन श्रृंखला का कोई भी कदम एन्क्रिप्शन के साथ या बिना किया गया था। - MadHatter
@MadHatter जब तक कि उन शीर्षकों को पूरी तरह से आपके द्वारा हॉप द्वारा जाली नहीं थी। - thrig
क्या आप वहां मौजूद हैं है अवसरवादी और अनिवार्य एन्क्रिप्शन के बीच एक अंतर। एक सक्रिय एमआईटीएम के लिए अवसरवादी एन्क्रिप्शन को बाधित करना अक्सर संभव होता है, जिसके कारण एंडपॉइंट्स को एन्क्रिप्शन पर वापस आना पड़ता है, जिस पर नजर रखी जा सकती है। अनिवार्य एन्क्रिप्शन के साथ, कनेक्शन गिरा दिया जाएगा, जिससे सेवा अस्वीकार हो जाएगी लेकिन गोपनीयता का उल्लंघन नहीं होगा। - cjm
इसलिए @cjm खतरे के मॉडल के बारे में मेरा मुद्दा। यदि आप गंभीर रूप से एमआईटीएम हमलों के खिलाफ बचाव करने की कोशिश कर रहे हैं, तो केवल एंड-टू-एंड-एन्क्रिप्शन मदद कर सकता है। अकेले एसएमटीपी एन्क्रिप्शन पर निर्भरता व्यर्थ है; एक परिष्कृत एमआईटीएम बस आपके सर्वर के रूप में मजाक कर देगा, फिर इसे पढ़ने के बाद मेल को रिले करें। निश्चित रूप से, आपके सर्वर पर एक उचित हस्ताक्षरित प्रमाणपत्र हो सकता है (जो आश्चर्यजनक रूप से दुर्लभ है) लेकिन आप यह नियंत्रित नहीं कर सकते कि सिस्टम आपको भेजने की आवश्यकता है या नहीं, इसलिए इस तरह के एक एमआईटीएम हमले एन्क्रिप्टेड कनेक्शन पर रखे गए किसी भी आवश्यकता के बावजूद सफल होंगे। - MadHatter


यह एक नीतिगत मामला है।

आम तौर पर जब टीएलएस को इनबाउंड और आउटबाउंड के लिए लागू किया जाता है, तो यह उन डोमेनों के सीमित सेट के लिए किया जाता है जो पार्टियों द्वारा आवश्यकता को पूरा करने के लिए सहमत होते हैं (उदाहरण के लिए, व्यापार भागीदारों के पास अपनी कंपनियों के बीच सभी मेल एन्क्रिप्ट करने का एक समझौता हो सकता है)।

जब तक ऐसा कोई समझौता न हो, तब तक लागू मोड चालू न करें।


10
2017-10-18 14:29





नहीं, यह एक बहुत बुरा विचार है।

वास्तव में, जैसा कि यह पता चला है, सबसे अधिक STARTTLS सर्वर / क्लाइंट किसी भी प्रकार के एक पुनः प्रयास एल्गोरिदम को स्टार्ट टीएलएस के बिना लागू नहीं करते हैं, एक टीएलएस कनेक्शन बातचीत करने में विफल होना चाहिए।

इस प्रकार, यहां तक ​​कि एक विकल्प के रूप में STARTTLS विज्ञापन भी पहले ही ईमेल प्राप्त करने (और भेजने) की संभावनाओं को कम कर देता है!

बस खोज करें, और आप पाएंगे कि बहुत से लोग * .protection.outlook.com क्लस्टर द्वारा प्रबंधित माइक्रोसॉफ्ट आउटलुक डोमेन पर कोई भी ईमेल भेजने में सक्षम नहीं हैं:

टीएलएस का उपयोग करते समय Sendmail संदेशों को माइक्रोसॉफ्ट से खारिज कर दिया गया

कारण: 403 4.7.0 टीएलएस हैंडशेक असफल रहा

उपर्युक्त दो पदों में प्रस्तुत मुद्दों को सारांशित करने के लिए:

  • STARTTLS के साथ या उसके बिना Outlook द्वारा प्रबंधित किए गए किसी भी होस्ट को कोई भी मेल भेज सकता है,
  • क्लाइंट प्रमाण पत्र के बिना मेल और STARTTLS के बिना Outlook भेज सकते हैं,
  • या शून्य-लंबाई क्लाइंट प्रमाणपत्र के साथ,
  • लेकिन माइक्रोसॉफ्ट पसंद नहीं करता है, और विफलता पर, क्लाइंट (अच्छी तरह से, क्लाइंट मोड में काम कर रहे सर्वर) STARTTLS के बिना संदेश फिर से भेजने का प्रयास नहीं करते हैं अगर प्राप्तकर्ता का सर्वर STARTTLS का विज्ञापन करता है!

इसी तरह, जब आपका होस्ट सर्वर के रूप में कार्य करता है, तो यदि आप STARTTLS को सक्षम करने का निर्णय लेते हैं तो एक समान स्थिति आपके नियंत्रण के बाहर हो सकती है - जब कोई क्लाइंट सर्वर देखता है कि सर्वर सर्वर में आपका सर्वर STARTTLS प्रदान करता है, तो वे टीएलएस पर बातचीत करने का प्रयास करते हैं, लेकिन यदि वार्ता विफल हो जाती है , वे बस प्रतीक्षा करते हैं, और एक ही कदम फिर से प्रयास करते हैं, जब तक संदेश प्रेषक को वापस बाउंस नहीं किया जाता है तब तक असफल रहें!

और यह STARTTLS भूमि में विभिन्न डोमेन के साथ अक्सर होता है!

अफसोस की बात है, जितना मैं अतीत में एक STARTTLS समर्थक होता था, अब मैं बहुत निराश हूं कि मुझे जोखिम मुक्त विज्ञापन से गुमराह किया गया था जिसे मैंने सोचा था कि मुझे अवसरवादी एन्क्रिप्शन माना जाता था।

आपको केवल STARTTLS की आवश्यकता नहीं है, लेकिन यदि आप अंतःक्रियाशीलता सुनिश्चित करना चाहते हैं, तो यह पूरी तरह अक्षम करने के लिए भी समझदार हो सकता है।


2
2017-10-20 10:20





मुझे opportunistic टीएलएस का उपयोग करने के विचार पर सहमत होना है। हालांकि, मेरे पास इस विचार को जोड़ने के लिए कुछ भी है। कुछ सुझावों से परेशान होंगे, हालांकि, यहां मेरे सुझावों को हल्के ढंग से और उचित विचार किए बिना, निर्णय लेने से पहले, मैं पूछता हूं कि आप संलग्न लिंक से पूरी चर्चा पढ़ें।

अवसरवादी टीएलएस का उपयोग करना सबसे अच्छा समाधान दूर और व्यापक है। इसके खिलाफ एक तर्क के रूप में एमआईटीएम कोण एक लाल हेरिंग है। आखिरकार, जैसा कि एमएच ने एक टिप्पणी में उल्लेख किया है, टीएलएस कनेक्शन के साथ एक "कानूनी" एसएमटीपी भी एमआईटीएम किया जा सकता है और अंतिम उपयोगकर्ता मेल क्लाइंट के विशाल बहुमत के कारण बुद्धिमान नहीं है क्योंकि विशाल बहुमत के साथ प्रमाणपत्र प्रमाणित करने के लिए परेशान नहीं है टीएलएस कर रहे एमटीए के स्व-हस्ताक्षरित प्रमाणपत्रों का उपयोग कर रहे हैं (कम से कम अगर आप DNSSEC और TLSA / DANE का उपयोग नहीं कर रहे हैं।) इस और संभवतः अन्य कारकों के परिणामस्वरूप, यह भी तर्कसंगत है कि जब तक आप और बाकी दुनिया ने डीएएनई / टीएलएसए और डीएनएसईसीसी को कार्यान्वित किया है, कि अवसरवादी टीएलएस चलाने के दौरान यह भी अज्ञात diffie-hellman (पीएफएस का उपयोग करते हुए) भी सक्षम नहीं है। कम से कम आंशिक रूप से यदि अधिकतर तथ्य यह नहीं है कि यह अभी भी आकस्मिक पर्यवेक्षक के खिलाफ यातायात की रक्षा करेगा। इस कॉन्फ़िगरेशन के आगे समर्थन में (मेरे मुकाबले ज्यादा विस्तृत स्पष्टीकरण के साथ) कृपया इस पोस्ट में विक्टर दुखोवनी द्वारा पोस्टफिक्स फ़ोरम में टिप्पणियां देखें: http://postfix.1071664.n5.nabble.com/Disabling-Anonymous-Diffie-Hellman-td67965.html 

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

उम्मीद है की यह मदद करेगा।


2
2017-10-20 19:07





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


0
2017-10-20 01:25