प्रतिनिधि इंटरव्यू विषय

बैकएंड इंटरव्यू: आप TLS-RPT के साथ SMTP TLS विफलताओं का निदान कैसे करेंगे?

बैकएंडकठिन
Offer.cc संपादकीय टीमप्रकाशित अपडेट किया गया

प्रश्न

मल्टी-MX डोमेन पर MTA-STS सक्षम करने के बाद, कुछ प्रेषक TLS हैंडशेक विफल होने की रिपोर्ट करते हैं। आप निदान करने और सुरक्षित रूप से रोलबैक करने के लिए TLS-RPT का उपयोग कैसे करेंगे?

प्रश्न और परिदृश्य

आप कई प्रदाताओं में फैले एक मल्टी-MX प्राप्तकर्ता डोमेन का संचालन करते हैं। MTA-STS सक्षम करने के बाद, कुछ प्रेषक TLS हैंडशेक विफलताओं की रिपोर्ट करते हैं। बताएं कि आप समाधान को देखने, निदान करने और सुरक्षित रूप से रोल आउट करने के लिए SMTP TLS Reporting (TLS-RPT) का उपयोग कैसे करेंगे।

साक्षात्कारकर्ता क्या जांच रहा है

  • टेलीमेट्री (TLS-RPT) और प्रवर्तन (MTA-STS और DANE) के बीच अंतर करना।
  • DNS, प्रमाणपत्र, STARTTLS, HTTPS पॉलिसी फाइलें और बैकअप MX पथों को जोड़ना।
  • डिलीवरेबिलिटी की सुरक्षा के लिए चरणबद्ध रोलआउट, मेट्रिक्स, अलर्ट और रोलबैक का उपयोग करना।

उत्तर देने से पहले स्पष्ट करने वाले प्रश्न

डोमेन के MX सेट की पुष्टि करें, क्या MTA-STS या DANE सक्षम है, TLS-RPT गंतव्य, रिपोर्ट विंडो, और क्या विफलताएं वैश्विक हैं या किसी एक प्रेषक या बैकअप MX में केंद्रित हैं। स्पष्ट करें कि क्या लक्ष्य प्लेनटेक्स्ट डाउनग्रेड का पता लगाना है, डिलीवरी विफलताओं की व्याख्या करना है, या किसी प्रवर्तन रोलआउट को मान्य करना है।

30-सेकंड का उत्तर ढांचा

RFC 8460 द्वारा परिभाषित TLS-RPT, टेलीमेट्री है; यह एन्क्रिप्शन लागू नहीं करता है। मैं एक _smtp._tls TXT रिकॉर्ड प्रकाशित करूंगा, समग्र रिपोर्ट एकत्र करूंगा, और पॉलिसी, प्रेषक, MX और कारण के आधार पर विफलताओं को समूहीकृत करूंगा। फिर मैं प्रत्येक MX के लिए STARTTLS, प्रमाणपत्र पहचान और श्रृंखला, DNS और MTA-STS HTTPS फ़ाइल को मान्य करूंगा। समस्याओं को ठीक करने के बाद, मैं लागू (enforce) करने से पहले testing मोड में निगरानी करूंगा और एक परीक्षण किए गए रोलबैक पथ को बनाए रखूंगा।

चरण-दर-चरण विस्तृत उत्तर

  1. v=TLSRPTv1; rua=mailto:tls-reports@example.org जैसा रिकॉर्ड प्रकाशित करें; गंतव्य को अधिकृत करें और पार्सिंग, प्रतिधारण (retention), और संपादन (redaction) को सत्यापित करें।
  2. पॉलिसी, भेजने वाले MTA, MX, सफलताओं और विफलता के कारणों के लिए RFC 8460 JSON एग्रीगेट्स को पार्स करें। केवल एक विफलता-दर संख्या पर निर्भर रहने के बजाय समय, प्रदाता और बैकअप MX द्वारा क्लस्टर करें।
  3. प्रत्येक MX के लिए, DNS, पोर्ट 25, STARTTLS, प्रमाणपत्र श्रृंखला और नाम सत्यापित करें। प्रेषक के अवलोकनों की तुलना मेल लॉग और एक स्पष्ट SMTP TLS जांच से करें।
  4. MTA-STS के लिए, _mta-sts, HTTPS /.well-known/mta-sts.txt फ़ाइल, इसके मोड, MX पैटर्न और कैशिंग की जांच करें। DANE के लिए, DNSSEC सत्यापन और प्रमाणपत्र के साथ TLSA संरेखण की जांच करें।
  5. enforce से पहले testing मोड में प्रत्येक MX, पुराने रिकॉर्ड और फेलओवर पथ का परीक्षण करें। बढ़ती विफलता दर या किसी महत्वपूर्ण प्रदाता/पथ पर अलर्ट सेट करें।
  6. प्रमाणपत्र, पॉलिसी फ़ाइलों, DNSSEC, या प्रदाता कॉन्फ़िगरेशन को ठीक करने के बाद उसी मैट्रिक्स के साथ पुनः परीक्षण करें। यदि डिलीवरी बाधित होती है, तो TLS-RPT संग्रह को बनाए रखते हुए MTA-STS मोड को कम करें या खराब पॉलिसी प्रविष्टि को हटा दें।
text
dig TXT _smtp._tls.example.org
dig TXT _mta-sts.example.org
curl https://mta-sts.example.org/.well-known/mta-sts.txt
openssl s_client -starttls smtp -connect mx1.example.org:25 -servername mx1.example.org

उच्च-गुणवत्ता वाला नमूना उत्तर

मैं TLS-RPT को टेलीमेट्री के रूप में मानता हूं, एन्क्रिप्शन स्विच के रूप में नहीं। सबसे पहले मैं _smtp._tls प्रकाशित करता हूं और रिपोर्ट को एक नियंत्रित गंतव्य पर भेजता हूं, फिर प्रेषक, लक्ष्य MX, पॉलिसी और विफलता के कारण के आधार पर एक बेसलाइन बनाता हूं। प्रत्येक रिपोर्ट किए गए पथ के लिए मैं STARTTLS, प्रमाणपत्र श्रृंखला और नाम, MTA-STS TXT और HTTPS पॉलिसी, या DANE DNSSEC/TLSA की जांच करता हूं; इसमें बैकअप MX और पुराने TTL शामिल हैं। सुधार के बाद मैं enforce करने से पहले एक पूरी रिपोर्ट विंडो और फेलओवर परीक्षण के माध्यम से testing मोड में रहता हूं। यदि डिलीवरी विफल हो जाती है, तो चुपचाप प्लेनटेक्स्ट स्वीकार करने के बजाय, रिपोर्ट बनाए रखते हुए मैं पॉलिसी मोड को वापस रोलबैक कर देता हूं। यह अवलोकन, मरम्मत और प्रवर्तन को प्रतिवर्ती (reversible) चरणों में अलग करता है।

सामान्य गलतियाँ

  • TLS-RPT को रिपोर्टिंग के बजाय TLS प्रवर्तन के रूप में मानना।
  • केवल प्राथमिक MX की जाँच करना और बैकअप, पुराने-DNS, या प्रदाता-विशिष्ट पथों को छोड़ देना।
  • प्रमाणपत्र समाप्ति की जांच करना लेकिन SAN, श्रृंखला, TLSA, या पॉलिसी फ़ाइल के mx पैटर्न की जांच न करना।
  • पूर्ण रिपोर्ट विंडो, थ्रेशोल्ड और रोलबैक के बिना enforce पर स्विच करना।
  • प्रेषक कवरेज और एंडपॉइंट प्राधिकरण की पुष्टि किए बिना कोई रिपोर्ट न होने को कोई विफलता न होना समझ लेना।

अनुवर्ती प्रश्न और प्रतिक्रियाएं

TLS-RPT और MTA-STS के बीच की सीमा क्या है?

TLS-RPT बातचीत के परिणामों के बारे में साक्ष्य एकत्र करता है। MTA-STS प्रेषकों को TLS को मान्य करने के लिए आवश्यक करने हेतु एक HTTPS पॉलिसी का उपयोग करता है। वे एक साथ काम करते हैं: रिपोर्टिंग एक प्रवर्तन रोलआउट को मान्य करती है।

एक रिपोर्ट में certificate-mismatch लिखा है। आप सबसे पहले क्या जांचते हैं?

रिपोर्ट किए गए MX के विरुद्ध हैंडशेक को पुन: प्रस्तुत करें, SAN, SNI, श्रृंखला और DNS का निरीक्षण करें, फिर जांचें कि क्या कोई लोड बैलेंसर या बैकअप नोड अभी भी पुराना प्रमाणपत्र प्रस्तुत कर रहा है।

DANE को DNSSEC पर विशेष ध्यान देने की आवश्यकता क्यों है?

TLSA विश्वास DNSSEC सत्यापन पर निर्भर करता है। प्रमाणपत्र रोटेशन को परमाणु रूप से (atomically) TLSA को अपडेट करना चाहिए; अन्यथा DANE-सक्षम प्रेषक कनेक्शन को अस्वीकार कर सकते हैं और विफलता की रिपोर्ट कर सकते हैं।

प्रवर्तन के बाद आप रोलबैक कैसे करते हैं?

संस्करणित DNS और पॉलिसी फाइलें रखें, MTA-STS को enforce से घटाकर testing करें या दोषपूर्ण प्रविष्टि को हटा दें, पुष्टि करें कि डिलीवरी और रिपोर्ट पुनर्प्राप्त हो गई हैं, फिर मूल कारण को ठीक करें जबकि TLS-RPT संग्रह जारी रहे।

सार्वजनिक स्रोत

संबंधित प्रश्न