थोडक्यात, एमटीए-एसटीएस हा मेल सर्व्हर दरम्यान प्रसारित केल्यावर इंटरसेप्शनपासून (म्हणजे, मॅन-इन-द-मिडल अटॅक उर्फ ​​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 ला सपोर्ट करत असेल, तर तो फक्त TLS कनेक्शनवर ईमेल पाठवेल, फक्त पॉलिसीद्वारे परिभाषित केलेल्या सर्व्हरला आणि फक्त सर्व्हरच्या प्रमाणपत्राच्या पडताळणीसह.

अर्धवट का? MTA-STS केवळ तेव्हाच कार्य करते जेव्हा दोन्ही पक्षांनी हे मानक लागू करण्याची काळजी घेतली असेल आणि MTA-STS अशा परिस्थितींपासून संरक्षण करत नाही ज्यामध्ये आक्रमणकर्ता सार्वजनिक CA पैकी एकाकडून वैध डोमेन प्रमाणपत्र प्राप्त करण्यास सक्षम असेल.

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 ला SMTP (RFC 7672) च्या प्रतिस्पर्धी DANE मानकापेक्षा कमी सुरक्षित करतात, परंतु तांत्रिकदृष्ट्या अधिक विश्वासार्ह, उदा. एमटीए-एसटीएससाठी मानकांच्या अंमलबजावणीमुळे उद्भवलेल्या तांत्रिक समस्यांमुळे पत्र वितरित केले जाणार नाही अशी शक्यता कमी आहे.

स्पर्धात्मक मानक - 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 धोरण प्रकाशित करत आहे. आम्ही सध्या मानकाचा क्लायंट भाग लागू करत आहोत. लेखनाच्या वेळी, धोरणे नॉन-ब्लॉकिंग मोडमध्ये लागू केली जातात (जर पॉलिसीद्वारे डिलिव्हरी अवरोधित केली गेली असेल, तर पॉलिसी लागू न करता पत्र "स्पेअर" सर्व्हरद्वारे वितरित केले जाईल), नंतर ब्लॉकिंग मोड लहान भागासाठी सक्ती केली जाईल. आउटगोइंग एसएमटीपी ट्रॅफिक, हळूहळू १००% ट्रॅफिकसाठी ते धोरणांची अंमलबजावणी समर्थित असेल.

इतर कोण मानक समर्थन करते?

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

याचा माझ्यावर कसा परिणाम होईल?

तुमच्या डोमेनने MTA-STS धोरण प्रकाशित केल्याशिवाय नाही. तुम्ही धोरण प्रकाशित केल्यास, तुमच्या मेल सर्व्हरच्या वापरकर्त्यांसाठीचे ईमेल व्यत्यय येण्यापासून अधिक चांगले संरक्षित केले जातील.

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

प्राप्तकर्त्याच्या बाजूने MTA-STS समर्थन

HTTPS द्वारे धोरण प्रकाशित करणे आणि DNS मध्ये रेकॉर्ड करणे, MTA मधील STARTTLS (सर्व आधुनिक MTAs मध्ये STARTTLS समर्थित आहे) साठी विश्वसनीय CAs (चला कूटबद्ध करणे शक्य आहे) कडून वैध प्रमाणपत्र कॉन्फिगर करणे पुरेसे आहे, कडून विशेष समर्थन नाही 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), मोड पॉलिसी ऍप्लिकेशन मोड, चाचणी — चाचणी मोड (धोरण लागू केलेले नाही), अंमलबजावणी — “लढाऊ” मोड सेट करते. प्रथम पॉलिसी मोडसह प्रकाशित करा: चाचणी, चाचणी मोडमध्ये पॉलिसीमध्ये कोणतीही समस्या नसल्यास, थोड्या वेळाने तुम्ही मोडवर स्विच करू शकता: enforce.

   mx मध्ये, तुमच्या डोमेनसाठी मेल स्वीकारू शकणार्‍या सर्व मेल सर्व्हरची सूची निर्दिष्ट केली आहे (प्रत्येक सर्व्हरकडे mx मध्ये निर्दिष्ट केलेल्या नावाशी जुळणारे प्रमाणपत्र कॉन्फिगर केलेले असणे आवश्यक आहे). Max_age पॉलिसीची कॅशिंग वेळ निर्दिष्ट करते (एकदा लक्षात ठेवलेली पॉलिसी लागू केली जाईल जरी आक्रमणकर्त्याने त्याचे वितरण अवरोधित केले किंवा कॅशिंग वेळेदरम्यान DNS रेकॉर्ड खराब केले तरीही, तुम्ही mta-sts DNS बदलून पुन्हा पॉलिसीची विनंती करण्याची आवश्यकता दर्शवू शकता. विक्रम).

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

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

   एक अनियंत्रित अभिज्ञापक (उदाहरणार्थ, एक टाइमस्टॅम्प) आयडी फील्डमध्ये वापरला जाऊ शकतो; जेव्हा धोरण बदलते तेव्हा ते बदलले पाहिजे, हे प्रेषकांना हे समजण्यास अनुमती देते की त्यांना कॅशे केलेल्या धोरणाची पुन्हा विनंती करणे आवश्यक आहे (जर आयडेंटिफायर पेक्षा वेगळा असेल तर कॅशे केलेले एक).

प्रेषकाच्या बाजूने 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 किंवा त्याच्या आंशिक अॅनालॉगला सर्वात योग्य यंत्रणा म्हणून विचारात घेण्याची शिफारस करतो, ते प्रत्येक डोमेनसाठी स्वतंत्रपणे सुरक्षित सेटिंग्ज करण्याची आवश्यकता काढून टाकते. जर तुम्हाला एमटीए-एसटीएसच्या क्लायंट भागाची अंमलबजावणी करण्यात अडचण येत असेल (प्रोटोकॉलला व्यापक समर्थन मिळेपर्यंत, ते बहुधा येतील), आम्ही या पद्धतीची शिफारस करू शकतो:

1. MTA-STS धोरण आणि/किंवा DANE रेकॉर्ड प्रकाशित करा (DNSSEC आधीपासून तुमच्या डोमेनसाठी आणि MTA-STS कोणत्याही परिस्थितीत सक्षम असेल तरच DANE ला अर्थ प्राप्त होतो), हे तुमच्या दिशेने ट्रॅफिकचे संरक्षण करेल आणि इतर मेल सेवांना विचारण्याची गरज दूर करेल. जर मेल सेवा आधीच MTA-STS आणि/किंवा DANE ला सपोर्ट करत असेल तर तुमच्या डोमेनसाठी अनिवार्य TLS कॉन्फिगर करण्यासाठी.
2. मोठ्या ईमेल सेवांसाठी, प्रत्येक डोमेनसाठी स्वतंत्र वाहतूक सेटिंग्जद्वारे MTA-STS चे “अॅनालॉग” लागू करा, जे मेल रिलेंगसाठी वापरलेले MX निश्चित करेल आणि त्यासाठी TLS प्रमाणपत्राची अनिवार्य पडताळणी आवश्यक असेल. जर डोमेनने आधीच MTA-STS धोरण प्रकाशित केले असेल, तर हे कदाचित वेदनारहित केले जाऊ शकते. स्वतःच, रिले निश्चित केल्याशिवाय आणि प्रमाणपत्राची पडताळणी न करता डोमेनसाठी अनिवार्य TLS सक्षम करणे सुरक्षिततेच्या दृष्टिकोनातून अप्रभावी आहे आणि विद्यमान STARTTLS यंत्रणांमध्ये काहीही जोडत नाही.

स्त्रोत: www.habr.com