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

MTA-STS ले के समस्या समाधान गर्छ?

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

एक प्रयोगकर्ताबाट अर्कोलाई पत्र पठाउने संयन्त्र कस्तो देखिन्छ:

ऐतिहासिक रूपमा, एक MitM आक्रमण सबै ठाउँहरूमा सम्भव थियो जहाँ मेल चल्छ।

RFC 8314 लाई मेल प्रयोगकर्ता अनुप्रयोग (MUA) र मेल सर्भर बीच TLS को प्रयोग आवश्यक छ। यदि तपाइँको सर्भर र तपाइँले प्रयोग गर्नुहुने मेल एप्लिकेसनहरू RFC 8314 सँग अनुरूप छन् भने, तपाइँले प्रयोगकर्ता र मेल सर्भरहरू बीचको म्यान-इन-द-मिडल आक्रमणहरूको सम्भावनालाई (ठूलो रूपमा) हटाउनुभएको छ।

सामान्यतया स्वीकृत अभ्यासहरू (RFC 8314 द्वारा मानकीकृत) पछ्याउँदा प्रयोगकर्ताको नजिकको आक्रमण हटाउँछ:

Mail.ru मेल सर्भरहरूले मानक अपनाइनु अघि नै RFC 8314 को पालना गर्‍यो; वास्तवमा, यसले पहिले नै स्वीकार गरिएका अभ्यासहरू मात्र कब्जा गर्छ, र हामीले थप केही कन्फिगर गर्नुपर्दैन। तर, यदि तपाईंको मेल सर्भरले अझै पनि प्रयोगकर्ताहरूलाई असुरक्षित प्रोटोकलहरू प्रयोग गर्न अनुमति दिन्छ भने, यो मानकका सिफारिसहरू लागू गर्न निश्चित हुनुहोस्, किनभने सम्भवतः, कम्तिमा तपाइँका केहि प्रयोगकर्ताहरूले ईन्क्रिप्शन बिना मेलसँग काम गर्छन्, यदि तपाइँ यसलाई समर्थन गर्नुहुन्छ भने।

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

MTA-STS ले मेल सर्भरहरू बीचको अक्षरहरू अवरोध गर्ने समस्यालाई आंशिक रूपमा हटाउँछ, जब आक्रमणकर्तासँग ट्राफिकलाई सक्रिय रूपमा प्रभाव पार्ने क्षमता हुन्छ। यदि प्रापकको डोमेनले MTA-STS नीति प्रकाशित गर्छ र प्रेषकको सर्भरले MTA-STS लाई समर्थन गर्छ भने, यसले TLS जडानमा मात्र इमेल पठाउनेछ, नीतिद्वारा परिभाषित सर्भरहरूमा मात्र, र सर्भरको प्रमाणपत्रको प्रमाणीकरणको साथमा।

किन आंशिक रूपमा? MTA-STS ले मात्र काम गर्दछ यदि दुबै पक्षहरूले यो मानक लागू गर्न ध्यान दिएका छन्, र MTA-STS ले कुनै आक्रमणकारीले सार्वजनिक CAs मध्ये कुनै एकबाट वैध डोमेन प्रमाणपत्र प्राप्त गर्न सक्ने परिदृश्यहरू विरुद्ध सुरक्षा गर्दैन।

MTA-STS कसरी काम गर्दछ

प्रापक

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

प्रेषक

प्रेषकले _mta-sts DNS रेकर्ड अनुरोध गर्दछ, र यदि यो उपलब्ध छ भने, HTTPS मार्फत नीति अनुरोध गर्दछ (प्रमाणपत्र जाँच गर्दै)। नतिजा नीति क्यास गरिएको छ (यदि कुनै आक्रमणकारीले यसमा पहुँच रोक्छ वा DNS रेकर्डलाई स्पूफ गर्दछ)।

मेल पठाउँदा, यो जाँच गरिन्छ कि:

• सर्भर जसमा मेल डेलिभर हुन्छ नीतिमा छ;
• सर्भरले TLS (STARTTLS) प्रयोग गरेर मेल स्वीकार गर्दछ र एक मान्य प्रमाणपत्र छ।

MTA-STS का फाइदाहरू

MTA-STS ले प्राविधिकहरू प्रयोग गर्दछ जुन पहिले नै धेरै संस्थाहरूमा लागू गरिएको छ (SMTP+STARTTLS, HTTPS, DNS)। प्रापक पक्षमा कार्यान्वयनको लागि, मानकको लागि कुनै विशेष सफ्टवेयर समर्थन आवश्यक पर्दैन।

MTA-STS का बेफाइदाहरू

वेब र मेल सर्भर प्रमाणपत्रको वैधता, नामहरूको पत्राचार, र समयमै नवीकरणको अनुगमन गर्न आवश्यक छ। प्रमाणपत्रको साथ समस्याहरू मेल डेलिभर गर्न असक्षम हुने परिणाम हुनेछ।

प्रेषक पक्षमा, MTA-STS नीतिहरूको लागि समर्थन भएको MTA आवश्यक छ; हाल, MTA-STS MTA मा बाकस बाहिर समर्थित छैन।

MTA-STS ले विश्वसनीय रूट CA को सूची प्रयोग गर्दछ।

MTA-STS ले आक्रमणबाट सुरक्षा गर्दैन जसमा आक्रमणकारीले मान्य प्रमाणपत्र प्रयोग गर्दछ। धेरै जसो अवस्थामा, सर्भरको नजिक MitM ले प्रमाणपत्र जारी गर्ने क्षमतालाई संकेत गर्दछ। प्रमाणपत्र पारदर्शिता प्रयोग गरेर यस्तो आक्रमण पत्ता लगाउन सकिन्छ। त्यसकारण, सामान्यतया, MTA-STS ले ट्राफिक अवरोधको सम्भावनालाई कम गर्छ, तर पूर्ण रूपमा हटाउन सक्दैन।

अन्तिम दुई बिन्दुहरूले MTA-STS लाई SMTP (RFC 7672) को लागि प्रतिस्पर्धी DANE मानक भन्दा कम सुरक्षित बनाउँदछ, तर अधिक प्राविधिक रूपमा भरपर्दो, अर्थात्। MTA-STS को लागि मानकको कार्यान्वयनको कारणले गर्दा प्राविधिक समस्याहरूको कारण पत्र डेलिभर हुने सम्भावना कम छ।

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

DANE ले प्रमाणपत्र जानकारी प्रकाशित गर्न DNSSEC प्रयोग गर्दछ र बाह्य प्रमाणपत्र अधिकारीहरूमा विश्वास आवश्यक पर्दैन, जुन धेरै सुरक्षित छ। तर DNSSEC को प्रयोगले धेरै वर्षको प्रयोगको तथ्याङ्कको आधारमा प्राविधिक विफलताहरू निम्त्याउँछ (यद्यपि त्यहाँ सामान्यतया DNSSEC र यसको प्राविधिक समर्थनको विश्वसनीयतामा सकारात्मक प्रवृत्ति छ)। प्रापक पक्षमा SMTP मा DANE लागू गर्न, DNS क्षेत्रको लागि DNSSEC को उपस्थिति अनिवार्य छ, र NSEC/NSEC3 को लागि सही समर्थन DANE को लागि आवश्यक छ, जसमा DNSSEC मा प्रणालीगत समस्याहरू छन्।

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

DANE र MTA-STS एकअर्कासँग विवाद गर्दैनन् र सँगै प्रयोग गर्न सकिन्छ।

Mail.ru मेलमा MTA-STS समर्थनको साथ के छ?

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

अरू कसले मापदण्डलाई समर्थन गर्छ?

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

यसले मलाई कसरी असर गर्नेछ?

तपाईको डोमेनले MTA-STS नीति प्रकाशित नगरेसम्म होइन। यदि तपाईंले नीति प्रकाशित गर्नुभयो भने, तपाईंको मेल सर्भरका प्रयोगकर्ताहरूका लागि इमेलहरू अवरोधबाट राम्रोसँग सुरक्षित हुनेछन्।

मैले MTA-STS कसरी लागू गर्ने?

प्राप्तकर्ता पक्षमा MTA-STS समर्थन

HTTPS मार्फत नीति प्रकाशित गर्न र DNS मा रेकर्डहरू, MTA मा STARTTLS (सबै आधुनिक MTAs मा STARTTLS समर्थित छ) को लागि विश्वसनीय CA बाट वैध प्रमाणपत्र कन्फिगर गर्न पर्याप्त छ (इन्क्रिप्ट गर्न सम्भव छ), कुनै विशेष समर्थन छैन। MTA आवश्यक छ।

चरण द्वारा, यो यस्तो देखिन्छ:

1. तपाईंले प्रयोग गरिरहनुभएको MTA मा STARTTLS कन्फिगर गर्नुहोस् (पोस्टफिक्स, एक्जिम, सेन्डमेल, माइक्रोसफ्ट एक्सचेन्ज, आदि)।
2. निश्चित गर्नुहोस् कि तपाइँ एक मान्य प्रमाणपत्र प्रयोग गर्दै हुनुहुन्छ (विश्वसनीय CA द्वारा जारी गरिएको, म्याद सकिएको छैन, प्रमाणपत्रको विषय MX रेकर्डसँग मेल खान्छ जसले तपाइँको डोमेनको लागि मेल डेलिभर गर्दछ)।
3. TLS-RPT रेकर्ड कन्फिगर गर्नुहोस् जसको माध्यमबाट नीति आवेदन रिपोर्टहरू डेलिभर गरिनेछ (TLS रिपोर्टहरू पठाउन समर्थन गर्ने सेवाहरूद्वारा)। उदाहरण प्रविष्टि (example.com डोमेनको लागि):

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

   यो प्रविष्टिले मेल प्रेषकहरूलाई SMTP मा TLS प्रयोगमा तथ्याङ्कीय रिपोर्टहरू पठाउन निर्देशन दिन्छ [email protected].

   कुनै त्रुटि छैन भनेर सुनिश्चित गर्न धेरै दिनको लागि रिपोर्टहरू निगरानी गर्नुहोस्।

4. HTTPS मा MTA-STS नीति प्रकाशित गर्नुहोस्। नीतिलाई स्थान अनुसार CRLF लाइन टर्मिनेटरहरूसँग पाठ फाइलको रूपमा प्रकाशित गरिएको छ।

   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), मोडले नीति अनुप्रयोग मोड सेट गर्छ, परीक्षण — परीक्षण मोड (नीति लागू गरिएको छैन), लागू — “लडाई” मोड। पहिले मोड: परीक्षणको साथ नीति प्रकाशित गर्नुहोस्, यदि परीक्षण मोडमा नीतिसँग कुनै समस्या छैन भने, केही समय पछि तपाईं मोडमा स्विच गर्न सक्नुहुन्छ: लागू गर्नुहोस्।

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

5. DNS मा TXT रेकर्ड प्रकाशित गर्नुहोस्: 

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

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

प्रेषक पक्षमा MTA-STS समर्थन

अहिलेसम्म यो उनको साथ खराब छ, किनभने ... ताजा मानक।

• एक्जिम - कुनै बिल्ट-इन समर्थन छैन, त्यहाँ तेस्रो-पक्ष लिपि छ https://github.com/Bobberty/MTASTS-EXIM-PERL 
• पोस्टफिक्स - त्यहाँ कुनै बिल्ट-इन समर्थन छैन, त्यहाँ तेस्रो-पक्ष लिपि हो जुन Habré मा विस्तृत रूपमा वर्णन गरिएको छ। https://habr.com/en/post/424961/

"अनिवार्य TLS" को बारेमा पछिको शब्दको रूपमा

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

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

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

स्रोत: www.habr.com