क्या SMTP के लिए एन्क्रिप्शन एक अच्छा विचार है (अभी तक)?

36

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

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

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

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

encryption tls smtps

— comfreak
स्रोत

34

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

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

इसका मतलब है कि ईमेल पहले से ही रिले के माध्यम से सादे-पाठ में प्रेषित हो सकता है।

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

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

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

— मैथ्यू इफ
स्रोत

7

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

— डीडब्ल्यू

मैं उपप्रकार के मात्र जोड़ द्वारा पूर्णता पर असहमत हो जाता हूं; फिर भी मैंने RFC के अनुरूप सर्वर की संभावित-तकनीकी-असंगति पर जोर देने के लिए उत्तर पर एक संपादन प्रस्तुत किया, लेकिन टीएलएस के साथ नहीं।

— एलेक्स माजारिओल

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

— comfreak

मैंने इस उत्तर को स्वीकार कर लिया क्योंकि यह स्पष्ट है कि मेरे सर्वर पर एन्क्रिप्शन लागू करने से संदेश भेजने वाले से प्राप्तकर्ता को संदेश की सुरक्षित / एन्क्रिप्टेड हस्तांतरण की गारंटी नहीं होगी, लेकिन केवल मेरे सर्वर से अगले तक।

— कॉम्फ्रेक

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

— मोमोमो

20

नहीं

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

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

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

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

— देवदूत
स्रोत

3

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

— कॉमफ्रीक

11

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

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

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

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

— MadHatter मोनिका का समर्थन करता है
स्रोत

मेरा तर्क है कि दोनों दुनिया के सर्वश्रेष्ठ भी आपको अंतर को देखने की अनुमति देंगे, वेब पर एक एसएसएल पेज के "लॉक" के समान, इसलिए आपको पता है कि कौन से ई-मेल * ब्लॉक किए गए हैं आपने टीएलएस को मजबूर किया है

— user2813274

@ user2813274 मैं सहमत हूं, और यह करता है। अपने हेडर की जांच करें; वे आपको दिखाएंगे कि ट्रांसमिशन श्रृंखला के किसी भी चरण के साथ, या बिना एन्क्रिप्शन के प्रदर्शन किया गया था या नहीं।

— MadHatter

@MadHatter जब तक कि हेडर पूरी तरह से आपके द्वारा पहले से ही जाली नहीं थे।

— प्रात

8

वहाँ है अवसरवादी और अनिवार्य एन्क्रिप्शन के बीच एक अंतर। यह एक सक्रिय MITM के लिए अवसरवादी एन्क्रिप्शन को बाधित करने के लिए अक्सर संभव है, जिससे समापन बिंदु बिना एन्क्रिप्शन के वापस गिर जाते हैं, जिसकी निगरानी की जा सकती है। अनिवार्य एन्क्रिप्शन के साथ, कनेक्शन को गिरा दिया जाएगा, जिससे सेवा से इनकार किया जाएगा लेकिन गोपनीयता भंग नहीं होगी।

— cjm

4

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

— MadHatter

10

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

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

जब तक इस तरह का समझौता नहीं होता है, तब तक मोड को चालू न करें।

— MikeyB
स्रोत

2

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

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

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

बस खोज करें, और आप बहुत से लोगों को * .protection.out.com.com द्वारा संभाले Microsoft आउटलुक डोमेन के लिए कोई भी ईमेल नहीं भेज पाएंगे।

TLS का उपयोग करते समय Microsoft से Sendmail संदेश अस्वीकृत

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

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

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

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

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

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

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

— CNST
स्रोत

2

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

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

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

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

— Mce128
स्रोत

0

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

— ईआरएम
स्रोत