Модул 5 · 5.4
Криптирано доставяне: TLS, MTA-STS и DANE
Модул 5: Репутация и големите доставчици · Време за четене: 10 минути
Учебна цел: След този урок ще можете да обясните как пощенските сървъри криптират връзката помежду си, защо това по подразбиране не е задължително, и какво променят в това отношение MTA-STS, TLS-RPT и DANE. Ще можете да намерите и прочетете съответните записи.
Основни понятия: STARTTLS между сървъри, опортюнистично криптиране, downgrade атака, MTA-STS (RFC 8461), запис _mta-sts, файл с политика, режим testing/enforce/none, TLS-RPT (RFC 8460), запис _smtp._tls, DANE за SMTP (RFC 7672), TLSA запис, DNSSEC
Два вида връзки
В урок 1.4 стана въпрос за връзката между Вашата пощенска програма и пощенския сървър на Вашия доставчик: порт 587 с STARTTLS, или 465 с директен TLS, с вход чрез потребителско име и парола. Там Вие имате контрол. Вашата програма знае кой сървър очаква, проверява сертификата и отказва да се свърже, ако нещо не е наред.
Този урок разглежда следващата стъпка: връзката между изпращащия сървър и получаващия сървър, на порт 25. Там нещата протичат по различен начин.
Опортюнистично: криптиране, когато е възможно
Когато даден сървър доставя поща, той се свързва с MX сървъра на получателя. След EHLO той проверява дали получаващият сървър предлага STARTTLS. Ако да, той преминава към криптирана връзка. Ако не, доставя пощата некриптирана, без да се замисля.
Това се нарича опортюнистично криптиране: криптиране, когато е възможно, иначе не. И обикновено изпращащият сървър не проверява сертификата стриктно. Изтекъл или саморъчно издаден сертификат не е причина за спиране.
Защо е така? Защото пощата трябва винаги да продължава да работи, дори със стари сървъри. Изпращачът не може да знае дали получателят трябва да поддържа TLS. Това прави възможни две атаки:
- Downgrade. Някой, който може да манипулира трафика по пътя, премахва думата
STARTTLSот отговора на получателя. Изпращачът смята, че няма криптиране и доставя некриптирано. Нападателят чете съдържанието. - Фалшив MX. Някой, който може да фалшифицира DNS отговори, посочва собствен сървър като MX. Тъй като сертификатът не се проверява, изпращачът не забелязва нищо.
В наши дни почти всички големи пощенски сървъри криптират, а Gmail изисква от изпращачите да използват TLS (урок 5.3). Но "обикновено криптирано" е нещо различно от "винаги и с правилния сървър". За целта съществуват две решения: MTA-STS и DANE. И двете се настройват от получателя: с тях Вие съобщавате, че пощата към Вашия домейн винаги трябва да бъде криптирана, при сървър с валиден сертификат.
MTA-STS: политика чрез уеб страница
MTA-STS (Mail Transfer Agent Strict Transport Security, RFC 8461) работи с два компонента.
TXT запис, който указва, че съществува политика:
_mta-sts.example.com. 3600 IN TXT "v=STSv1; id=20261108T120000;"И файл с политика на фиксирано място, достъпен чрез https с валиден сертификат:
https://mta-sts.example.com/.well-known/mta-sts.txt
version: STSv1
mode: enforce
mx: mx1.example.com
mx: mx2.example.com
max_age: 604800| Ред | Значение |
|---|---|
mode: enforce | Доставяйте само чрез TLS с валиден сертификат при един от посочените MX сървъри. Ако това не е възможно, не доставяйте (съобщението остава в опашката) |
mode: testing | Доставяйте както обикновено, но съобщавайте за проблеми чрез TLS-RPT |
mode: none | Няма (повече) политика |
mx: | Имената на MX сървърите, които трябва да носят сертификата; *. в началото е допустимо |
max_age: | Колко дълго (в секунди) изпращачът може да запомни политиката |
id= в TXT записа | Номер на версия. Ако промените политиката, променете и id, за да могат изпращачите да изтеглят файла наново |
Хитрото е следното: изпращачът запомня политиката за продължителността на max_age. Нападател, който по-късно премахне думата STARTTLS или посочи фалшив MX, тогава се разкрива: политиката казва, че криптирането е задължително и кои сървъри са валидни. При самата първа връзка (преди политиката да е известна) MTA-STS не защитава; това е известната слаба точка.
Реален пример е gmail.com: TXT записът _mta-sts.gmail.com съществува, а файлът с политика на https://mta-sts.gmail.com/.well-known/mta-sts.txt е настроен на mode: enforce.
TLS-RPT: отчети за неуспешно криптиране
Когато MTA-STS е на enforce, пощата може да заседне, ако нещо не е наред с Вашия сертификат. Вие искате да узнаете за това. За целта съществува TLS-RPT (RFC 8460):
_smtp._tls.example.com. 3600 IN TXT "v=TLSRPTv1; rua=mailto:tlsrapport@example.com"Изпращачи, които поддържат TLS-RPT (включително Google и Microsoft), изпращат ежедневно отчет във формат JSON: колко връзки са успели и кои са се провалили, с причината (например изтекъл сертификат или име, което не фигурира в политиката). Както и при DMARC отчетите (урок 4.5), можете да възложите обработката им на услуга за отчети.
Ред на въвеждане: първо TLS-RPT, после MTA-STS на testing, четене на отчетите в продължение на няколко седмици, и едва след това enforce. Това прилича на препоръчителния подход при DMARC: първо наблюдение, после строгост.
DANE: сертификатът в DNS, защитен с DNSSEC
DANE (DNS-based Authentication of Named Entities) подхожда по различен начин. Поставяте в DNS TLSA запис за всеки MX сървър, с отпечатък на сертификата или ключа:
_25._tcp.mx1.example.com. 3600 IN TLSA 3 1 1 0d5a5c8f3d8aab82bba32bf8d711fa2433e4fe5fa4828b0443364d3ab5cdc1d5_25._tcp означава: за SMTP на порт 25. Трите числа указват как да се чете стойността. За пощенски сървъри най-често се използва 3 1 1: "това е SHA-256 отпечатъкът на публичния ключ на точно този сървър". Среща се и 2 1 1: тогава в записа е отпечатъкът на междинен сертификат.
Изпращач, който поддържа DANE, вижда TLSA записа, изисква криптиране и проверява дали сертификатът на сървъра съвпада. Ако не съвпада, не доставя.
Защо DANE е защитен срещу фалшифицирани DNS отговори? Защото работи единствено с DNSSEC (DNS курс, урок 8.1). Без валидна DNSSEC верига TLSA записите се игнорират. Това е и прагът: както Вашият домейн (за MX), така и зоната на пощенския сървър трябва да бъдат подписани.
DANE няма слабост от типа "първи път", каквато има MTA-STS, и се използва широко в Нидерландия и Германия. internet.nl го тества. Microsoft поддържа DANE за входяща поща в Exchange Online. Също така MX сървърите на internet.nl имат TLSA записи.
Капан: ако замените сертификата на пощенски сървър с DANE с нов ключ, TLSA записът трябва да се промени заедно с него, и то предварително: първо добавяте новия запис, изчаквате изтичането на TTL, едва тогава пускате новия ключ в употреба. Иначе изпращачите, използващи DANE, ще отхвърлят Вашата поща. При 3 1 1 това е от значение само когато ключът се променя, не и при всяко подновяване със същия ключ.
MTA-STS или DANE?
| MTA-STS | DANE | |
|---|---|---|
| Изисква DNSSEC | Не | Да |
| Къде се намира | TXT запис плюс файл с политика на уебсайт | TLSA запис за всеки MX сървър |
| Защитава първата връзка | Не | Да |
| Поддръжка | Поддържане на уебсайт и сертификат за mta-sts. | Актуализиране на TLSA при нов ключ |
Можете да ги използвате едновременно. RFC 8461 указва, че изпращач, който поддържа DANE, дава предимство на DANE, ако съществуват валидни TLSA записи.
Кой се занимава с това?
Това настройвате за входящата поща на Вашия домейн. Ако Вашата поща се обработва от хостинг компания или услуга за поща, зависи от съответния доставчик:
- DANE е възможен само ако доставчикът публикува TLSA записи за своите пощенски сървъри и Вашият домейн има DNSSEC. При WebOké можете например да включите DANE на същото място, където включвате DNSSEC (вижте статията на internet.nl по-долу); при други доставчици действа по подобен начин или е настроено по подразбиране.
- MTA-STS понякога можете да настроите сами, но тогава
mta-sts.example.comтрябва да бъде уебсайт с валиден сертификат, а Вие трябва да знаете имената на MX сървърите на Вашия доставчик. - TLS-RPT винаги можете да настроите сами: това е само TXT запис с адрес за отчитане.
За Вашата изходяща поща не е нужно да правите нищо: сървърът на Вашия доставчик определя дали зачита MTA-STS и DANE на получателите.
Обобщение
- Между пощенските сървъри TLS по подразбиране е опортюнистичен: криптирано, когато е възможно, без стриктна проверка на сертификата. Това прави възможни downgrade атаки и фалшив MX.
- MTA-STS: TXT
_mta-stsплюс файл с политика наhttps://mta-sts.<домейн>/.well-known/mta-sts.txt; режимtestingилиenforce. - TLS-RPT: TXT
_smtp._tlsс адрес за отчитане, за ежедневни отчети за неуспешно криптиране. - DANE: TLSA запис на
_25._tcp.<mx сървър>, работи само с DNSSEC и защитава и първата връзка. - Въвеждайте както при DMARC: първо отчети (TLS-RPT,
testing), после строгост.
Тест
Задача
Задача Z5.4: Проверка на MTA-STS, TLS-RPT и DANE. Потърсете при gmail.com MTA-STS записа и TLS-RPT записа, отворете файла с политика и попълнете режима (enforce, testing или none). След това потърсете при MX сървър на internet.nl TLSA записа на _25._tcp.<mx сървър> и попълнете първите три числа на един от записите. По желание: същите въпроси за Вашия собствен домейн (там отговорът може да бъде "няма"). Програмата проверява всичко на живо и сравнява.
За допълнително четене
Стъпките в тези статии важат за панелите на WebOké; при други доставчици действа по подобен начин.
- Контролен списък на Internet.nl
- Какво е DNSSEC?
- Безплатен курс по DNS 8.1: DNSSEC с прости думи
- internet.nl, проверете Вашата поща (независим тест на STARTTLS, DANE и други): https://internet.nl/
- RFC 8461 (MTA-STS), RFC 8460 (TLS-RPT), RFC 7672 (DANE за SMTP)