Поскольку организации все больше полагаются на электронную почту как на основное средство коммуникации, важность защиты этих каналов от потенциальных угроз трудно переоценить. Безопасность транспортного уровня (TLS) обеспечивает конфиденциальность и целостность данных, передаваемых по сети.

Несколько протоколов помогают шифровать каналы сообщений SMTP, чтобы киберзлоумышленники не смогли перехватить электронную почту. К ним относятся STARTTLS, DANE и MTA-STS. Однако, когда попытки шифрования при использовании этих протоколов заканчиваются неудачей, ваше письмо может быть не доставлено. TLS-RPT (как описано в RFC 8460) обеспечивает механизм обратной связи для сообщения о таких сбоях в доставке.

Мы настоятельно рекомендуем использовать TLS-RPT в сочетании с MTA-STS протоколом. Давайте разберемся, как эти протоколы работают вместе для повышения безопасности электронной почты.

Что такое TLS-RPT?

TLS-RPT (Transport Layer Security Reporting) - это стандарт, позволяющий сообщать о проблемах с доставкой электронной почты, когда письмо не зашифровано с помощью TLS. Его важность для аутентификации электронной почты совпадает с причиной включения шифрования TLS для электронной почты.

Шифрование TLS гарантирует, что каждое отправленное вам письмо будет доставлено в безопасном режиме. Если соединение небезопасно, часто письма могут не доставляться. TLS-RPT позволяет владельцам доменов отслеживать доставку электронной почты и сбои в соединении. Отчеты могут содержать информацию о:

Проблемы с обработкой политики MTA-STS
Причина и тип отказа в доставке
IP-адреса агентов по передаче и получению электронной почты
Общее количество успешных и неуспешных сеансов TLS-соединения

Это обеспечивает видимость ваших каналов электронной почты и позволяет быстрее решать проблемы с доставкой.

Как работает отчетность TLS?

При передаче электронной почты по протоколу SMTP шифрование TLS является "оппортунистическим". Это означает, что если зашифрованный канал не может быть согласован, электронная почта все равно отправляется в незашифрованном (обычном) формате. На самом деле, почти 4 десятилетия назад протоколы электронной почты SMTP не поддерживали шифрование TLS. Его пришлось внедрять позже в виде команды STARTTLS.

Команда STARTTLS выполняется в SMTP-коммуникациях только в том случае, если обе стороны поддерживают шифрование TLS. В противном случае письмо будет отправлено в виде обычного текста.

Чтобы избавиться от оппортунистического шифрования в SMTP, был введен MTA-STS (RFC 8461). Протокол MTA-STS обеспечивает шифрование электронной почты перед доставкой. Ваш почтовый сервер или агент передачи почты (MTA) договаривается с принимающим сервером о том, поддерживает ли он команду STARTTLS. Если поддерживает, письмо шифруется с помощью TLS и доставляется. В противном случае доставка не выполняется.

Причин сбоев шифрования TLS может быть несколько. Помимо отсутствия поддержки шифрования с обеих сторон, к сбою TLS-соединения могут привести и более зловещие причины, например атака на понижение SMTP. При включенном MTA-STS злоумышленникам не удается доставить сообщения в виде обычного текста при обрыве соединения.

Но владельцы доменов хотели бы знать о неудачной доставке. TLS-отчет (TLS-RPT) - это протокол, который уведомит вас об этом. При сбоях в доставке вы получите отчет TLS в формате JSON на адрес электронной почты, указанный в вашей записи TLS-RPT.

Зачем нужна отчетность SMTP TLS?

Владельцы доменов должны быть в курсе событий, связанных с электронной почтой

проблемы с доставкой из-за сбоев в шифровании TLS для писем, отправленных из домена с поддержкой MTA-STS. Отчеты TLS делают это возможным, предоставляя такую информацию. TLS-RPT

Получать отчеты с обратной связью, в которых указывается тип вашего полиса и
Чтобы определить причину сбоев в шифровании TLS
Чтобы добиться видимости на каналах электронной почты
Чтобы решить проблемы с доставкой

Шаги по настройке TLS-RPT

Вы можете включить TLS-отчетность для своего домена, создав TXT-запись для TLS-RPT и опубликовав ее в DNS. Эта запись должна быть опубликована на поддомене smtp.tls.yourdomain.com

Шаг 1: Выберите инструмент для создания записей TLS-RPT

Вы можете зарегистрироваться В PowerDMARC можно зарегистрироваться бесплатно и использовать наш генератор записей TLS-RPT для создания записи.

Шаг 2: Введите адрес электронной почты для отчетности

Введите адрес электронной почты, на который вы хотите получать отчеты SMTP TLS.

Шаг 3: Опубликуйте запись TLS в вашем DNS

Вы можете обратиться к регистратору домена, чтобы создать новую TXT-запись для TLS-RPT. Если вы сами управляете DNS, измените настройки DNS, чтобы включить эту запись.

Пример записи TLS-RPT

Синтаксис: v=TLSRPTv1; rua=mailto:[email protected];

Давайте разберем 2 компонента предоставляемой отчетной записи TLS:

v=TLSRPTv1: Этот тег указывает версию используемого протокола TLS-RPT. В данном случае, "TLSRPTv1" указывает на первую версию протокола.
rua=mailto:[email protected]: rua означает "Reporting URI(s) for Aggregate Data". Этот тег указывает, куда почтовый сервер получателя должен отправлять агрегированные отчеты TLS.

Вы можете настроить несколько пунктов назначения для получения отчетов. Для нескольких пунктов назначения разделяйте каждый пункт запятой (,). Вы можете либо использовать "maito:", чтобы указать адрес электронной почты для этого шага, либо указать MTA отправлять отчеты через POST на URL-адреса конечных точек, используя "https:" в поле rua=. Если вы используете "https:" , убедитесь, что поле определяет URL-адрес веб-сервера с поддержкой HTTPS и действующим сертификатом. И "mailto:", и "https:" также можно использовать в одной записи, разделяя их запятой.

Пример: v=TLSRPTv1; rua=mailto:[email protected],https://tlsreport.example.com;

Примечание: На практике вы замените "yourdomain.com" на реальное имя домена, в котором вы хотите получать эти отчеты.

Формат отчетов TLS

Отчеты TLS отправляются в формате JSON. Ниже приведен пример того, как может выглядеть отчет TLS в формате JSON:

{

"organization-name": "Organization Inc.",

“date-range”: {

"start-datetime": “2020-10-22T00:00:00Z”,

"end-datetime": “2020-10-22T23:59:59Z”

"contact-info": "[email protected]",

"report-id": “2020-10-22T00:00:00Z_domain.com”,

"policies": [

{

“policy”: {

"policy-type": "sts",

"policy-string": [

"Версия: STSv1",

"Режим: тестирование",

"mx: mx.domain.com",

"mx: mx2.domain.com",

"mx: mx3.domain.com",

"max_age: 604800"

"policy-domain": "domain.com".

“summary”: {

"total-successful-session-count": 15,

"total-failure-session-count": 0

}

Вот разбивка основных полей этого JSON TLS-отчета:

Поля	Описание
организация	Доменная организация, которой принадлежит запись TLS-RPT.
e-mail	Адрес электронной почты, на который отправляются агрегированные отчеты.
начальная_дата	Дата начала отчетного периода.
дата окончания	Дата окончания отчетного периода.
политика	Массив объектов политики, описывающих политики, примененные в отчетном периоде.
политика	Содержит информацию о примененной политике.
тип политики	Указывает тип политики
строка_политики	Указывает строку политики, связанную с политикой
режим	Указывает режим политики MTA-STS (Enforce/Testing).
резюме	Содержит краткую информацию о сеансах, в которых были предприняты попытки.
total_successful_session_count	Общее количество успешно установленных сеансов TLS.
total_failure_session_count	Общее количество отказов сеансов TLS.
сведения о неудаче	Массив объектов, содержащих подробную информацию о конкретных сбоях.
причина	Строка, указывающая на причину неудачи (например, "сертификат_истек").
считать	Количество сеансов, которые завершились неудачей по определенной причине.

Причины и типы отказов при шифровании TLS

Проблемы с сертификатами

Виды отказов	Причины	Возможные варианты устранения неполадок
сертификат_истёк	Срок действия сертификата, представленного удаленным сервером, истек. Это делает его недостоверным для шифрования.	Обновите свой сертификат.
сертификат_не_действительный_еще	Сертификат, представленный удаленным сервером, еще не действителен. Это может быть связано с неправильным временем сервера или преждевременным использованием сертификата.	Обратитесь к поставщику сертификатов.
сертификат_отменён	Сертификат, представленный удаленным сервером, был отозван центром сертификации по соображениям безопасности.	Обратитесь к поставщику сертификатов.
no_valid_signature	Цепочка сертификатов, представленная удаленным сервером, не вызывает доверия у почтового сервера или клиента отправителя, что указывает на потенциальную угрозу безопасности.	Обратитесь к поставщику сертификатов.
неподдерживаемый_сертификат	В сертификате, представленном удаленным сервером, используются алгоритмы шифрования или длина ключа, которые не поддерживаются почтовым сервером отправителя, что препятствует установлению безопасного соединения.	Обратитесь к поставщику сертификатов.

Несоответствие имени хоста и идентификатора

Тип отказа	Причина	Возможные варианты устранения неполадок
несоответствие имени хоста	Имя хоста, указанное в сертификате сервера, не совпадает с именем хоста сервера, к которому пытается подключиться почтовый сервер отправителя. Это указывает на возможную атаку "человек посередине" или проблемы с конфигурацией.	Проверьте MX-записи в файле политики MTA-STS, чтобы убедиться, что они совпадают с MX-записями для домена.

Вопросы рукопожатия и протокола

Виды отказов	Причины	Возможные варианты устранения неполадок
рукопожатие_неудача	Во время начального процесса квитирования TLS между почтовым сервером отправителя и почтовым сервером получателя возникла проблема, препятствующая установлению защищенного канала.	Дважды проверьте, было ли установлено соединение SMTP STARTTLS. Сбои в шифровании могут быть вызваны несколькими причинами, например отсутствием поддержки STARTTLS или атакой на понижение TLS.

Вопросы политики MTA-STS

Виды отказов	Причины	Возможные варианты устранения неполадок
mta_sts_policy_not_found	Этот сбой происходит, когда почтовый сервер отправителя не может найти политику MTA-STS для домена получателя.	Просмотрите файл политики MTA-STS. Проверьте запись MTA-STS, чтобы убедиться, что она была опубликована правильно.
mta_sts_policy_invalid	Этот сбой происходит, когда политика MTA-STS, найденная в DNS для домена получателя, недействительна, содержит ошибки или не соответствует спецификации MTA-STS.	Просмотрите файл политики MTA-STS. Укажите соответствующий режим политики MTA-STS. Это может быть None, Enforce или Testing. Это указывает серверам-отправителям, как обрабатывать сообщения электронной почты, в которых произошли сбои при проверке политики MTA-STS. Подробнее о режимах политики можно узнать здесь.
mta_sts_policy_fetch_error	Этот сбой возникает, когда почтовый сервер отправителя сталкивается с ошибкой при попытке получить политику MTA-STS из DNS-записей домена получателя.	Проверьте записи MTA-STS в DNS, чтобы убедиться в правильности синтаксиса записи.
mta_sts_connection_failure	Этот сбой возникает, когда почтовый сервер отправителя пытается установить безопасное соединение с помощью MTA-STS, но не может этого сделать по таким причинам, как недоверенные сертификаты, неподдерживаемые наборы шифров или другие проблемы с TLS.	Проверьте срок действия сертификата, убедитесь, что он соответствует последнему стандарту TLS.
mta_sts_invalid_hostname	Этот сбой происходит, когда имя хоста почтового сервера получателя, указанное в политике MTA-STS, не совпадает с реальным именем хоста сервера.	Проверьте MX-записи в файле политики MTA-STS, чтобы убедиться, что они совпадают с MX-записями для домена.

Упрощенная отчетность по SMTP TLS с помощью PowerDMARC

SMTP TLS-отчетность PowerDMARC - это повышение уровня безопасности и упрощение работы с размещенным сервисом.

Переведенные отчеты TLS

Сложные отчеты TLS-RPT JSON преобразуются в упрощенную информацию, которую можно просмотреть за несколько секунд или прочитать подробно.

Проблемы автоопределения

Платформа PowerDMARC определяет и выделяет проблему, с которой вы столкнулись, чтобы вы могли решить ее, не теряя времени.

В платформе PowerDMARC мне нравится не что-то одно, она проста в использовании и понятна, при этом обладает, как я бы сказал, полным набором функций, позволяя контролировать DMARC на хостинге, сглаживать SPF, легко расширять SPF для проверки специфики записи и даже полностью поддерживать MTA-STS и TLS-RPT!

Дилан Б (владелец бизнеса)

Часто задаваемые вопросы по безопасности транспортного уровня

1. Что означает TLS?

TLS расшифровывается как Transport Layer Security.

2. Кто выдает сертификаты TLS?

Центры сертификации (ЦС) могут выдавать сертификаты TLS. Процесс выдачи сертификата включает проверку личности владельца сертификата. При успешной идентификации сертификат выдается.

3. Зачем нужен сертификат TLS?

Сертификаты TLS играют ключевую роль в обеспечении безопасности связи через Интернет. Они помогают зашифровать конфиденциальную информацию, которой обмениваются взаимодействующие веб-серверы. Среди наиболее распространенных способов использования сертификата - защита электронной почты и HTTPS.

4. Каков текущий стандарт TLS?

TLS 1.3 является последней версией Transport Layer Security. TLS-RPT может быть реализован с использованием любой версии TLS. Это могут быть как старые версии протокола, так и будущие. Версия обычно определяется такими критериями, как возможности взаимодействующих серверов.

Юнес Тарада

Эксперт по безопасности доменов и электронной почты в PowerDMARC

Юнес - руководитель группы операций в PowerDMARC, обладающий экспертными знаниями в области аутентификации и безопасности электронной почты. Юнес имеет сертификат Microsoft Azure Administrator Associate, а также сертификаты CompTIA A+ и многие другие.

Последние сообщения Юнеса Тарады (см. все)

Yahoo Japan рекомендует пользователям внедрить DMARC в 2025 году - 17 января 2025 г.
Ботнет MikroTik использует неправильную конфигурацию SPF для распространения вредоносного ПО - 17 января 2025 г.
Неаутентифицированная почта DMARC запрещена [Решено] - 14 января 2025 г.

Что такое отчетность SMTP TLS?