संक्षेप में, एमटीए-एसटीएस मेल सर्वर के बीच संचारित होने पर ईमेल को अवरोधन (यानी, मैन-इन-द-मिडिल हमलों उर्फ ​​मिटएम) से बचाने का एक तरीका है। यह आंशिक रूप से ईमेल प्रोटोकॉल की पुरानी वास्तुशिल्प समस्याओं को हल करता है और अपेक्षाकृत हाल के मानक RFC 8461 में वर्णित है। Mail.ru इस मानक को लागू करने के लिए RuNet पर पहली प्रमुख मेल सेवा है। और कट के अंतर्गत इसका अधिक विस्तार से वर्णन किया गया है।

एमटीए-एसटीएस किस समस्या का समाधान करता है?

ऐतिहासिक रूप से, ईमेल प्रोटोकॉल (SMTP, POP3, IMAP) स्पष्ट पाठ में जानकारी प्रसारित करते हैं, जिससे इसे रोकना संभव हो जाता है, उदाहरण के लिए, संचार चैनल तक पहुंचते समय।

एक उपयोगकर्ता से दूसरे उपयोगकर्ता तक पत्र पहुंचाने की व्यवस्था कैसी दिखती है:

ऐतिहासिक रूप से, एमआईटीएम हमला उन सभी स्थानों पर संभव था जहां मेल प्रसारित होता है।

RFC 8314 को मेल उपयोगकर्ता एप्लिकेशन (MUA) और मेल सर्वर के बीच TLS के उपयोग की आवश्यकता होती है। यदि आपका सर्वर और आपके द्वारा उपयोग किए जाने वाले मेल एप्लिकेशन RFC 8314 के अनुरूप हैं, तो आपने (काफी हद तक) उपयोगकर्ता और मेल सर्वर के बीच मैन-इन-द-मिडिल हमलों की संभावना को समाप्त कर दिया है।

आम तौर पर स्वीकृत प्रथाओं (आरएफसी 8314 द्वारा मानकीकृत) का पालन करने से उपयोगकर्ता के पास हमला समाप्त हो जाता है:

मानक अपनाने से पहले ही Mail.ru मेल सर्वर RFC 8314 का अनुपालन करते थे; वास्तव में, यह केवल पहले से ही स्वीकृत प्रथाओं को पकड़ता है, और हमें कुछ भी अतिरिक्त कॉन्फ़िगर करने की आवश्यकता नहीं थी। लेकिन, यदि आपका मेल सर्वर अभी भी उपयोगकर्ताओं को असुरक्षित प्रोटोकॉल का उपयोग करने की अनुमति देता है, तो इस मानक की सिफारिशों को लागू करना सुनिश्चित करें, क्योंकि सबसे अधिक संभावना है, कम से कम आपके कुछ उपयोगकर्ता बिना एन्क्रिप्शन के मेल के साथ काम करते हैं, भले ही आप इसका समर्थन करते हों।

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

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

आंशिक रूप से क्यों? एमटीए-एसटीएस केवल तभी काम करता है जब दोनों पक्षों ने इस मानक को लागू करने का ध्यान रखा हो, और एमटीए-एसटीएस उन परिदृश्यों से रक्षा नहीं करता है जिसमें एक हमलावर सार्वजनिक सीए में से एक से वैध डोमेन प्रमाणपत्र प्राप्त करने में सक्षम होता है।

एमटीए-एसटीएस कैसे काम करता है

प्राप्तकर्ता

1. मेल सर्वर पर वैध प्रमाणपत्र के साथ STARTTLS समर्थन कॉन्फ़िगर करता है। 
2. एचटीटीपीएस के माध्यम से एमटीए-एसटीएस नीति प्रकाशित करता है; उदाहरण के लिए, प्रकाशन के लिए एक विशेष एमटीए-एसटीएस डोमेन और एक विशेष प्रसिद्ध पथ का उपयोग किया जाता है https://mta-sts.mail.ru/.well-known/mta-sts.txt. नीति में मेल सर्वर (एमएक्स) की एक सूची शामिल है जिनके पास इस डोमेन के लिए मेल प्राप्त करने का अधिकार है।
3. नीति संस्करण के साथ DNS में एक विशेष TXT रिकॉर्ड _mta-sts प्रकाशित करता है। जब नीति बदलती है, तो इस प्रविष्टि को अद्यतन किया जाना चाहिए (यह प्रेषक को नीति को फिर से पूछने का संकेत देता है)। उदाहरण के लिए, _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

प्रेषक

प्रेषक _mta-sts DNS रिकॉर्ड का अनुरोध करता है, और यदि यह उपलब्ध है, तो HTTPS (प्रमाणपत्र की जाँच) के माध्यम से एक नीति अनुरोध करता है। परिणामी नीति कैश्ड हो जाती है (यदि कोई हमलावर उस तक पहुंच को अवरुद्ध कर देता है या DNS रिकॉर्ड को खराब कर देता है)।

मेल भेजते समय यह जांचा जाता है कि:

• जिस सर्वर पर मेल डिलीवर किया जाता है वह पॉलिसी में है;
• सर्वर TLS (STARTTLS) का उपयोग करके मेल स्वीकार करता है और उसके पास एक वैध प्रमाणपत्र है।

एमटीए-एसटीएस के लाभ

एमटीए-एसटीएस उन प्रौद्योगिकियों का उपयोग करता है जो पहले से ही अधिकांश संगठनों (एसएमटीपी+स्टार्टटीएलएस, एचटीटीपीएस, डीएनएस) में लागू हैं। प्राप्तकर्ता पक्ष पर कार्यान्वयन के लिए, मानक के लिए किसी विशेष सॉफ़्टवेयर समर्थन की आवश्यकता नहीं है।

एमटीए-एसटीएस के नुकसान

वेब और मेल सर्वर प्रमाणपत्र की वैधता, नामों के पत्राचार और समय पर नवीनीकरण की निगरानी करना आवश्यक है। प्रमाणपत्र के साथ समस्याओं के परिणामस्वरूप मेल वितरित नहीं हो पाएगा।

प्रेषक पक्ष पर, एमटीए-एसटीएस नीतियों के समर्थन के साथ एक एमटीए की आवश्यकता है; वर्तमान में, एमटीए-एसटीएस एमटीए में बॉक्स से बाहर समर्थित नहीं है।

एमटीए-एसटीएस विश्वसनीय रूट सीए की सूची का उपयोग करता है।

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

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

प्रतिस्पर्धी मानक - डेन

DANE प्रमाणपत्र जानकारी प्रकाशित करने के लिए DNSSEC का उपयोग करता है और उसे बाहरी प्रमाणपत्र प्राधिकारियों पर विश्वास की आवश्यकता नहीं होती है, जो कि अधिक सुरक्षित है। लेकिन कई वर्षों के उपयोग के आंकड़ों के आधार पर, DNSSEC का उपयोग अक्सर तकनीकी विफलताओं का कारण बनता है (हालांकि DNSSEC की विश्वसनीयता और इसके तकनीकी समर्थन में आम तौर पर सकारात्मक रुझान है)। प्राप्तकर्ता पक्ष पर SMTP में DANE को लागू करने के लिए, DNS ज़ोन के लिए DNSSEC की उपस्थिति अनिवार्य है, और DANE के लिए NSEC/NSEC3 के लिए सही समर्थन आवश्यक है, जिसके साथ DNSSEC में प्रणालीगत समस्याएं हैं।

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

डेन और एमटीए-एसटीएस एक-दूसरे के साथ टकराव नहीं करते हैं और इन्हें एक साथ इस्तेमाल किया जा सकता है।

Mail.ru मेल में MTA-STS समर्थन क्या है?

Mail.ru काफी समय से सभी प्रमुख डोमेन के लिए MTA-STS नीति प्रकाशित कर रहा है। हम वर्तमान में मानक के ग्राहक भाग को कार्यान्वित कर रहे हैं। लेखन के समय, नीतियों को गैर-अवरुद्ध मोड में लागू किया जाता है (यदि वितरण किसी नीति द्वारा अवरुद्ध किया जाता है, तो पत्र नीतियों को लागू किए बिना "अतिरिक्त" सर्वर के माध्यम से वितरित किया जाएगा), फिर अवरुद्ध मोड को एक छोटे से हिस्से के लिए मजबूर किया जाएगा आउटगोइंग एसएमटीपी ट्रैफ़िक के लिए, धीरे-धीरे 100% ट्रैफ़िक के लिए नीतियों का प्रवर्तन समर्थित होगा।

और कौन मानक का समर्थन करता है?

अब तक, एमटीए-एसटीएस नीतियां लगभग 0.05% सक्रिय डोमेन प्रकाशित करती हैं, लेकिन, फिर भी, वे पहले से ही बड़ी मात्रा में मेल ट्रैफ़िक की रक्षा करती हैं, क्योंकि मानक प्रमुख खिलाड़ियों - Google, Comcast और आंशिक रूप से Verizon (AOL, Yahoo) द्वारा समर्थित है। कई अन्य डाक सेवाओं ने घोषणा की है कि मानक के लिए समर्थन निकट भविष्य में लागू किया जाएगा।

इसका मुझ पर क्या प्रभाव पड़ेगा?

तब तक नहीं जब तक आपका डोमेन एमटीए-एसटीएस नीति प्रकाशित नहीं करता। यदि आप नीति प्रकाशित करते हैं, तो आपके मेल सर्वर के उपयोगकर्ताओं के ईमेल अवरोधन से बेहतर रूप से सुरक्षित रहेंगे।

मैं एमटीए-एसटीएस कैसे लागू करूं?

प्राप्तकर्ता पक्ष पर एमटीए-एसटीएस समर्थन

यह नीति को HTTPS और DNS में रिकॉर्ड के माध्यम से प्रकाशित करने के लिए पर्याप्त है, MTA में STARTTLS के लिए किसी विश्वसनीय CA (आइए एन्क्रिप्ट करना संभव है) में से एक वैध प्रमाणपत्र कॉन्फ़िगर करें (STARTTLS सभी आधुनिक MTA में समर्थित है), से कोई विशेष समर्थन नहीं एमटीए आवश्यक है.

चरण दर चरण, यह इस प्रकार दिखता है:

1. आप जिस एमटीए का उपयोग कर रहे हैं उसमें STARTTLS कॉन्फ़िगर करें (पोस्टफ़िक्स, एक्ज़िम, सेंडमेल, माइक्रोसॉफ्ट एक्सचेंज, आदि)।
2. सुनिश्चित करें कि आप एक वैध प्रमाणपत्र का उपयोग कर रहे हैं (विश्वसनीय सीए द्वारा जारी किया गया, समाप्त नहीं हुआ है, प्रमाणपत्र का विषय एमएक्स रिकॉर्ड से मेल खाता है जो आपके डोमेन के लिए मेल वितरित करता है)।
3. एक टीएलएस-आरपीटी रिकॉर्ड कॉन्फ़िगर करें जिसके माध्यम से नीति आवेदन रिपोर्ट वितरित की जाएंगी (उन सेवाओं द्वारा जो टीएलएस रिपोर्ट भेजने का समर्थन करती हैं)। उदाहरण प्रविष्टि (example.com डोमेन के लिए):

   smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»

   यह प्रविष्टि मेल प्रेषकों को एसएमटीपी में टीएलएस उपयोग पर सांख्यिकीय रिपोर्ट भेजने का निर्देश देती है [email protected].

   यह सुनिश्चित करने के लिए कि कोई त्रुटि न हो, कई दिनों तक रिपोर्ट की निगरानी करें।

4. HTTPS पर MTA-STS नीति प्रकाशित करें। नीति को स्थान के अनुसार सीआरएलएफ लाइन टर्मिनेटर के साथ एक टेक्स्ट फ़ाइल के रूप में प्रकाशित किया जाता है।

   https://mta-sts.example.com/.well-known/mta-sts.txt
   

   उदाहरण नीति:

   version: STSv1
   mode: enforce
   mx: mxs.mail.ru
   mx: emx.mail.ru
   mx: mx2.corp.mail.ru
   max_age: 86400
   

   संस्करण फ़ील्ड में नीति का संस्करण (वर्तमान में) शामिल है STSv1), मोड नीति अनुप्रयोग मोड, परीक्षण - परीक्षण मोड (नीति लागू नहीं होती है), लागू - "मुकाबला" मोड सेट करता है। सबसे पहले नीति को mode:testing के साथ प्रकाशित करें, यदि परीक्षण मोड में नीति के साथ कोई समस्या नहीं है, तो थोड़ी देर बाद आप mode:enforce पर स्विच कर सकते हैं।

   एमएक्स में, उन सभी मेल सर्वरों की एक सूची निर्दिष्ट की गई है जो आपके डोमेन के लिए मेल स्वीकार कर सकते हैं (प्रत्येक सर्वर के पास एक प्रमाणपत्र कॉन्फ़िगर होना चाहिए जो एमएक्स में निर्दिष्ट नाम से मेल खाता हो)। Max_age पॉलिसी के कैशिंग समय को निर्दिष्ट करता है (एक बार याद की गई पॉलिसी लागू हो जाएगी, भले ही हमलावर इसकी डिलीवरी को अवरुद्ध कर दे या कैशिंग समय के दौरान DNS रिकॉर्ड को दूषित कर दे, आप mta-sts DNS को बदलकर पॉलिसी को फिर से अनुरोध करने की आवश्यकता का संकेत दे सकते हैं अभिलेख)।

5. DNS में TXT रिकॉर्ड प्रकाशित करें: 

   _mta-sts.example.com. TXT “v=STS1; id=someid;”
   

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

प्रेषक पक्ष पर एमटीए-एसटीएस समर्थन

अब तक यह उसके साथ बुरा है, क्योंकि... ताज़ा मानक.

• एक्ज़िम - कोई अंतर्निहित समर्थन नहीं, एक तृतीय-पक्ष स्क्रिप्ट है https://github.com/Bobberty/MTASTS-EXIM-PERL 
• पोस्टफ़िक्स - कोई अंतर्निहित समर्थन नहीं है, एक तृतीय-पक्ष स्क्रिप्ट है जिसका वर्णन हैबे पर विस्तार से किया गया है https://habr.com/en/post/424961/

"अनिवार्य टीएलएस" के बारे में एक उपसंहार के रूप में

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

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

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

स्रोत: www.habr.com