हस्ताक्षरित संदेश भी स्पैम हो सकता है। उसका साइनिंग डोमेन प्राप्तकर्ता को दिखने वाले पते से अलग भी हो सकता है।
DKIM हस्ताक्षर किन चीज़ों को कवर करता है?
DKIM हस्ताक्षर चुने गए हेडर फ़ील्ड और बॉडी के हैश को सुरक्षित करता है।
h= टैग हस्ताक्षरित हेडर फ़ील्ड की सूची देता है। bh= टैग में बॉडी हैश होता है। भेजने वाला सर्वर अपनी निजी कुंजी से हस्ताक्षर बनाता है। प्राप्तकर्ता संबंधित सार्वजनिक कुंजी से उसका सत्यापन करते हैं।
प्राप्तकर्ता बॉडी हैश की दोबारा गणना करता है। वह चुने गए हेडर और हस्ताक्षर हेडर पर बने हस्ताक्षर का सत्यापन भी करता है, जिसमें वही हैश होता है।
RFC 6376 के अनुसार From हेडर पर हस्ताक्षर करना ज़रूरी है। बाकी हेडर फ़ील्ड बिना हस्ताक्षर के रह सकते हैं। इसलिए बिना हस्ताक्षर वाला Reply-To जोड़ने पर भी DKIM मान्य रह सकता है।
दोहराए गए हेडर को अलग से संभालना पड़ता है। हस्ताक्षरकर्ता किसी हेडर नाम को उसकी वास्तविक संख्या से ज़्यादा बार सूची में डाल सकता है, ताकि कोई और प्रति बिना पकड़े जोड़ी न जा सके।
प्राप्तकर्ता को सार्वजनिक कुंजी कहाँ मिलती है?
प्राप्तकर्ता हस्ताक्षर करने वाले डोमेन और सेलेक्टर से सार्वजनिक कुंजी ढूँढता है। सेलेक्टर वह नाम है जो उस कुंजी की पहचान करता है। d= टैग डोमेन बताता है। s= टैग सेलेक्टर बताता है।
d=example.com और s=foo.bar के लिए लुकअप नाम foo.bar._domainkey.example.com होता है। सेलेक्टर की मदद से एक ही हस्ताक्षर डोमेन के तहत अलग-अलग कुंजियाँ रखी जा सकती हैं।
कुंजी बदलते समय, नई कुंजी से हस्ताक्षर करने से पहले उसे प्रकाशित करें। जब तक पुरानी कुंजी से हस्ताक्षरित संदेश रास्ते में हैं, तब तक पुरानी सत्यापन कुंजी उपलब्ध रखें। उसे समय से पहले हटाने पर प्राप्तकर्ता उन संदेशों का सत्यापन नहीं कर पाते।
फ़ॉर्मैटिंग में बदलाव से हस्ताक्षर क्यों टूट सकता है?
कैनोनिकलाइज़ेशन, यानी हस्ताक्षर और सत्यापन से पहले लागू होने वाला नॉर्मलाइज़ेशन, तय करता है कि DKIM फ़ॉर्मैटिंग के कौन-से बदलाव सहन करता है।
c= टैग हेडर और बॉडी के लिए अलग-अलग एल्गोरिदम चुनता है। relaxed/relaxed में दोनों रिलैक्स्ड नॉर्मलाइज़ेशन का उपयोग करते हैं।
| एल्गोरिदम | हेडर पर व्यवहार | बॉडी पर व्यवहार |
|---|---|---|
simple | हेडर की फ़ॉर्मैटिंग को जस का तस रखता है | अंत की खाली पंक्तियों को अनदेखा करता है |
relaxed | हेडर नाम के अक्षर-केस, फ़ोल्डिंग और व्हाइटस्पेस को नॉर्मलाइज़ करता है | व्हाइटस्पेस और अंत की खाली पंक्तियों को नॉर्मलाइज़ करता है |
फ़ोल्ड किया गया हेडर अगली पंक्ति में जारी रहता है। रिलैक्स्ड हेडर प्रोसेसिंग इस फ़ोल्डिंग को सहन कर लेती है। जब कोई सर्वर उसी हेडर को दोबारा फ़ोल्ड करता है, तो सिंपल प्रोसेसिंग विफल हो सकती है।
विफल होने वाले रिले से पहले और बाद के साइन किए गए कंटेंट की तुलना करें, क्योंकि फ़ॉर्मैटिंग में कोई अदृश्य बदलाव इस परिणाम का कारण हो सकता है।
DKIM किन साइनिंग एल्गोरिदम को सपोर्ट करता है?
DKIM RSA और Ed25519 साइनिंग एल्गोरिदम को सपोर्ट करता है, और दोनों SHA-256 के साथ इस्तेमाल होते हैं।
RFC 8301 के अनुसार RSA कुंजी का न्यूनतम आकार 1024 बिट है। इससे छोटी कुंजियाँ कुंजी के उजागर होने से पर्याप्त सुरक्षा नहीं देतीं।
RSA का अनुशंसित आकार कम से कम 2048 बिट है, जो कुंजी के उजागर होने से ज़्यादा सुरक्षा देता है। अगर आपका साइनिंग सिस्टम इसे सपोर्ट करता है, तो यही आकार चुनें। स्पेसिफ़िकेशन साइनिंग और सत्यापन के लिए rsa-sha1 के इस्तेमाल पर रोक लगाता है।
RFC 8463 ed25519-sha256 जोड़ता है। अलग-अलग एल्गोरिदम सपोर्ट करने वाले प्राप्तकर्ताओं के साथ काम करने के लिए एक संदेश में RSA और Ed25519 दोनों सिग्नेचर हो सकते हैं।
Yahoo के दिशानिर्देश भी कम से कम 1024 बिट की DKIM कुंजी की माँग करते हैं।
जब कोई मेलिंग लिस्ट संदेश में बदलाव करती है, तो क्या होता है?
अगर कोई बदलाव सिग्नेचर के दायरे में आने वाली सामग्री को बदलता है, तो वह DKIM को अमान्य कर सकता है।
फ़ॉरवर्ड करना अपने आप में साइन की गई सामग्री को नहीं बदलता। बिना बदला सिग्नेचर फ़ॉरवर्ड होने के बाद भी मान्य रह सकता है। अंत में जोड़ा गया फ़ुटर बॉडी हैश बदल सकता है। साइन किए गए Subject को दोबारा लिखने से हेडर सिग्नेचर अमान्य हो सकता है।
वैकल्पिक l= टैग बॉडी की सुरक्षा को तय बाइट संख्या तक सीमित करता है। l=100 होने पर पहले 100 नॉर्मलाइज़ किए गए बाइट के बाद की सामग्री सुरक्षित नहीं रहती। इसलिए भ्रामक टेक्स्ट जोड़ने पर भी सिग्नेचर मान्य रह सकता है।
अगर आपको पूरी बॉडी सुरक्षित चाहिए, तो यह सीमा न लगाएँ। ARC की मदद से बीच के सर्वर अपने बदलावों से पहले के प्रमाणीकरण का साइन किया हुआ प्रमाण सुरक्षित रख सकते हैं।
Bird के साथ DKIM कैसे कॉन्फ़िगर करें?
जब आप अपना भेजने वाला डोमेन रजिस्टर करते हैं, तो लौटाया गया DKIM रिकॉर्ड आप प्रकाशित करते हैं।
API के dkim.mode फ़ील्ड का डिफ़ॉल्ट मान txt है। इस मोड में सार्वजनिक कुंजी को TXT रिकॉर्ड में प्रकाशित करें। स्कीमा में delegated भी सूचीबद्ध है। भेजने वाला डोमेन रजिस्टर करते समय यह मान HTTP 422 लौटाता है, इसलिए txt का उपयोग करें।
Bird किसी भेजने वाले डोमेन का उपयोग करने वाले हर संगठन के लिए अलग कुंजी और सेलेक्टर बनाता है। एक ही डोमेन का उपयोग करने वाले संगठनों को साइनिंग कुंजी साझा करने की ज़रूरत नहीं होती।
ऑथेंटिकेशन गाइड लौटाए गए रिकॉर्ड को समझाती है।
क्या पास होने वाला सिग्नेचर यह साबित करता है कि संदेश सुरक्षित है?
पास होने वाला सिग्नेचर साइन की गई सामग्री की ज़िम्मेदारी तय करता है। इससे यह तय नहीं होता कि संदेश चाहा गया है या भरोसेमंद है।
इसके लिए यह भी ज़रूरी नहीं कि साइनिंग डोमेन दिखाई देने वाले From डोमेन से मेल खाए। यह मिलान नियम DMARC अलाइनमेंट के ज़रिए देता है। सेंडर रेप्युटेशन, यानी प्राप्तकर्ता द्वारा किसी सेंडर के ट्रैफ़िक का आकलन, एक अलग पहलू बना रहता है।
संक्षेप में
केवल चुनी गई सामग्री सुरक्षित रहती है।
DKIM सूचीबद्ध हेडर फ़ील्ड और बॉडी हैश को कवर करता है। असुरक्षित सामग्री बदलने पर भी हस्ताक्षर अमान्य नहीं होता।
सेलेक्टर सत्यापन कुंजियों का पता बताते हैं।
सेलेक्टर और साइनिंग डोमेन मिलकर उस DNS रिकॉर्ड की पहचान करते हैं जिसमें सार्वजनिक कुंजी होती है।
नॉर्मलाइज़ेशन सत्यापन को प्रभावित करता है।
simple और relaxed एल्गोरिदम फ़ॉर्मैटिंग के बदलावों को अलग-अलग तरह से संभालते हैं।
फ़ॉरवर्ड करने पर पास होने की गारंटी नहीं है।
बिना बदला हस्ताक्षर फ़ॉरवर्डिंग के बाद भी मान्य रह सकता है, लेकिन हस्ताक्षरित सामग्री में बदलाव उसे तोड़ सकते हैं।