Поскольку организации все больше полагаются на электронную почту как на основное средство коммуникации, важность защиты этих каналов от потенциальных угроз трудно переоценить. Безопасность транспортного уровня (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:tlsrpt@yourdomain.com;
Давайте разберем 2 компонента предоставляемой отчетной записи TLS:
- v=TLSRPTv1: Этот тег указывает версию используемого протокола TLS-RPT. В данном случае, "TLSRPTv1" указывает на первую версию протокола.
- rua=mailto:tlsrpt@yourdomain.com: rua означает "Reporting URI(s) for Aggregate Data". Этот тег указывает, куда почтовый сервер получателя должен отправлять агрегированные отчеты TLS.
Вы можете настроить несколько пунктов назначения для получения отчетов. Для нескольких пунктов назначения разделяйте каждый пункт запятой (,). Вы можете либо использовать "maito:", чтобы указать адрес электронной почты для этого шага, либо указать MTA отправлять отчеты через POST на URL-адреса конечных точек, используя "https:" в поле rua=. Если вы используете "https:" , убедитесь, что поле определяет URL-адрес веб-сервера с поддержкой HTTPS и действующим сертификатом. И "mailto:", и "https:" также можно использовать в одной записи, разделяя их запятой.
Пример: v=TLSRPTv1; rua=mailto:tlsrpt@example.com,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": "smtp-tls-reporting@organization.com",
"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. |
| Адрес электронной почты, на который отправляются агрегированные отчеты. | |
| начальная_дата | Дата начала отчетного периода. |
| дата окончания | Дата окончания отчетного периода. |
| политика | Массив объектов политики, описывающих политики, примененные в отчетном периоде. |
| политика | Содержит информацию о примененной политике. |
| тип политики | Указывает тип политики |
| строка_политики | Указывает строку политики, связанную с политикой |
| режим | Указывает режим политики 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. Это могут быть как старые версии протокола, так и будущие. Версия обычно определяется такими критериями, как возможности взаимодействующих серверов.
Дополнительные ресурсы
- Объяснение кодов ошибок SMTP Yahoo - 1 мая 2024 г.
- SPF Softfail и Hardfail: В чем разница? - 26 апреля 2024 г.
- ФТК сообщает, что электронная почта является популярным средством мошенничества, выдающего себя за человека - 16 апреля 2024 г.