به طور خلاصه، MTA-STS راهی برای محافظت بیشتر از ایمیل ها در برابر رهگیری (به عنوان مثال، حملات انسان در وسط با نام MitM) هنگام ارسال بین سرورهای ایمیل است. این تا حدی مشکلات معماری قدیمی پروتکل‌های ایمیل را حل می‌کند و در استاندارد نسبتاً جدید RFC 8461 توضیح داده شده است. Mail.ru اولین سرویس پست عمده در RuNet است که این استاندارد را پیاده‌سازی می‌کند. و در زیر برش با جزئیات بیشتر توضیح داده شده است.

MTA-STS چه مشکلی را حل می کند؟

از لحاظ تاریخی، پروتکل‌های ایمیل (SMTP، POP3، IMAP) اطلاعات را به صورت متن واضح منتقل می‌کردند که رهگیری آن را برای مثال هنگام دسترسی به یک کانال ارتباطی ممکن می‌کرد.

مکانیسم ارسال نامه از یک کاربر به کاربر دیگر چگونه است:

از لحاظ تاریخی، حمله MitM در همه مکان‌هایی که پست‌ها در آن‌ها در گردش است امکان‌پذیر بود.

RFC 8314 به استفاده از TLS بین برنامه کاربر ایمیل (MUA) و سرور ایمیل نیاز دارد. اگر سرور شما و برنامه‌های ایمیلی که استفاده می‌کنید مطابق با RFC 8314 هستند، پس (تا حد زیادی) امکان حملات Man-in-the-Middle بین کاربر و سرورهای ایمیل را از بین برده‌اید.

پیروی از روش های پذیرفته شده عمومی (استاندارد شده توسط RFC 8314) حمله نزدیک کاربر را از بین می برد:

سرورهای ایمیل Mail.ru حتی قبل از تصویب این استاندارد با RFC 8314 مطابقت داشتند؛ در واقع، آن به سادگی شیوه‌های پذیرفته شده قبلی را ضبط می‌کند و ما نیازی به پیکربندی هیچ چیز اضافی نداریم. اما، اگر سرور ایمیل شما همچنان به کاربران اجازه استفاده از پروتکل های ناامن را می دهد، حتما توصیه های این استاندارد را اجرا کنید، زیرا به احتمال زیاد، حداقل برخی از کاربران شما با ایمیل بدون رمزگذاری کار می کنند، حتی اگر از آن پشتیبانی کنید.

سرویس گیرنده ایمیل همیشه با همان سرور ایمیل همان سازمان کار می کند. و شما می توانید همه کاربران را مجبور کنید به روشی ایمن متصل شوند و سپس اتصال را برای کاربران غیر ایمن غیرممکن کنید (این دقیقاً همان چیزی است که RFC 8314 نیاز دارد). این گاهی اوقات دشوار است، اما شدنی است. ترافیک بین سرورهای ایمیل همچنان پیچیده تر است. سرورها متعلق به سازمان‌های مختلف هستند و اغلب در حالت «تنظیم و فراموش کردن» استفاده می‌شوند، که باعث می‌شود بدون قطع اتصال، به یک پروتکل امن تبدیل شوید. SMTP مدت‌ها است که پسوند STARTTLS را ارائه کرده است که به سرورهایی که از رمزگذاری پشتیبانی می‌کنند اجازه می‌دهد تا به TLS سوئیچ کنند. اما مهاجمی که توانایی تأثیرگذاری بر ترافیک را دارد، می‌تواند اطلاعات مربوط به پشتیبانی از این دستور را «قطع» کند و سرورها را مجبور به برقراری ارتباط با استفاده از یک پروتکل متن ساده (به اصطلاح حمله کاهش) کند. به همین دلیل، STARTTLS معمولاً اعتبار گواهی را بررسی نمی کند (یک گواهی نامعتبر می تواند در برابر حملات غیرفعال محافظت کند و این بدتر از ارسال پیام به صورت متنی واضح نیست). بنابراین، STARTTLS فقط در برابر استراق سمع غیرفعال محافظت می کند.

MTA-STS تا حدی مشکل رهگیری نامه ها بین سرورهای ایمیل را برطرف می کند، زمانی که مهاجم توانایی تأثیرگذاری فعال بر ترافیک را دارد. اگر دامنه گیرنده یک خط‌مشی MTA-STS منتشر کند و سرور فرستنده از MTA-STS پشتیبانی کند، ایمیل را فقط از طریق یک اتصال TLS، فقط به سرورهای تعریف‌شده توسط این خط‌مشی و فقط با تأیید گواهی سرور ارسال می‌کند.

چرا تا حدی؟ MTA-STS تنها در صورتی کار می کند که هر دو طرف مراقب اجرای این استاندارد باشند، و MTA-STS در برابر سناریوهایی که در آن مهاجم می تواند یک گواهی دامنه معتبر از یکی از CAهای عمومی دریافت کند، محافظت نمی کند.

MTA-STS چگونه کار می کند

گیرنده

1. پشتیبانی STARTTLS را با یک گواهی معتبر در سرور ایمیل پیکربندی می کند. 
2. خط مشی MTA-STS را از طریق HTTPS منتشر می کند؛ به عنوان مثال، یک دامنه mta-sts ویژه و یک مسیر شناخته شده خاص برای انتشار استفاده می شود. https://mta-sts.mail.ru/.well-known/mta-sts.txt. این خط مشی شامل فهرستی از سرورهای ایمیل (mx) است که حق دریافت نامه برای این دامنه را دارند.
3. یک رکورد TXT ویژه _mta-sts در DNS با نسخه خط مشی منتشر می کند. وقتی خط‌مشی تغییر می‌کند، این ورودی باید به‌روزرسانی شود (این به فرستنده سیگنال می‌دهد که سیاست را دوباره درخواست کند). مثلا، _mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"

فرستنده

فرستنده رکورد _mta-sts DNS را درخواست می کند و در صورت موجود بودن، از طریق HTTPS (بررسی گواهینامه) درخواست خط مشی می دهد. خط مشی حاصل در کش ذخیره می شود (در صورتی که مهاجم دسترسی به آن را مسدود کند یا رکورد DNS را جعل کند).

هنگام ارسال نامه، بررسی می شود که:

• سروری که نامه به آن تحویل داده می شود در خط مشی است.
• سرور با استفاده از TLS (STARTTLS) نامه می‌پذیرد و دارای گواهی معتبر است.

مزایای MTA-STS

MTA-STS از فناوری هایی استفاده می کند که قبلاً در اکثر سازمان ها پیاده سازی شده اند (SMTP+STARTTLS، HTTPS، DNS). برای پیاده سازی در سمت گیرنده، هیچ پشتیبانی نرم افزاری خاصی برای استاندارد مورد نیاز نیست.

معایب MTA-STS

نظارت بر اعتبار گواهی وب و سرور پست الکترونیکی، مطابقت اسامی و تمدید به موقع ضروری است. مشکلات مربوط به گواهی منجر به عدم امکان تحویل نامه می شود.

در سمت فرستنده، MTA با پشتیبانی از سیاست های MTA-STS مورد نیاز است؛ در حال حاضر، MTA-STS خارج از جعبه در MTA پشتیبانی نمی شود.

MTA-STS از لیستی از CAهای ریشه قابل اعتماد استفاده می کند.

MTA-STS در برابر حملاتی که در آن مهاجم از گواهی معتبر استفاده می کند محافظت نمی کند. در بیشتر موارد، MitM در نزدیکی سرور به معنای توانایی صدور گواهی است. چنین حمله ای را می توان با استفاده از شفافیت گواهی شناسایی کرد. بنابراین، به طور کلی، MTA-STS امکان رهگیری ترافیک را کاهش می دهد، اما به طور کامل از بین نمی برد.

دو نکته آخر MTA-STS را نسبت به استاندارد رقیب DANE برای SMTP (RFC 7672) کمتر ایمن می کند، اما از نظر فنی قابل اعتمادتر است، به عنوان مثال. برای MTA-STS به دلیل مشکلات فنی ناشی از اجرای استاندارد، احتمال کمی وجود دارد که نامه تحویل نشود.

استاندارد رقابتی - DANE

DANE از DNSSEC برای انتشار اطلاعات گواهی استفاده می کند و نیازی به اعتماد به مقامات گواهی خارجی ندارد، که بسیار ایمن تر است. اما استفاده از DNSSEC به طور قابل توجهی بیشتر منجر به خرابی های فنی می شود، بر اساس آمار در طول چندین سال استفاده (اگرچه به طور کلی روند مثبتی در قابلیت اطمینان DNSSEC و پشتیبانی فنی آن وجود دارد). برای پیاده سازی DANE در SMTP در سمت گیرنده، وجود DNSSEC برای منطقه DNS الزامی است و پشتیبانی صحیح از NSEC/NSEC3 برای DANE ضروری است که مشکلات سیستمیک در DNSSEC وجود دارد.

اگر DNSSEC به درستی پیکربندی نشده باشد، اگر طرف فرستنده از DANE پشتیبانی کند، می‌تواند منجر به شکست در تحویل نامه شود، حتی اگر طرف گیرنده چیزی در مورد آن نداند. بنابراین، علیرغم اینکه DANE استانداردی قدیمی تر و ایمن تر است و قبلاً در برخی از نرم افزارهای سرور در سمت فرستنده پشتیبانی می شود، در واقع نفوذ آن ناچیز است، بسیاری از سازمان ها به دلیل نیاز به پیاده سازی DNSSEC آمادگی اجرای آن را ندارند. این به طور قابل توجهی اجرای DANE را در تمام آن سال هایی که این استاندارد وجود داشته است کند کرده است.

DANE و MTA-STS با یکدیگر تضادی ندارند و می توانند با هم استفاده شوند.

پشتیبانی MTA-STS در Mail.ru Mail چیست؟

Mail.ru مدتی است که سیاست MTA-STS را برای همه دامنه های اصلی منتشر کرده است. ما در حال حاضر در حال پیاده سازی بخش مشتری از استاندارد هستیم. در زمان نگارش، خط‌مشی‌ها در حالت غیرمسدود اعمال می‌شوند (اگر تحویل توسط یک خط‌مشی مسدود شود، نامه از طریق یک سرور «یدکی» بدون اعمال خط‌مشی تحویل داده می‌شود)، سپس حالت مسدود کردن برای بخش کوچکی اجباری می‌شود. از ترافیک خروجی SMTP، بتدریج برای 100% ترافیک آن، اجرای سیاست ها پشتیبانی می شود.

چه کسی دیگری از استاندارد پشتیبانی می کند؟

تاکنون، سیاست‌های MTA-STS تقریباً 0.05٪ از دامنه‌های فعال را منتشر می‌کنند، اما با این وجود، آنها قبلاً از حجم زیادی از ترافیک ایمیل محافظت می‌کنند، زیرا این استاندارد توسط بازیکنان اصلی پشتیبانی می شود - Google، Comcast و تا حدی Verizon (AOL، Yahoo). بسیاری از خدمات پستی دیگر اعلام کرده اند که پشتیبانی از این استاندارد در آینده نزدیک اجرا خواهد شد.

این چه تاثیری بر من خواهد گذاشت؟

نه مگر اینکه دامنه شما یک خط مشی MTA-STS را منتشر کند. اگر این خط‌مشی را منتشر کنید، ایمیل‌های کاربران سرور ایمیل شما بهتر از رهگیری محافظت می‌شوند.

چگونه می توانم MTA-STS را پیاده سازی کنم؟

پشتیبانی MTA-STS در سمت گیرنده

کافی است خط مشی را از طریق HTTPS و رکوردها در DNS منتشر کنید، یک گواهی معتبر از یکی از CA های قابل اعتماد پیکربندی کنید (بیایید رمزگذاری کنیم ممکن است) برای STARTTLS در MTA (STARTTLS در همه MTA های مدرن پشتیبانی می شود)، بدون پشتیبانی ویژه از طرف MTA مورد نیاز است.

گام به گام، به نظر می رسد این است:

1. STARTTLS را در MTA که استفاده می کنید پیکربندی کنید (postfix، exim، sendmail، Microsoft Exchange، و غیره).
2. مطمئن شوید که از یک گواهی معتبر استفاده می کنید (که توسط یک CA قابل اعتماد صادر شده است، منقضی نشده است، موضوع گواهی با رکورد MX که نامه را برای دامنه شما ارسال می کند مطابقت دارد).
3. یک رکورد TLS-RPT را پیکربندی کنید که از طریق آن گزارش های برنامه سیاست (توسط سرویس هایی که از ارسال گزارش های TLS پشتیبانی می کنند) تحویل داده شود. ورودی مثال (برای دامنه example.com):

   smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»

   این ورودی به فرستندگان ایمیل دستور می دهد تا گزارش های آماری در مورد استفاده از TLS در SMTP را به آنها ارسال کنند [email protected].

   گزارش ها را برای چند روز نظارت کنید تا مطمئن شوید که هیچ خطایی وجود ندارد.

4. سیاست MTA-STS را روی HTTPS منتشر کنید. این خط‌مشی به‌صورت یک فایل متنی با پایان‌دهنده‌های خط CRLF بر اساس مکان منتشر می‌شود.

   https://mta-sts.example.com/.well-known/mta-sts.txt
   

   نمونه سیاست:

   version: STSv1
   mode: enforce
   mx: mxs.mail.ru
   mx: emx.mail.ru
   mx: mx2.corp.mail.ru
   max_age: 86400
   

   فیلد نسخه حاوی نسخه خط مشی (در حال حاضر STSv1)، حالت حالت برنامه سیاست، تست - حالت تست (خط مشی اعمال نمی شود)، اجرا - حالت "مبارزه" را تنظیم می کند. ابتدا خط مشی را با mode: testing منتشر کنید، اگر در حالت تست مشکلی برای خط مشی وجود نداشت، پس از مدتی می توانید به حالت: Enforce تغییر دهید.

   در mx، لیستی از تمام سرورهای ایمیلی که می توانند نامه را برای دامنه شما بپذیرند مشخص شده است (هر سرور باید یک گواهی پیکربندی شده باشد که با نام مشخص شده در mx مطابقت داشته باشد). Max_age زمان کش کردن خط مشی را مشخص می کند (زمانی که خط مشی به خاطر سپرده شده اعمال شود حتی اگر مهاجم تحویل آن را مسدود کند یا رکوردهای DNS را در طول زمان کش خراب کند، می توانید با تغییر mta-sts DNS نیاز به درخواست مجدد خط مشی را علامت بزنید. رکورد).

5. یک رکورد TXT در DNS منتشر کنید: 

   _mta-sts.example.com. TXT “v=STS1; id=someid;”
   

   یک شناسه دلخواه (مثلاً یک مهر زمانی) می‌تواند در فیلد id استفاده شود؛ زمانی که خط‌مشی تغییر می‌کند، باید تغییر کند، این به فرستنده‌ها اجازه می‌دهد بفهمند که باید سیاست ذخیره‌شده را دوباره درخواست کنند (اگر شناسه متفاوت از حافظه پنهان).

پشتیبانی از MTA-STS در سمت فرستنده

تا اینجای کار با او بد است، زیرا ... استاندارد تازه

• Exim - بدون پشتیبانی داخلی، یک اسکریپت شخص ثالث وجود دارد https://github.com/Bobberty/MTASTS-EXIM-PERL 
• Postfix - پشتیبانی داخلی وجود ندارد، یک اسکریپت شخص ثالث وجود دارد که به طور مفصل در Habré توضیح داده شده است. https://habr.com/en/post/424961/

به عنوان پسوند در مورد "TLS اجباری"

اخیرا، تنظیم کننده ها به امنیت ایمیل توجه کرده اند (و این یک چیز خوب است). به عنوان مثال، DMARC برای همه سازمان های دولتی در ایالات متحده اجباری است و به طور فزاینده ای در بخش مالی مورد نیاز است، با نفوذ استاندارد به 90٪ در مناطق تحت نظارت. اکنون برخی از تنظیم‌کننده‌ها به پیاده‌سازی «TLS اجباری» با دامنه‌های جداگانه نیاز دارند، اما مکانیسم اطمینان از «TLS اجباری» تعریف نشده است و در عمل این تنظیم اغلب به‌گونه‌ای پیاده‌سازی می‌شود که حتی حداقل از حملات واقعی که قبلاً انجام شده‌اند محافظت نمی‌کند. در مکانیسم هایی مانند DANE یا MTA-STS ارائه شده است.

اگر تنظیم کننده نیاز به اجرای "TLS اجباری" با دامنه های جداگانه داشته باشد، توصیه می کنیم MTA-STS یا آنالوگ جزئی آن را به عنوان مناسب ترین مکانیسم در نظر بگیرید، نیاز به ایجاد تنظیمات ایمن برای هر دامنه به طور جداگانه را از بین می برد. اگر در اجرای بخش کلاینت MTA-STS مشکل دارید (تا زمانی که پروتکل پشتیبانی گسترده ای دریافت کند، به احتمال زیاد آن ها این کار را خواهند کرد)، می توانیم این روش را توصیه کنیم:

1. یک خط‌مشی MTA-STS و/یا سوابق DANE را منتشر کنید (DANE فقط در صورتی منطقی است که DNSSEC از قبل برای دامنه شما فعال شده باشد، و در هر صورت MTA-STS)، این کار از ترافیک در جهت شما محافظت می‌کند و نیازی به درخواست سایر سرویس‌های پستی را از بین می‌برد. برای پیکربندی TLS اجباری برای دامنه خود در صورتی که سرویس پست از قبل از MTA-STS و/یا DANE پشتیبانی می کند.
2. برای سرویس‌های ایمیل بزرگ، یک «آنالوگ» از MTA-STS را از طریق تنظیمات انتقال جداگانه برای هر دامنه پیاده‌سازی کنید، که MX مورد استفاده برای ارسال نامه را برطرف می‌کند و به تأیید اجباری گواهی TLS برای آن نیاز دارد. اگر دامنه‌ها قبلاً یک خط‌مشی MTA-STS منتشر کرده‌اند، احتمالاً می‌توان این کار را بدون دردسر انجام داد. به خودی خود، فعال کردن TLS اجباری برای یک دامنه بدون تعمیر رله و تأیید گواهی برای آن از نقطه نظر امنیتی بی اثر است و چیزی به مکانیسم های STARTTLS موجود اضافه نمی کند.

منبع: www.habr.com