چرا امنیت انتقال ایمیل فقط با TLS حل نمی‌شود؟
بسیاری از سرورهای ایمیل هنگام تحویل پیام به یکدیگر از SMTP و قابلیت STARTTLS استفاده می‌کنند. در حالت Opportunistic TLS، فرستنده زمانی کانال رمزگذاری‌شده ایجاد می‌کند که سرور مقصد آن را اعلام کند. مشکل این است که اعلام پشتیبانی TLS می‌تواند در بخشی از مسیر دست‌کاری یا حذف شود و یک ارتباط بالقوه امن به مسیر ضعیف‌تر تنزل پیدا کند. علاوه بر این، سرور مقصد از طریق رکورد MX در DNS انتخاب می‌شود و اگر پاسخ DNS دست‌کاری شده باشد، فرستنده ممکن است به میزبان نادرست متصل گردد. پروتکل DANE برای SMTP راهکاری است که از رکوردهای معتبرشده DNSSEC برای اعلام انتظار امنیت حمل‌ونقل و ارتباط با گواهی مقصد استفاده می‌کند. هدف آن محافظت از تحویل بین دو MTA است، نه رمزگذاری سرتاسری متن پیام برای گیرنده نهایی.
DANE و TLSA چه رابطه‌ای دارند؟
نام DANE مخفف DNS-based Authentication of Named Entities است. در این روش، صاحب سرویس اطلاعاتی درباره گواهی TLS یا کلید عمومی مورد انتظار را در رکورد TLSA منتشر می‌کند. این رکورد زمانی قابل اعتماد است که مسیر DNS آن با DNSSEC اعتبارسنجی شده باشد. بنابراین یک رکورد TLSA که از پاسخ DNS نامطمئن به دست آمده، به‌تنهایی اثبات مالکیت سرویس نیست. RFC 7672 کاربرد ویژه DANE در انتقال SMTP بین سرورها را توضیح می‌دهد و RFC 6698 ساختار عمومی TLSA را تعریف می‌کند. برای استقرار باید نقش سرور ارسال‌کننده، میزبان MX، گواهی ارائه‌شده و اعتبار زنجیره DNS را جدا فهمید. ترکیب درست این اجزا در برابر حذف STARTTLS و جعل مسیر مقصد کمک می‌کند، اما جایگزین امنیت صندوق‌های ایمیل و کنترل‌های ضد فیشینگ نیست.
چگونه MX و TLSA کنار هم قرار می‌گیرند؟
زمانی که سرور مبدأ می‌خواهد برای یک دامنه پیام بفرستد، ابتدا مسیر تحویل را با بررسی رکورد MX پیدا می‌کند. سپس برای میزبان واقعی دریافت‌کننده، اطلاعات TLSA در نام ویژه‌ای شامل پورت و پروتکل پرس‌وجو می‌شود؛ برای نمونه نامی مانند _25._tcp.mail.example.org به سرویس SMTP روی پورت ۲۵ اشاره دارد. اعتبارسنج DNS باید داده مربوط به MX و TLSA را مطابق الزامات استاندارد بررسی کند. اگر رکوردهای لازم معتبر باشند، سرور ارسال‌کننده می‌تواند برای اتصال TLS و تطبیق گواهی تصمیم بگیرد. خطای رایج این است که مدیر فقط برای دامنه ریشه TLSA بسازد، در حالی که سرویس ایمیل روی نام میزبان MX دیگری کار می‌کند. طراحی درست از نمودار مسیر تحویل شروع می‌شود، نه از کپی کردن یک رکورد نمونه.
چهار بخش اصلی رکورد TLSA
رکورد TLSA شامل چهار بخش است: Certificate Usage، Selector، Matching Type و داده تطبیق. بخش Usage مشخص می‌کند چه نوع رابطه‌ای با گواهی یا مرجع اعتماد انتظار می‌رود. Selector تعیین می‌کند کل گواهی یا اطلاعات کلید عمومی موضوع بررسی است. Matching Type بیان می‌کند داده به صورت کامل یا اثر انگشت هش‌شده منتشر شده است. مقدار نهایی باید دقیقاً با بخش انتخاب‌شده از گواهی فعلی سرویس هماهنگ باشد. نمونه رایج 3 1 1 به مفهوم استفاده از DANE-EE، انتخاب SubjectPublicKeyInfo و تطبیق با SHA-256 است؛ با این حال انتخاب نهایی باید از راهنمای محصول و سیاست عملیاتی تبعیت کند. کپی کردن اثر انگشت از یک گواهی اشتباه می‌تواند باعث توقف تحویل پیام شود.
وابستگی DANE به DNSSEC
مهم‌ترین تفاوت DANE با قرار دادن یک اثر انگشت در صفحه وب آن است که مسیر انتقال سیاست امنیتی باید قابل اعتبارسنجی باشد. DNSSEC به Resolver کمک می‌کند منشأ رکورد و عدم تغییر آن را بررسی کند. اگر دامنه مقصد رکورد MX معتبرشده داشته باشد اما زنجیره TLSA خراب باشد، فرستنده‌ای که مطابق DANE عمل می‌کند نباید این خرابی را نادیده بگیرد و بی‌سروصدا به ارسال نامطمئن بازگردد. در مقابل، نبود DANE در دامنه‌ای که آن را اعلام نکرده است لزوماً خطای پروتکل نیست. همین تمایز میان «سرویس سیاست امنی اعلام نکرده» و «سیاست معتبر اعلام شده ولی شکست خورده» قلب دفاع در برابر downgrade است. مدیر باید وضعیت DNSKEY، DS، RRSIG و انقضای امضا را پیش از تولید بررسی کند.
DANE-EE و نگهداری گواهی
در تنظیماتی که از DANE-EE استفاده می‌کنند، اطلاعات مورد انتظار می‌تواند مستقیماً به گواهی یا کلید عمومی میزبان دریافت‌کننده مرتبط باشد. چنین مدلی به مدیر اجازه می‌دهد رابطه‌ای قابل بررسی میان نام سرویس و کلید آن تعریف کند. اما تغییر گواهی و کلید بدون هماهنگی با DNS می‌تواند تطبیق TLSA را از بین ببرد. بهتر است پیش از چرخش، پنجره همپوشانی و نحوه انتشار رکوردهای جدید با TTL مناسب طراحی شود. وقتی گواهی به‌طور خودکار تمدید می‌شود باید بررسی کرد آیا کلید عمومی ثابت می‌ماند یا تغییر می‌کند و سیاست TLSA چه اثری می‌پذیرد. نتیجه‌گیری درباره رفتار تمدید تنها بر اساس نام ابزار صدور گواهی درست نیست؛ مراحل واقعی و نوع رکورد باید آزمون شوند.
خطای DNS چه اثری بر صف ایمیل دارد؟
در اتصال وب، خطای TLS معمولاً به صورت پیام فوری مرورگر دیده می‌شود. در SMTP رفتار متفاوت است، زیرا ارسال‌کننده می‌تواند پیام را موقتاً در صف نگه دارد و بعداً دوباره تلاش کند. اگر رکورد TLSA معتبر وجود داشته باشد ولی اتصال قابل اعتبارسنجی برقرار نشود، سیاست استاندارد ممکن است مانع تحویل ناامن شود و پیام تا رفع خطا در صف بماند. مدیر دریافت‌کننده باید این پیامد را در برنامه تغییر DNS و گواهی لحاظ کند. وقتی مانیتورینگ فقط تعداد ایمیل‌های تحویل‌شده را نشان می‌دهد، افزایش تدریجی صف ممکن است دیر تشخیص داده شود. لازم است زمان تأخیر تحویل، گزارش خطای TLSA و سلامت DNSSEC به صورت مشترک پایش شوند. آزمون قبل از انتشار عمومی می‌تواند از ایجاد اختلال گسترده جلوگیری کند.
DANE و MTA-STS چه تفاوتی دارند؟
دو سازوکار DANE و MTA-STS به مسئله امنیت مسیر SMTP می‌پردازند ولی شیوه اعلام اعتماد در آن‌ها یکسان نیست. DANE از DNSSEC و رکورد TLSA برای بیان انتظار امنیتی بهره می‌برد. MTA-STS معمولاً سیاستی مبتنی بر HTTPS و ساختار اعتماد گواهی‌های عمومی را به کار می‌گیرد. انتخاب یکی از آن‌ها به قابلیت سرورهای ارسال و دریافت، DNS میزبان، شیوه صدور گواهی و شرایط بهره‌برداری بستگی دارد. در برخی سازمان‌ها بررسی هم‌زمان پشتیبانی از هر دو منطقی است، اما نباید آن‌ها را بدون مطالعه مثل دو گزینه کاملاً جایگزین با رفتار یکسان فرض کرد. هدف اصلی این است که سرور مبدأ بتواند وجود انتظار امنیتی را از کانالی قابل اعتماد تشخیص دهد و با شکست ارتباط بی‌صدا از آن صرف‌نظر نکند.
DANE ارتباطی با SPF و DKIM و DMARC دارد؟
SPF، DKIM و DMARC بیشتر به تشخیص هویت دامنه فرستنده و سیاست پذیرش پیام مربوط هستند، در حالی که DANE تلاش می‌کند مسیر حمل پیام میان سرورها را در برابر دست‌کاری و تنزل امنیتی محافظت کند. فعال بودن DKIM ثابت نمی‌کند ارتباط SMTP حتماً رمزگذاری شده است؛ به همین ترتیب داشتن TLSA به معنی حذف حمله فیشینگ یا جعل محتوای پیام نیست. یک معماری ایمیل حرفه‌ای باید این کنترل‌ها را مکمل بداند. مدیر می‌تواند SPF و DKIM را برای اعتبار پیام، DMARC را برای سیاست گزارش و DANE یا MTA-STS را برای محافظت از حمل بین سرورها ارزیابی کند. همه این‌ها به نگهداری درست DNS، مدیریت کلیدها و مشاهده‌پذیری نیاز دارند، اما مسئله امنیتی هرکدام متفاوت است.
پیش‌نیازهای عملی استقرار
قبل از ساخت TLSA باید فهرست کامل رکوردهای MX دامنه و میزبان‌هایی که واقعاً ایمیل را دریافت می‌کنند تهیه شود. اگر سرویس از چند ارائه‌دهنده یا مسیر پشتیبان استفاده می‌کند، هر میزبان باید جدا بررسی شود. دامنه و ناحیه‌های مربوط باید DNSSEC معتبر داشته باشند و مدیر باید به فرایند انتشار و چرخش رکوردها دسترسی داشته باشد. پس از آن گواهی‌های واقعی سرورهای مقصد و شیوه تمدیدشان مستند می‌شود. بهتر است محیط آزمایش با دامنه مستقل تهیه شود تا خطای تنظیم موجب توقف ایمیل سازمان نشود. آزمون باید شامل اتصال درست، گواهی ناسازگار، رکورد منقضی و سناریوی نبود TLSA باشد. تنها پس از ثبت نتایج و روش بازگشت، زمان انتقال تولید انتخاب می‌شود.
بررسی رکوردها با ابزارهای DNS
ابزارهایی مانند dig می‌توانند رکوردهای MX، TLSA و داده‌های DNSSEC را نمایش دهند. اما مشاهده یک پاسخ به معنی تأیید کامل زنجیره اعتماد نیست؛ لازم است Resolver اعتبارسنج و وضعیت امضا نیز بررسی شود. مدیر می‌تواند از چند مسیر شبکه و Resolver مستقل برای مقایسه استفاده کند تا خطای کش یا سرویس محلی آشکار شود. هنگام عیب‌یابی باید نام کامل TLSA، نوع رکورد و ترتیب فیلدها دقیق ثبت شوند. اگر رکورد منتشرشده مطابق انتظار در دسترس نیست، اول زنجیره انتشار DNS و TTL بررسی می‌شود، نه اینکه بی‌درنگ روی سرویس SMTP تغییر اعمال گردد. برای بررسی گواهی نیز بهتر است نتیجه اتصال TLS واقعی به میزبان MX با داده رکورد مقایسه شود؛ مقایسه دستی یک رشته بدون فهم Selector ممکن است گمراه‌کننده باشد.
سناریوی تمدید خودکار گواهی
فرض کنید گواهی میزبان ایمیل هر چند ماه با یک سامانه خودکار تمدید می‌شود. اگر رکورد TLSA بر بخشی از کلید عمومی فعلی تکیه داشته باشد و کلید در تمدید تغییر کند، بدون هماهنگی ممکن است پیام‌های جدید دیگر با سیاست DNS مطابقت نداشته باشند. روش امن برنامه‌ریزی برای انتشار اطلاعات جدید قبل از تغییر نهایی و رعایت زمان کش است. این کار باید با قابلیت‌های واقعی نرم‌افزار ایمیل و DNS اجرا شود؛ همه ارائه‌دهندگان مدیریت رکورد خودکار یکسان ندارند. مدیر باید مسئول چرخش، زمان هشدار، فرایند آزمون و واکنش اضطراری را تعیین کند. استفاده از یک گواهی آزمایشی و مشاهده تغییر اثر انگشت قبل از اجرای تولید می‌تواند خطر قطع تحویل را کم کند.
مدیریت خطا در سرورهای چندگانه
بسیاری از دامنه‌ها چند رکورد MX با اولویت متفاوت دارند. در چنین وضعی نباید فقط میزبان اصلی با DANE تنظیم شود و وضعیت میزبان پشتیبان فراموش گردد. هر مسیر باید از نظر پشتیبانی TLS، گواهی، نام میزبان و اعتبار رکوردهای مرتبط بررسی شود. رفتار ارسال‌کننده هنگام شکست یک مقصد ممکن است به وجود مسیر جایگزین و وضعیت رکوردهای آن وابسته باشد. همچنین نام‌های مستعار و ساختار DNS پیچیده می‌توانند تحلیل را دشوار کنند. گزارش استقرار باید نشان دهد برای هر MX چه سیاستی انتظار می‌رود و در چه شرایطی انتقال به مقصد دیگر مجاز است. بهترین آزمون آن است که در آزمایشگاه مسیر اصلی موقتاً از دسترس خارج و نتیجه واقعی سیستم صف و ارسال مشاهده شود.
ارتباط با خدمات ابری ایمیل
ارائه‌دهندگان ایمیل ابری ممکن است برای دریافت یا ارسال SMTP از DANE و DNSSEC پشتیبانی کنند، اما جزئیات راه‌اندازی برای دامنه‌های سفارشی متفاوت است. مستندات Microsoft Exchange Online نمونه‌ای از توضیح مسیر تحویل و اعتبارسنجی TLSA ارائه می‌دهد. پیش از انتقال یک دامنه باید مشخص شود کدام بخش از رکوردهای DNS توسط مشتری و کدام بخش توسط ارائه‌دهنده مدیریت می‌شود. اگر سرویس از درگاه امنیت ایمیل شخص ثالث استفاده می‌کند، مسیر واقعی MX اهمیت بیشتری پیدا می‌کند. همچنین باید بررسی شود پیام در حالت خطای DANE چه مدت در صف می‌ماند و مدیر از کدام گزارش‌ها متوجه مشکل می‌شود. ادعای پشتیبانی رسمی یک قابلیت لزوماً به معنی فعال بودن خودکار آن برای همه دامنه‌ها نیست.
پایش روزانه و شاخص‌های سلامت
پس از استقرار، موفقیت DANE را نمی‌توان فقط با مشاهده وجود رکورد TLSA سنجید. باید اعتبار DNSSEC، درستی تطبیق گواهی، نرخ خطاهای اتصال و مدت انتظار پیام‌ها پایش شوند. هشدار درباره تغییر بدون برنامه گواهی یا حذف رکورد مهم است، زیرا ممکن است مشکل قبل از دیده شدن شکایت کاربران آغاز شده باشد. داشبورد عملیاتی بهتر است دامنه، میزبان MX، وضعیت اعتبار امضا و آخرین زمان آزمون را نمایش دهد. برای جلوگیری از هشدارهای کاذب، تغییر برنامه‌ریزی‌شده باید در سامانه مدیریت تغییرات ثبت شود. داده‌های گزارش نباید محتوای محرمانه نامه‌ها را بی‌دلیل افشا کنند. تمرکز پایش بر وضعیت کانال انتقال و سلامت سیاست امنیتی کافی است؛ ذخیره همه پیام‌ها برای این هدف ضرورتی ندارد.
چک‌لیست انتشار و برنامه بازگشت
مالک دامنه باید ابتدا صحت DNSSEC را تأیید کند و همه سرورهای MX را فهرست نماید. سپس برای هر میزبان، گواهی واقعی و روش تمدید ثبت می‌شود. رکورد TLSA با فرمت مناسب ساخته و روی ناحیه آزمایشی منتشر می‌گردد. اعتبار رکورد از Resolverهای مستقل بررسی می‌شود و تحویل SMTP در حالت‌های سالم و خطا آزمون می‌شود. پس از آن برنامه تولید با زمان‌بندی TTL، مالک فنی و هشدارهای عملیاتی به تصویب می‌رسد. برنامه بازگشت باید مشخص کند در صورت مشکل چگونه بدون تشدید ریسک و با رعایت سیاست‌های امنیتی، سرویس را بازیابی کنیم. غیرفعال کردن شتاب‌زده اعتبارسنجی برای عبور از خطا ممکن است همان محافظتی را حذف کند که هدف استقرار بوده است.
جمع‌بندی و پرسش‌های متداول
آیا DANE نامه را از فرستنده تا صندوق گیرنده رمزگذاری می‌کند؟ خیر، تمرکز RFC 7672 بر انتقال میان سرورهای SMTP است. آیا هر TLSA قابل اعتماد است؟ تنها وقتی وضعیت DNSSEC آن به‌درستی اعتبارسنجی شده باشد. آیا نبود TLSA همیشه به معنی عدم امکان تحویل است؟ خیر؛ رفتار استاندارد به وضعیت امضای ناحیه و سیاست ارسال بستگی دارد. آیا DANE جایگزین DMARC است؟ خیر، آن‌ها مخاطرات متفاوتی را پوشش می‌دهند. آیا نصب یک رکورد برای چند سرور MX کافی است؟ باید وضعیت هر میزبان واقعی بررسی شود. نتیجه این است که DANE ابزار مهمی برای کاهش خطر تنزل TLS و جعل مسیر ایمیل است، ولی موفقیت آن به مدیریت DNSSEC، گواهی و فرآیند عملیاتی دقیق وابسته است. RFC 7672 و مستندات Microsoft منابع معتبر شروع هستند.
