ट्रांसपोर्ट एन्क्रिप्शन और S/MIME : हॉप सुरक्षा को संदेश सुरक्षा से अलग करें

ट्रांसपोर्ट TLS और S/MIME विभिन्न समस्याओं का समाधान करते हैं। TLS आसन्न प्रणालियों के बीच कनेक्शन की सुरक्षा करता है। S/MIME संदेश सामग्री पर हस्ताक्षर या एन्क्रिप्ट कर सकता है ताकि सुरक्षा संदेश के साथ प्रसारित हो। यह वास्तव में एंड-टू-एंड है या नहीं, यह इस बात पर निर्भर करता है कि कुंजियाँ कहाँ रखी गई हैं और हस्ताक्षर या डिक्रिप्शन कहाँ होता है, न कि केवल यह कि ईमेल क्लाइंट सुरक्षा आइकन प्रदर्शित करता है या नहीं।

नियंत्रण चुनने से पहले पथ बनाएं

सन्दर्भ: RFC 3207 §1, RFC 8551 §1.

ऐलिस के क्लाइंट से उसकी सबमिशन सेवा, फिर आउटबाउंड गेटवे, प्राप्तकर्ता की MX सेवा और बॉब के मेलबॉक्स और क्लाइंट के लिए एक संदेश का उपयोग करें। प्रत्येक नेटवर्क हॉप का अपना TLS कनेक्शन और नीति हो सकती है। एक सफल अंतर-डोमेन SMTP TLS कनेक्शन सबमिशन, आंतरिक रिले, मेलबॉक्स एक्सेस या स्टोरेज एन्क्रिप्शन के बारे में अपने आप में कुछ नहीं कहता है।

TLS को समाप्त करने वाले प्रत्येक सर्वर पर, सामान्य संदेश सामग्री प्रसंस्करण के लिए उपलब्ध होती है जब तक कि इसे अलग से एन्क्रिप्ट नहीं किया जाता है। इसलिए फ़िल्टर, गेटवे और समझौता किए गए समापन बिंदु गोपनीयता सीमा का हिस्सा बने रहते हैं। MTA-STS और SMTP DANE उनके लागू मार्गों के लिए परिवहन प्रमाणीकरण और प्रवर्तन में सुधार; न ही हॉप-बाय-हॉप TLS संदेश एन्क्रिप्शन में बदलता है। RFC 8461 अनुभाग 2.

हस्ताक्षर को एन्क्रिप्शन से अलग करें

सन्दर्भ: RFC 8551 §3.3, RFC 8551 §3.4, RFC 8551 §3.5, RFC 8551 §3.7, RFC 8551 §4.

S/MIME हस्ताक्षरित सामग्री प्रमाणपत्र विश्वास और सत्यापन के अनुसार अखंडता और हस्ताक्षरकर्ता-प्रमाणीकरण साक्ष्य प्रदान करती है। अकेले हस्ताक्षर करने से संदेश नहीं छिपता। S/MIME आच्छादित सामग्री उन प्राप्तकर्ताओं के लिए संरक्षित सामग्री को एन्क्रिप्ट करती है जिनकी कुंजियाँ इसे डिक्रिप्ट कर सकती हैं; अकेले एन्क्रिप्शन एक सत्यापित लेखक के हस्ताक्षर के बराबर नहीं है। जैसा कि RFC 8551 §3.4 बताता है, प्रमाणित लिफाफा सामग्री अतिरिक्त रूप से उत्पत्ति साबित किए बिना गोपनीयता और डेटा अखंडता प्रदान कर सकती है। उस सुरक्षा की तुलना सत्यापित लेखक के हस्ताक्षर से न करें। एक वर्कफ़्लो हस्ताक्षर और एन्क्रिप्शन को जोड़ सकता है। RFC 8551 अनुभाग 2 और 3.

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

एक ही संदेश पर खतरों की तुलना करें

सन्दर्भ: RFC 8551 §3.1, RFC 8551 §6.

उचित रूप से एन्क्रिप्टेड SMTP हॉप के निष्क्रिय अवलोकन के लिए, TLS उस हॉप पर प्रसारित बाइट्स की सुरक्षा करता है। TLS समाप्ति के बाद मेल पढ़ने वाले गेटवे व्यवस्थापक के लिए, हॉप एन्क्रिप्शन कोई सामग्री-गोपनीयता बाधा प्रदान नहीं करता है। क्लाइंट-साइड S/MIME एन्क्रिप्शन एन्क्रिप्टेड बॉडी को उस गेटवे से सुरक्षित कर सकता है यदि इसमें डिक्रिप्शन कुंजी नहीं है। यह शब्द महत्वपूर्ण हो सकता है क्योंकि कुछ परिनियोजन जानबूझकर गेटवे पर डिक्रिप्ट होते हैं।

परिवहन के बाद परिवर्तन के लिए, एक वैध S/MIME हस्ताक्षर हस्ताक्षरित सामग्री में परिवर्तन उजागर कर सकता है; तथ्य यह है कि पहले वाला TLS कनेक्शन सफल नहीं हो सका। एक समझौता प्राप्त प्राप्तकर्ता क्लाइंट के लिए जिसके पास डिक्रिप्शन कुंजी है, न तो TLS और न ही S/MIME एन्क्रिप्शन क्लाइंट को प्लेनटेक्स्ट तक पहुंचने से रोकता है। दृश्यमान रूटिंग मेटाडेटा और बाहरी हेडर के लिए, पूर्ण छुपाने का वादा न करें: कवरेज संदेश पैकेजिंग और कार्यान्वयन पर निर्भर करता है।

निजी समीक्षा साक्ष्य में इन सीमाओं का वर्णन करने वाला एक स्पष्ट पथ-और-खतरा मैट्रिक्स शामिल है। यह एक डिज़ाइन मॉडल है, क्रिप्टोग्राफ़िक इंटरऑपरेबिलिटी परीक्षण नहीं। स्थानीय TLSA पैकेज में कहीं और प्रमाणपत्र फिक्स्चर S/MIME हस्ताक्षर या डिक्रिप्शन व्यवहार स्थापित नहीं करते हैं।

नियंत्रण और स्वीकृति साक्ष्य एक साथ चुनें

सन्दर्भ: RFC 8551 §4, RFC 8551 §6.

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

रखना फ़िशिंग और व्यवसाय-प्रक्रिया के दावे अलग-अलग हैं। एक प्रमाणित प्रेषक या हस्ताक्षरित संदेश में अभी भी गलत या धोखाधड़ी वाला भुगतान अनुरोध हो सकता है, खासकर खाते से समझौता होने के बाद। परिणामी कार्रवाइयों का स्वतंत्र सत्यापन आवश्यक रहता है। इस गाइड के लिए कोई S/MIME संदेश हस्ताक्षरित, एन्क्रिप्टेड, डिलीवर या डिक्रिप्ट नहीं किया गया था; इसका प्रमाण निरीक्षण योग्य नियंत्रण-से-खतरे मैट्रिक्स है, और क्लाइंट इंटरऑपरेबिलिटी स्पष्ट रूप से लंबित स्वीकृति कार्य बनी हुई है।