Якщо коротко, то MTA-STS — це спосіб додатково захистити листи від перехоплення (тобто атак зловмисник усередині aka MitM) при передачі між поштовими серверами. Він частково вирішує успадковані архітектурні проблеми протоколів електронної пошти та описаний у відносно свіжому стандарті RFC 8461. Пошта Mail.ru – перша велика поштова служба в Рунеті, що реалізує цей стандарт. А детальніше розповідається вже під катом.
Яку проблему вирішує 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. Але атакуючий, у якого можна впливати на трафік, може «вирізати» інформацію про підтримку цієї команди і змусити сервери спілкуватися за звичайним текстовим протоколом (т.зв. downgrade attack — атака на зниження версії протоколу). З цієї ж причини, для STARTTLS зазвичай не перевіряється відповідність сертифіката (недовірений сертифікат може захищати від пасивних атак, і це не гірше відправки листа відкритим текстом). Тому STARTTLS захищає лише від пасивного прослуховування.
MTA-STS частково усуває проблему перехоплення листів між поштовими серверами, коли атакуючий має можливість активно впливати на трафік. Якщо домен одержувача публікує політику MTA-STS, і сервер відправника підтримує MTA-STS, він надсилатиме лист тільки через TLS-з'єднання, тільки на сервери, визначені політикою, і лише з перевіркою сертифіката сервера.
Чому частково? MTA-STS працює тільки якщо обидві сторони подбали про впровадження цього стандарту, і MTA-STS не захищає від сценаріїв, при яких атакуючий має можливість отримати валідний сертифікат домену в одному з публічних CA.
Як працює MTA-STS
одержувач
- Налаштовує підтримку STARTTLS із валідним сертифікатом на поштовому сервері.
- Публікує через HTTPS політику MTA-STS, для публікації використовується спеціальний домен mta-sts та спеціальний well-known шлях, наприклад
https://mta-sts.mail.ru/.well-known/mta-sts.txt. Політика містить список поштових серверів (mx), які мають право отримувати пошту для цього домену. - Публікує спеціальний TXT-запис _mta-sts у DNS з версією політики. При зміні політики цей запис має бути оновлений (це сигналізує відправнику про необхідність перезапитувати політику). Наприклад,
_mta-sts.mail.ru. TXT "v=STSv1; id=20200303T120000;"
Відправник
Відправник запитує DNS-запис _mta-sts, за її наявності робить запит політики щодо 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 поблизу сервера передбачає можливість випуску сертифіката. Подібна атака може бути знайдена за рахунок Certificate Transparency. Тому в цілому MTA-STS мітігує, але не повністю усуває можливість перехоплення трафіку.
Два останні пункти роблять MTA-STS менш захищеним, ніж конкуруючий стандарт DANE для SMTP (RFC 7672), але технічно надійним, тобто. для MTA-STS низька ймовірність, що лист не буде доставлений через технічні проблеми, викликані впровадженням стандарту.
Конкуруючий стандарт - DANE
DANE використовує DNSSEC для публікації інформації про сертифікати і не вимагає довіри до зовнішніх центрів, що значно безпечніше. Але використання DNSSEC значно частіше призводить до технічних збоїв, якщо спиратися на статистику за кілька років використання (хоча в надійності DNSSEC та його технічної підтримки загалом спостерігається позитивна динаміка). Для реалізації DANE у SMTP на стороні одержувача наявність DNSSEC для DNS-зони є обов'язковою, причому для DANE істотна коректна підтримка NSEC/NSEC3, з якою у DNSSEC є системні проблеми.
Якщо DNSSEC налаштований з помилками, це може призвести до відмови в доставці пошти, якщо сторона, що відправляє, підтримує DANE, навіть якщо сторона, що приймає, нічого про нього не знає. Тому, незважаючи на те, що DANE — це більш старий і захищений стандарт і вже підтриманий у деякому серверному програмному забезпеченні на стороні відправника, за фактом його проникнення залишається незначним, багато організацій не готові впроваджувати його через необхідність реалізації DNSSEC, це суттєво гальмувало впровадження DANE всі роки, що стандарт існує.
DANE та MTA-STS не конфліктують один з одним і можуть бути використані спільно.
Що за допомогою MTA-STS в Пошті Mail.ru
Mail.ru вже давно публікує політику MTA-STS для всіх основних доменів. Наразі ми займаємося впровадженням клієнтської частини стандарту. На момент написання статті політики застосовуються в неблокувальному режимі (у разі якщо доставка блокована політикою, лист буде доставлено через «запасний» сервер без застосування політик), потім буде форсований блокуючий режим для невеликої частини вихідного SMTP-трафіку, поступово для 100% трафіку буде підтримуватись застосування політик.
Хто ще підтримує стандарт
Поки що політика MTA-STS публікує приблизно 0.05% активних доменів, але, проте, вони вже захищають великий обсяг поштового трафіку, т.к. стандарт підтримують великі гравці - Google, Comcast та частково Verizon (AOL, Yahoo). Багато інших поштових служб заявили про те, що підтримка стандарту буде реалізована в найближчому майбутньому.
Як мене це торкнеться?
Ніяк, якщо ваш домен не оприлюднює політику MTA-STS. Якщо ви опублікуєте політику, листи для користувачів вашого поштового сервера будуть краще захищені від перехоплення.
Як мені впровадити MTA-STS?
Підтримка MTA-STS на стороні одержувача
Достатньо опублікувати політику через HTTPS та записи в DNS, налаштувати валідний сертифікат від одного з довірених CA (можна Let's encrypt) для STARTTLS до MTA (STARTTLS підтримується у всіх сучасних MTA), спеціальна підтримка з боку MTA не потрібна.
За кроками це виглядає так:
- Налаштуйте STARTTLS у використовуваному MTA (postfix, exim, sendmail, Microsoft Exchange тощо).
- Переконайтеся, що використовується валідний сертифікат (виданий довіреним CA, не прострочений, суб'єкт сертифіката відповідає MX-запису, за яким доставляється пошта для вашого домену).
- Налаштуйте TLS-RPT запис, за яким доставлятимуться звіти про застосування політик (сервіси, що підтримують надсилання звітів TLS). Приклад запису (для домену example.com):
smtp._tls.example.com. 300 IN TXT «v=TLSRPTv1;rua=mailto:[email protected]»Цей запис інструктує відправників пошти надсилати статистичні звіти щодо використання TLS у SMTP на адресу
[email protected].Слідкуйте за звітами кілька днів, переконайтеся у відсутності помилок.
- Опублікуйте політику 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Поле version містить версію політики (зараз це
STSv1), Mode задає режим застосування політики, testing - тестовий режим (політика не застосовується), enforce - "бойовий" режим. Спочатку опублікуйте політику mode: testing, якщо з політикою не знайдеться проблем у тестовому режимі, через деякий час можна переключитися на mode: enforce.У mx задається список всіх поштових серверів, які можуть приймати пошту для вашого домену (у кожного сервера має бути налаштований сертифікат, відповідний імені заданому в mx). Max_age задає час кешування політики (одного разу запам'ятана політика буде застосовуватися навіть якщо атакуючий блокує її віддачу або зіпсує DNS-записи протягом часу кешування, сигналізувати про необхідність знову запитати політику можна через зміну mta-sts запису DNS).
- Опублікуйте в DNS TXT-запис:
_mta-sts.example.com. TXT “v=STS1; id=someid;”У полі id можна використовувати довільний ідентифікатор (наприклад, позначку часу), при зміні політики він повинен змінюватися, це дозволяє відправникам зрозуміти, що необхідно перезапитати кешовану політику (якщо ідентифікатор відрізняється від кешованого).
Підтримка MTA-STS на стороні відправника
Поки що з нею погано, т.к. свіжий стандарт.
- Exim - немає вбудованої підтримки, є сторонній скрипт
- Postfix - немає вбудованої підтримки, є сторонній скрипт про який детально розказано на Хабрі
Як післямова про «mandatory TLS»
Останнім часом регулятори звертають увагу на безпеку пошти (і це добре). Наприклад, DMARC є обов'язковим для всіх держустанов у США і все частіше потрібний у фінансовій сфері, у регульованих сферах проникнення стандарту досягає 90%. Зараз деякі регулятори вимагають впровадження "mandatory TLS" з окремими доменами, але при цьому механізм забезпечення "mandatory TLS" не визначається і на практиці це налаштування часто впроваджується таким способом, який навіть мінімально не захищає від реальних атак, які вже передбачені в таких механізмах як DANE чи MTA-STS.
Якщо регулятор потребує реалізації «mandatory TLS» з окремими доменами, ми рекомендуємо розглянути MTA-STS або його частковий аналог як найбільш підходящий механізм, він усуває необхідність робити безпечні налаштування для кожного домену окремо. Якщо у вас є складнощі з реалізацією клієнтської частини MTA-STS (поки протокол не отримав широкої підтримки, вони швидше за все будуть), можна рекомендувати такий підхід:
- Опублікуйте політику MTA-STS та/або записи DANE (DANE має сенс додавати тільки якщо для вашого домену вже включений DNSSEC, а MTA-STS у будь-якому випадку), це захистить трафік у ваш бік і позбавить необхідності просити інші поштові служби налаштувати mandatory TLS для вашого домену, якщо поштова служба вже підтримує MTA-STS та/або DANE.
- Для великих поштових сервісів реалізуйте «аналог» MTA-STS через окремі налаштування транспорту для кожного домену, які зафіксують MX, що використовується для релеїнгу пошти, і вимагатимуть для нього обов'язкової перевірки TLS-сертифіката. Якщо домени вже публікують політику MTA-STS, це швидше за все можна зробити безболісно. Саме по собі включення обов'язкового TLS для домену без фіксації релею та перевірки сертифіката для нього неефективне з точки зору безпеки і нічого не додає до наявних механізмів STARTTLS.
Джерело: habr.com