DKIM: подписано отправителем

Автор статьи: Александр Венедюхин, ведущий аналитик ТЦИ

DKIM – Domain Keys Identified Mail (дословно: «почтовая идентификация по доменным ключам», RFC 6376) – технология, позволяющая проверить полномочия почтового сервера, который доставляет почтовые сообщения (email) из того или иного почтового домена. Это основанный на электронной подписи способ аутентификации технического отправителя, который помогает решать задачи обнаружения писем с «поддельным» адресом отправителя.

DKIM не стоит путать с S/MIME и другими механизмами подписывания содержания сообщений почты пользователем (а точнее – почтовым клиентом). DKIM использует похожий механизм, но работает не на клиенте, а между серверами, на техническом уровне. Другими словами, в DKIM идентификация автора сообщения полностью отделена от идентификации подписывающей стороны, в качестве которой выступает почтовая система. При этом в DKIM нет иерархии удостоверяющих центров или другой подобной внешней структуры – ключи привязываются к доменам с помощью DNS (спецификация DKIM написана так, что, в теории, есть возможность распределять ключи DKIM без DNS, но такой способ не используется). Обычному пользователю подписи DKIM, как и механизмы их проверки, не видны, но вот на доставку сообщений они влияют непосредственно.

Контекст безопасности

Подписи DKIM полезны и сами по себе, однако лучше работают в связке с параметрами DMARC и SPF. Первая аббревиатура - название технологии публикации политик обработки сообщений. DMARC расшифровывается как Domain-based Message Authentication, Reporting, and Conformance (дословно: «доменная аутентификация сообщений, отчёты и исполнение/соответствие»). Вторая аббревиатура, SPF (Sender Policy Framework – «критерии политики отправки»), позволяет связать с именем почтового домена сетевые параметры отправляющего сервера.

Все три технологии, - DKIM, DMARC, SPF, – работают на базе доменной системы имён (DNS). При этом, с точки зрения использования DNS, DKIM задействуется в роли дополнения, придающего смысл и DMARC, и SPF. То есть DKIM позволяет серверу-получателю проверить то, что сервер-отправитель имеет отношение к конкретному почтовому домену, при помощи DMARC администратор доменной зоны публикует рекомендации по обработке сообщений на стороне получателя, а SPF – это способ задания разрешённых сетевых адресов почтовых серверов, который связывает доставку электронной почты непосредственно с сетевым транспортом. Данные всех этих трех систем публикуются в TXT-записях DNS. Такая конфигурация сложилась и используется потому, что электронная почта в Интернете – это децентрализованная система (см. рис. 1).

Рис. 1. Логическая схема доставки сообщений электронной почты и DKIM

При отправке сообщения почтовый сервер, обслуживающий клиента-отправителя, находит сервер-получатель при помощи доменной системы имён. В электронной почте сервер-получатель – это сервер, который принимает почтовые сообщения для почтового домена. То есть для домена, указанного справа в адресе, конкретный сервер действует независимо от других почтовых серверов, обслуживающих другие домены. Более того, серверы для отправки сообщений с адресами в заданном домене и серверы, принимающие email-сообщения в этот же домен, нередко являются разными серверами. Для того, чтобы доставляющий почту сервер мог определить, к какому конкретно узлу обратиться, в DNS для обозначения почтовых серверов домена выделен специальный тип записи – MX-запись (Mail eXchange). Собственно, DNS и задумывалась как инструмент, облегчающий, кроме прочего, запись адресов электронной почты (до DNS адреса и пути доставки указывались совсем другим методом).

Таким образом, логическая архитектура системы доставки электронной почты выводится из механизма поиска принимающего сервера по имени домена, и в этой архитектуре нет никакого «центрального управляющего сервера». Полезно сравнить архитектуру email с архитектурой того или иного популярного современного мессенджера (один из самых известных - Telegram), где доставка сообщений между пользовательскими аккаунтами полностью производится внутри одного «центрального сервера» (здесь имеется в виду логический сервер, который, конечно, может состоять из сотен отдельных физических узлов). В подобном централизованном мессенджере задачу проверки/аутентификации технического отправителя, аналогичную задаче DKIM, решает сам центральный сервер, так как он же и доставляет сообщения (см. рис. 2). Существуют мессенджеры с полностью распределённой архитектурой, схема аутентификации в которых очень похожа на механизм публикации открытых ключей DKIM, однако их рассмотрение находится за рамками данной статьи.

Рис. 2. Логическая схема доставки сообщений в централизованном мессенджере

В распределённой архитектуре почтовых доменов состоит важное преимущество электронной почты, но без дополнительных механизмов безопасности эта же архитектура несёт и определённые риски. Так, попытаться доставить на сервер-получатель сообщение, обратный адрес для которого находится в произвольном домене, может не менее произвольный сервер – верхнеуровневый протокол доставки (SMTP) этому никак не мешает. Вообще, если задуматься над подходами к проектированию протоколов, то быстро начинает казаться, что в старом Интернете все друг другу старались верить на слово, и даже в тех случаях, когда верить предлагается серверу. Отчасти, раньше так и было. К сожалению, уже много лет назад ситуация поменялась кардинально.

Вернёмся к протоколам электронной почты, которые являются одними из самых древних в Интернете. Только что описанная проблема «подделки» адреса отправителя известна как «проблема спуфинга email-сообщений»: недобросовестный сервер может принести получателю сообщение, в котором адрес отправителя будет содержать «чужой» для реального отправителя, но хорошо знакомый для получателя домен. При этом письмо было отправлено без ведома пользователя, которому принадлежит почтовый ящик, указанный в качестве ящика отправителя. Например, в корректно работающем централизованном мессенджере возникновению такой ситуации мешает то, что всякий пользователь должен быть авторизован в общей системе, прежде чем он сможет отправлять сообщения.

Проблеме спуфинга в email несколько десятков лет, однако актуальность её не уменьшается: отправка фиктивных писем используется и при массовой рассылке нежелательных сообщений, и в ходе целевых фишинговых атак (в последнем случае – часто с гораздо большим успехом). Отправка сообщений «с чужим обратным адресом» возможна потому, что процесс получения почтового сообщения не требует установления некоторой строгой логической связи между принимающим сервером и отправляющим доменом. Установление такой связи через DNS как раз и является задачей DKIM (и, отчасти, SPF).

Доставка с подписью

Подготовка к использованию DKIM в почтовом домене сводится к созданию ключевой пары (секретный и открытый ключи) с публикацией открытого ключа в DNS под специальным именем, находящимся в защищаемом домене. Например, если имя почтового домена test.ru, то открытый ключ может быть размещён в TXT-записи key2023._domainkey.test.ru. Здесь _domainkey задаёт выделенную область адресов для DKIM в DNS – это обязательная часть (обратите внимание на символ «нижнее подчёркивание»). Префикс, находящийся слева от _domainkey, - в нашем примере это key2023, - является селектором для конкретного ключа (или ключей) и передаётся в сообщениях электронной почты, которые сервер отправляет с защитой DKIM. То есть данный селектор может быть разным для разных серверов (если они используют разные ключи, например), а может быть и разным для разных писем. Возможны и другие варианты, когда используются различные значения данного селектора (выбор ключей по времени, по домену получателя и т.д.). Для отправки сообщений с корректной DKIM-подписью почтовому серверу требуется доступ к закрытому ключу (либо, если говорить строго, к интерфейсу, обеспечивающему операцию вычисления подписи).

При отправке почтовый сервер указывает вычисленную подпись в специальном заголовке технического конверта (название заголовка - DKIM-Signature). Технически сообщение электронной почты представляет собой набор текстовых строк, часть из которых играет сугубо служебную роль и отражает как параметры и формат самого текста (тела) сообщения, так и путь доставки, сопроводительную информацию – эта совокупность и есть «технический конверт». «Заголовками» принято называть технические строки, предшествующие телу сообщения. Формат представления письма вместе с техническим конвертом достаточно строго определён спецификациями, поэтому почтовые программы и почтовые серверы справляются с его автоматической обработкой. Просмотреть заголовки или весь конверт целиком можно в большинстве почтовых клиентов или систем веб-почты (пункты меню «Исходное сообщение» и пр.).

Таким образом, значение электронной подписи DKIM преобразуется в текстовую форму (кодирование Base64) и встраивается сервером непосредственно в техническую часть письма. Это происходит после того, как письмо покинуло почтовый клиент отправителя, но до того, как письмо поступило на принимающий сервер (или, в ряде случаев, на промежуточный почтовый релей).

Электронная подпись DKIM отправляющим сервером вычисляется для набора заголовков технического конверта и для тела письма (с некоторыми ограничениями по нормализации и длине, которые рассмотрены ниже). В типичном сообщении электронной почты заголовков, кроме относящихся к DKIM, может быть достаточно много. Часть из них добавляется в процессе доставки письма другими серверами, не сервером-отправителем. DKIM позволяет защитить подписью только те заголовки, которые посчитал важными администратор почтовой системы, за исключением обязательных (From). Этот набор может быть, например, таким: Subject:From:To:Date (двоеточие – разделитель) - здесь выбраны «Тема письма» (Subject), «Отправитель» (From), «Получатель» (To), «Дата» (Date). Подпись защищает указанные заголовки от изменения. Важно отметить, что защита заголовков составляет важный элемент практики DKIM, а конкретный процесс формирования списка заголовков для почтовой системы достаточно сложный и, как говорится, многогранный, с массой особенностей, которые остались за пределами статьи. Таким образом, формируя сообщение, сервер-отправитель добавляет в его состав криптографическое подтверждение того, что этому серверу известен секретный ключ, соответствующий открытому ключу почтового домена. Это и есть механизм, привязывающий легитимный сервер-отправитель к домену.

Распространённый вопрос, иногда вызывающий споры: обязательно ли подпись DKIM закрывает тело сообщения? В большинстве случаев, да, закрывает. Но с особенностями. Тело сообщения «подмешивается» в защищаемые данные отдельно, через дополнительную итерацию хеш-функции. При этом в заголовке DKIM-подписи есть параметр, задающий длину той части тела сообщения, которая учитывается при вычислении значения хеш-функции, то есть действительно попадает в защищаемые данные. Поэтому, согласно спецификации, электронной подписью DKIM может охватываться только часть самого текста сообщения. Более того, можно установить нулевую длину этой части, полностью исключив тело из подписи. Всё это означает, что, в принципе, к сообщению могут быть дописаны какие-то символы, а подпись DKIM (с параметром длины!) останется корректной. Однако по умолчанию учитывается всё тело сообщения, так что, если не предпринимать специальных мер, DKIM закрывает весь текст – в таком случае дописать какие-то «ссылки», не нарушив целостность, не выйдет. Более того, соответствующий RFC 6376 вообще не рекомендует использовать указание длины в параметрах DKIM для подписываемых сообщений, а современный валидатор DKIM, в принципе, может считать некорректными подписи с подобным ограничением (что, понятно, не добавляет надёжности).

Сервер-получатель, который принимает письмо, для проверки DKIM должен обнаружить в нём заголовок DKIM-подписи. Это достаточно важный аспект: чтобы начать «проверять DKIM» сервер должен получить письмо полностью. Отказаться от получения письма «с плохим DKIM» сервер не может в принципе. Другое дело, что после проверки письмо может быть отброшено и не попадёт к пользователю, не будет занимать место в очередях и почтовых ящиках. Однако считать, что DKIM строго предотвращает получение сообщения, – не верно. Только что описанная особенность, конечно, может показаться очевидной, однако почтовые системы используют ряд мер, позволяющих отказаться от получения нежелательных писем ещё на самом раннем этапе процесса доставки, без необходимости приёма самого сообщения. И некоторые из этих мер весьма не очевидные: в качестве примера – статистика времени ожидания ответа почтового сервера на Statdom.ru.

Итак, приняв сообщение с DKIM-подписью, сервер-получатель может эту подпись проверить. Для проверки требуется открытый ключ, который сервер извлекает из DNS, сконструировав по определённому алгоритму нужное имя. Это имя содержит домен авторизации и селектор, прочитанный в заголовке DKIM-Signature (см. выше). В простейшем случае, если домен отправителя test.ru, а селектор в заголовке DKIM – mail, сервер обратится за ключом по имени mail._domainkey.test.ru. Успешно получив открытый ключ, сервер может собрать на своей стороне копию подписываемых данных и проверить значение подписи. Если значение сошлось, то сервер считает, что проверка DKIM прошла успешно (и наоборот). Сейчас, в подавляющем большинстве случаев, криптосистемой подписи DKIM будет RSA – другие, более современные, варианты ещё не получили распространения.

По результатам проверки DKIM принимающий сервер может предпринять какие-то дополнительные действия. Здесь ключевое слово – «может». Дело в том, что DKIM или DMARC, а также SPF - это не более чем рекомендательные инструменты. Каких-то реальных технических рычагов, влияющих на работу принимающего сервера, в этих технологиях нет. Как упоминалось выше, публикация ключей DKIM, публикация политики DMARC не обязывают другие стороны процесса доставки электронной почты следовать этим предписаниям. Принимающий сервер может поддерживать DKIM, но не предпринимать никаких дополнительных действий для сообщений с DKIM-подписью, кроме дописывания результатов проверки в технический конверт. Другие серверы могут просто игнорировать DKIM. Естественно, в 2023 году настройка DKIM является скорее обязательным требованием для отправки сообщений email, но обязательность требования - не техническая.

Сопроводительные DNS-документы

Принимающий сервер может получить из DNS описание политик, которые администратор почтового домена-отправителя рекомендует применять для входящих писем. Это делается при помощи DMARC. Данная технология позволяет задать несколько параметров для обработки сообщений. Мы остановимся только на значении, собственно, политики: none, quarantine, reject. Это три уровня рекомендаций: none – не делать ничего (данный вариант, понятно, не зависит от результата проверки DKIM); quarantine – если проверка DKIM не прошла, то сообщение нужно отнести к нежелательным (например, переместить в папку «Спам» на стороне пользователя); reject – отбрасывать сообщения, не прошедшие проверку DKIM. При этом самое строгое значение, reject, как раз и означает, что пользователь (возможно) просто не увидит адресованное ему сообщение. Более того, и отправитель не получит никаких сообщений о сбое доставки (последний момент, конечно, актуален только для неверно настроенного DKIM, в других случаях адрес отправителя всё равно был «подделан»). DMARC публикуется в DNS, в TXT-записи с фиксированным префиксом _dmarc. Например, если домен отправителя test.ru, то DMARC соответствует _dmarc.test.ru. Принимающий сервер не обязан исполнять политики DMARC. Он может обрабатывать сообщение по каким-то своим внутренним алгоритмам, о которых администратору домена-отправителя ничего не известно.

SPF - ещё один элемент настройки доставки почты, связанный с DKIM и DMARC, который необходимо упомянуть. SPF – это способ определения перечня IP-адресов узлов, которые могут доставлять сообщения, относящиеся к данному почтовому домену. В большинстве случаев SPF используется самым простым способом: в соответствующей TXT-записи указывается IP-адрес почтового сервера, обслуживающего данный домен на отправку сообщений, а также модификатор, запрещающий или понижающий в приоритете все остальные адреса («-all/~all»). При этом спецификация SPF допускает довольно экзотические настройки, в том числе «макросы», поэтому распространённое мнение, что SPF – «всего лишь список IP-адресов», в целом, не верное. Принимающий почтовый сервер знает IP-адрес отправляющего сервера, так как последний устанавливает TCP-соединение для доставки сообщения. IP-адрес принимающий сервер может сравнить с параметрами SPF домена, получив запись из DNS. Прямого отношения к DKIM данная технология не имеет, однако SPF играет важную роль в самом процессе проверки отправителя, а в DMARC предусмотрен параметр, определяющий то, с каким «уровнем строгости» почтовый сервер должен обрабатывать данные SPF. TXT-записи с SPF публикуются непосредственно под именем почтового домена, реже - под техническим доменом (в SPF есть и много других «особенностей адресации»). В простейшем случае, если письмо доставляется с обратным адресом в test.ru, то и начальную SPF-запись сервер запрашивает для test.ru.

Вся описанная схема, включая DKIM, DMARC и SPF, как и в очень многих других случаях, полностью зависит от доверия DNS: сторона, контролирующая DNS, может разместить нужные ключи, подменить селектор, сгенерировать собственную подпись DKIM, заменить адрес в SPF, а также провести массу других атак. В существенной мере проблему управления доверием тут могла бы решить технология DNSSEC, но она не очень распространена.

DKIM - весьма непростая в работе и настройке технология. Особенная осторожность тут требуется потому, что неверно настроенный DKIM приводит к тому, что не доставляются не только сообщения со «спуфингом», но и вполне подлинные, корректные во всех прочих отношениях, сообщения. При первой настройке DKIM рекомендуется установить нестрогую политику DMARС – quarantine (а возможно, даже none). Кроме того, рекомендуется снизить «долю применения» политики (актуально для quarantine и reject) при помощи параметра pct и обязательно корректно настроить адрес для приёма отчётов о DKIM-сбоях от внешних почтовых серверов (параметры rua/ruf). И конечно, просматривать полученные отчёты силами администратора почтовой системы.