SMTP सर्वर के लिए SSL प्रमाणपत्र में कौन सा होस्ट नाम होना चाहिए?

22

मेरे पास 192.0.2.1 पर एक सर्वर foo.example.com है

यह मेरे कई डोमेन के लिए ई-मेल प्राप्त करने के लिए एक्ज़िम चलाता है।

मेरे डोमेन में प्रत्येक में MX रिकॉर्ड है जो mx.example.com की ओर इशारा करता है, जो 192.0.2.1 तक हल होता है

अगर मैं आने वाले ई-मेल कनेक्शन के लिए टीएलएस एन्क्रिप्शन की पेशकश करना चाहता हूं, तो मुझे एसएसएल प्रमाणपत्र में कौन सा होस्ट नाम डालना चाहिए?

foo.example.com क्योंकि सर्वर हेलो में क्या कहेगा?
mx.example.com क्योंकि मेजबान नाम ग्राहकों से जुड़ा होगा?

http://www.checktls.com बताता है कि उत्तरार्द्ध सही है, लेकिन मुझे निश्चित उत्तर नहीं मिल रहा है।

— डेविड नॉर्थ
स्रोत

HTTP + SSL में आपको कई नाम आधारित वर्चुअल सर्वर की सेवा के लिए वाइल्डकार्ड प्रमाणपत्र (* .example.com) की आवश्यकता होगी। मुझे एसएमटीपी + एसएसएल के बारे में निश्चित नहीं है लेकिन मुझे संदेह है कि आप एक समान प्रतिबंध पाएंगे। HTTP के साथ इसके आस-पास का तरीका प्रत्येक वर्चुअल सर्वर को एक अलग IP से बाँधने और प्रत्येक के लिए एक अद्वितीय प्रमाण पत्र का उपयोग करने के लिए है।

— क्रिस नावा

1

एमएक्स सर्वर के लिए व्यावहारिक रूप से बोलना, यह कोई मायने नहीं रखता कि आपने अपना सामान्य नाम क्या निर्धारित किया है।

— cnst

18

यह वास्तव में कहीं भी स्पष्ट रूप से परिभाषित नहीं है, और सर्वर को "विश्वसनीय" होना चाहिए या नहीं यह क्लाइंट (जो निश्चित रूप से एक और मेल सर्वर हो सकता है) पर निर्भर करता है जो इसे कनेक्ट कर रहा है; प्रासंगिक RFC ( RFC 2487 ) से उद्धृत :

यदि SMTP क्लाइंट यह तय करता है कि प्रमाणीकरण या
गोपनीयता का स्तर जारी रखने के लिए पर्याप्त नहीं है, तो
वह TLS बातचीत पूरी होने के तुरंत बाद SMTP QUIT कमांड जारी करता है।
यदि SMTP सर्वर यह तय करता है कि प्रमाणीकरण या
गोपनीयता का स्तर जारी रखने के लिए पर्याप्त नहीं है, तो
वह ग्राहक से प्रत्येक SMTP कमांड (QUIT कमांड के अलावा)
से 554 रिप्लाई कोड (संभव टेक्स्ट जैसे ) के साथ उत्तर देगा। जैसा कि "
सुरक्षा की कमी के कारण कमांड ने इनकार कर दिया")।

टीएलएस वार्ता में दूसरे पक्ष की प्रामाणिकता पर विश्वास करने या न करने का निर्णय एक स्थानीय मामला है। हालाँकि,
निर्णय के लिए कुछ सामान्य नियम हैं:
- A SMTP client would probably only want to authenticate an SMTP
  server whose server certificate has a domain name that is the
  domain name that the client thought it was connecting to.

मूल रूप से इसका मतलब क्या है, जब सर्वर किसी दिए गए प्रमाण पत्र का उपयोग करके टीएलएस एन्क्रिप्शन प्रदान करता है, तो इसे स्वीकार करने या इनकार करने के बारे में निर्णय पूरी तरह से दूसरे भाग पर निर्भर करता है, जो संभवतः प्रमाण पत्र पर नाम उसी से जुड़ा होना चाहेगा जो इससे जुड़ा हो, लेकिन हो सकता है बहुत अच्छी तरह से इसे स्वीकार करते हैं, भले ही यह मेल न खाता हो।

लेकिन रुकिए, और भी है। उसी RFC से फिर से उद्धरण:

टीएलएस हैंडशेक के पूरा होने पर, एसएमटीपी प्रोटोकॉल
प्रारंभिक अवस्था (एसएमटीपी में सर्वर द्वारा 220
सेवा तैयार ग्रीटिंग जारी करने के बाद की स्थिति) पर रीसेट कर दिया जाता है । सर्वर
ग्राहक से प्राप्त किसी भी ज्ञान को त्याग देता है, जैसे कि EHLO कमांड का तर्क,
जो कि TLS की बातचीत से ही प्राप्त नहीं हुआ था। क्लाइंट
को सर्वर से प्राप्त किसी भी ज्ञान को त्यागना होगा, जैसे कि
एसएमटीपी सेवा विस्तार की सूची , जो टीएलएस
वार्ता से ही प्राप्त नहीं हुई थी । क्लाइंट SHOULD
एक सफल TLS वार्ता के बाद पहले कमांड के रूप में एक EHLO कमांड भेजता है ।

इसलिए, टीएलएस हैंडशेक से पहले सर्वर वास्तव में हेलो / ईएचएलओ के जवाब में क्या कह रहा है, वास्तव में कोई फर्क नहीं पड़ता।

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

— मास्सिमो
स्रोत

11

आपके डोमेन पर मेल पहुंचाने वाला एक एमटीए एमएक्स रिकॉर्ड (जो एक होस्टनाम प्राप्त करेगा) को देखने जा रहा है, और फिर उस होस्टनाम के लिए ए रिकॉर्ड की खोज करेगा। होस्टनाम जो इसे कनेक्ट कर रहा है, इसलिए MX होस्टनाम है, और इसी तरह SSL प्रमाणपत्र सामान्य नाम के खिलाफ सत्यापित किया जाएगा। हेलो होस्टनाम को सत्यापित करने का कोई मतलब नहीं है क्योंकि सर्वर किसी भी हेलो होस्टनाम को प्रदान कर सकता है जो वह चाहता है - यह अतिरिक्त सुरक्षा प्रदान नहीं करता है।

कहा कि मेल वितरित करते समय एसएसएल प्रमाणपत्रों की कड़ाई से पुष्टि करना इस समय विशेष रूप से उपयोगी नहीं है, क्योंकि एमटीए गैर-एसएसएल वितरण के लिए लगभग हमेशा की तरह कमबैक करेगा, क्योंकि इस समय एसएमटीपी कैसे काम करता है। समझदार कॉन्फ़िगरेशन इसलिए SSL का उपयोग करने के लिए है यदि MX सर्वर इसे प्रदान करता है, भले ही SSL प्रमाणपत्र सत्यापित हो या न हो (क्योंकि प्रमाणीकरण के बिना एन्क्रिप्शन कोई एन्क्रिप्शन और प्रमाणीकरण के बिना बेहतर है)। इसलिए आप इस उद्देश्य के लिए स्व-हस्ताक्षरित प्रमाणपत्र का उपयोग कर सकते हैं।

— mgorven
स्रोत

हां, और इस कारण से, यह वास्तव में आम बात नहीं है कि सामान्य नाम क्या सेट किया गया है, या क्या यह पहली बार में सेट किया गया है।

— cnst

7

सर्वर सर्टिफिकेट को सत्यापित करने का कार्य और जो सर्वर के होस्ट नाम से मेल खाता है, विशुद्ध रूप से क्लाइंट की भूमिका है, एसएसएल / टीएलएस का उपयोग कर किसी भी प्रोटोकॉल के लिए।

जैसे, प्रमाणपत्र में होस्ट नाम उस नाम से मेल खाना चाहिए जिसे क्लाइंट एक्सेस करने का प्रयास कर रहा है।

जब एसएसएल / टीएलएस कनेक्शन को सामने (एसएमटीपीएस) शुरू किया जाता है, तो सर्वर को यह देखने का कोई तरीका नहीं होता है कि कनेक्शन स्थापित होने से पहले हेलो संदेश क्या कहता है, इसलिए इसे उसी के साथ उपयोग करना चाहिए जिसके साथ उसने अनुरोध किया था।

SSL / TLS का उपयोग करने के बाद STARTTLS, क्लाइंट अभी भी उस सर्वर से बात करना चाहता है जिसके साथ इसे कॉन्फ़िगर किया गया था, इसलिए यह अभी भी वही है जो इसे जांचना चाहिए। असफल होना जो MITM के हमलों को संभव करेगा:

सी-> एस: हैलो, मैं एलिस हूं, मैं बॉब से बात करना चाहता हूं।
S-> C: नमस्ते, मैं चक हूँ, यहाँ चक के लिए मेरा प्रमाण पत्र है।
C-> S: ओह हां, आपका सर्टिफिकेट चक के लिए वास्तव में मान्य है। आगे बढ़ते हैं।
... बेशक एक दोष है, क्योंकि ऐलिस बॉब के साथ एक सुरक्षित संचार चाहता था।

दोनों ही मामलों में, यह MX पता है जिसका उपयोग किया जाना चाहिए।

होस्ट नाम मिलान नियम हाल ही में RFC 6125 में प्रोटोकॉल पर एकत्रित किए गए हैं , लेकिन कुछ ग्राहक इसे पूरी तरह से लागू करते हैं (यह एक पूर्ण परिवर्तन की तुलना में सबसे अच्छा अभ्यास RFC है, और यह अभी भी हाल ही में है)।

में अपने परिशिष्ट , यह एसएमटीपी के बारे में क्या पहले अस्तित्व (से लिया सारांशित करता आरएफसी 3207 और आरएफसी 4954 )। विशेष रूप से " क्लाइंट को असुरक्षित रिमोट स्रोत (जैसे असुरक्षित डीएनएस लुकअप) से प्राप्त सर्वर होस्टनाम के किसी भी रूप का उपयोग नहीं करना चाहिए। " (जो सर्वर के बैनर पर लागू होता है)। इसके अलावा, एसएमटीपी विरासत नियमों विषय के वैकल्पिक नाम (के बारे में HTTPS से थोड़ा अधिक आराम से थे चाहिए बजाय चाहिए इस्तेमाल किया जा)।

आधुनिक तरीका निश्चित रूप से होस्ट नाम को विषय वैकल्पिक नाम DNS प्रविष्टि में रखना है। वाइल्डकार्ड का उपयोग भी हतोत्साहित किया जाता है ।

— ब्रूनो
स्रोत

यह अच्छा होगा यदि मेल डोमेन के लिए प्रमाणित होगा - तो DNSSEC को अनिवार्य रूप से MITMs से बचने की आवश्यकता नहीं होगी।

— एंड्रियास क्रे

1

मुझे लगता है कि अभ्यास में जो किया जाता है, उसे कॉपी करना सबसे अच्छा होगा। मैंने http://checktls.com का उपयोग करके yahoo.com ईमेल पते की जाँच की है। उम्मीद है, याहू में, उन्होंने अपने hostname के लिए और अपने mx डोमेन के लिए एक अलग डोमेन का उपयोग किया है। तो, उनका hostname yahoo.com है और उनका mx डोमेन yahoodns.net के साथ समाप्त होता है

dig mx yahoo.com gives mta6.am0.yahoodns.net. among others

जाँच के परिणाम: SSL प्रमाणपत्र CN = MX डोमेन (* .yahoodns.net)

मैंने सिस्को के साथ भी ऐसा ही किया और मेरा भी यही नतीजा था।

— निकोलस गुएरनेट
स्रोत

0

एसएसएल / टीएलएस एन्क्रिप्शन में ग्राहक हमेशा दूरस्थ मशीन पर "वास्तविक" / "घोषित" होस्टनाम के बीच के पत्राचार की जांच करते हैं और प्रमाणपत्र में सर्टिफिकेट होते हैं।

तो, आपको शायद foo.example.com सेट करना चाहिए या वाइल्डकार्ड प्रमाणित करना होगा ;-)

— डॉ। मैं
स्रोत

2

मुझे नहीं लगता कि यह सही है।

— मोगरेवेन

मैं अपने उत्तर में सुधार करूंगा। अपने मेल सर्वर पर, यदि मैं अपने होस्ट सर्वर के बीच एक कॉन्सेप्ट रखना चाहता हूं, जिसका नाम उदाहरण है: mx1.dn.tld और एक अन्य सर्वर जिसका नाम उदाहरण है: foo.dn.tld यहां, मुझे होस्टनाम mb1 के साथ एक SSL सर्टिफिकेट जेनरेट करना है .dn.tld। अब, यदि आपके पास एक मेल सर्वर है जिसे आप बाहरी सेवाओं के उपयोग के लिए अन्य सेवाओं से एक्सेस करना चाहते हैं, उदाहरण के लिए IMAP, तो आप निम्न DNS उपनाम: imap.dn.tld सेट करेंगे जो एक आईपी या किसी अन्य होस्टनाम (mx1) से लिंक होता है। dn.tld उदाहरण के लिए)। और फिर इस imap.dn.tld hostname का उपयोग करके एक SSL प्रमाणपत्र प्राप्त करें।

— मैं

2

हां, लेकिन सवाल IMAP / POP3 एक्सेस के बारे में नहीं था, यह SMTP के साथ मेल डिलीवरी के बारे में था।

— प्रातः