Всеобъемлющая безопасность электронной почты в Интернете

Электронной почтой пользуются повсеместно и организации, и частные лица. При этом сама электронная почта уязвима к целому ряду угроз безопасности. Угрозы безопасности электронной почты можно весьма общо разбить на следующие категории:

  • Угрозы аутентичности: могут привести к несанкционированному доступу к корпоративной системе электронной почты. Сюда же относится обман адресата, т.е. ситуация, когда отправитель письма выдает себя за другого.
  • Угрозы целостности: могут привести к несанкционированному изменению содержимого электронного письма.
  • Угрозы конфиденциальности: могут привести к несанкционированному разглашению конфиденциальной информации.
  • Угрозы доступности: могут перекрыть конечным пользователям возможность получать или отправлять электронную почту.

Для содействия борьбе с этими категориями угроз Национальный институт стандартов и технологии (National Institute of Standards and Technology, NIST) опубликовал документ SP 800-177[1], в котором содержатся рекомендации по укреплению доверия к электронной почте. Этот документ представляет собой одновременно обзор имеющихся стандартизованных протоколов и набор рекомендаций по использованию этих протоколов для того, чтобы противостоять угрозам безопасности электронной почты.

Для лучшего понимания тем, излагаемых в настоящей статье, целесообразно иметь общее представление об архитектуре электронной почты в Интернете. В настоящее время она определяется стандартом RFC 5598[2]. Начнем с обзора основных концепций.

На самом фундаментальном уровне архитектура электронной почты в Интернете состоит из «мира пользователей» в виде почтовых агентов (Message User Agent, MUA) и «мира передачи» в виде службы обработки сообщений (Message HandlingService, MHS), состоящей из агентов пересылки сообщений (Message Transfer Agent, MTA). MHS получает сообщение от пользователя и доставляет его одному или нескольким другим пользователям, создавая виртуальную среду обмена данными MUA-MUA. Эта архитектура включает в себя три типа взаимодействия.Первое – непосредственно между пользователями: MUA должен форматировать сообщения от имени автора так, чтобы MUA получателя мог показать их адресату в читабельном виде. Также требуется взаимодействие между MUA и MHS – сначала тогда, когда MUA передает сообщение MHS, а потом когда MHS доставляет его MUA получателя. Также требуется взаимодействие между компонентами MTA по пути передачи сообщения по MHS.

На рис. 1 показаны основные компоненты почтовой архитектуры Интернета, в том числе следующие:

  • Почтовый агент (MUA): работает от имени пользователей и приложений пользователей. Является их представителем в почтовом сервисе. Как правило, эта функция расположена на компьютере пользователя и называется почтовым клиентом – либо в локальной сети и называется локальным почтовым сервером. MUA автора форматирует сообщение и выполняет первоначальную передачу его в MHS посредством агента отправки почты (Mail Submission Agent, MSA). MUA получателя получает почту для хранения или показа пользователю-адресату.
  • Агент отправки почты (MSA): получает сообщение, отправленное MUA, и применяет политики хостингового домена и требования стандартов Интернета. Эта функция может располагаться вместе с MUA или быть реализована в качестве отдельной функциональной модели. В последнем случае для передачи данных между MUA и MSA используется протокол SMTP.
  • Агент пересылки сообщений (MTA): передает сообщения на следующий узел почтовой системы. Он похож на коммутатор пакетов или IP-маршрутизатор, в том смысле, что его задача – осуществлять оценку маршрутизации и передавать сообщения ближе к адресату. Несколько MTA последовательно пересылают сообщение, пока оно не достигнет нужного MDA. Кроме того, MTA дописывает в заголовок сообщения информацию о трассировке. Для обмена данными между разными MTA, а также между MTA и MSA/MDA, используется протокол SMTP.
  • Агент доставки почты (Mail Delivery Agent, MDA): MDA отвечает за передачу сообщений от MHS в хранилище сообщений (Message Store, MS).
  • Хранилище сообщений (MS): MUA может использовать долгосрочный MS. MS может располагаться на удаленном сервере или же на той же самой машине, что и MUA. Как правило, MUA извлекает сообщения с удаленного сервера с помощью протокола POP (Post Office Protocol) или IMAP (Internet Message Access Protocol).

Рис. 1. Функциональные модули и стандартные протоколы в почтовой архитектуре Интернета.

Как мы скоро увидим, важным элементом обеспечения безопасности почты является шифрование с открытым ключом. В свою очередь, использование шифрования с открытым ключом зависит от использования сертификатов открытого ключа. В сущности,сертификат открытого ключа состоит из а) самого открытого ключа и б)идентификатора пользователя, принадлежащего владельцу ключа, а весь блок подписывается доверенной третьей стороной. Обычно открытые ключи создаются и используются с помощью такого третьего лица, как центр сертификации (CertificateAuthority, CA). CA – это организация, пользующаяся доверием сообщества пользователей, например, государственное или финансовое учреждение. Перечислим основные элементы в схеме CA:

  1. Клиентское ПО создает пару ключей: один открытый и один закрытый. Клиент подготавливает неподписанный сертификат, в который входят ID пользователя и его открытый ключ.Затем клиент отправляет неподписанный сертификат безопасным способом в CA.
  2. CA генерирует подпись, вычислив хэш-сумму неподписанного сертификата и зашифровав хэш закрытым ключом CA; зашифрованный хэш называется подписью, или сигнатурой (signature). CA дописывает полученную подпись к неподписанному сертификату, а затем отправляет подписанный таким образом сертификат клиенту.
  3. Клиент может отправить свой подписанный сертификат любому другому пользователю. Этот пользователь может проверить действительность сертификата, вычислив его хэш (без подписи), расшифровав подпись с помощью открытого ключа CA и сравнив хэш с расшифрованной подписью.

Если все пользователи подписывают свои сертификаты в одном и том же CA, это означает, что такой CA пользуется общим доверием. Все сертификаты пользователей можно поместить в каталог для доступа всем пользователям. Кроме того, пользователи могут напрямую передавать свои сертификаты друг другу. В любом случае, когда пользователь Bполучает сертификат пользователя A, то B убежден, что сообщения, которые он подпишет открытым ключом A, будут защищены от прослушивания и что сообщения,подписанные закрытым ключом А, будет невозможно подделать.

Если сообщество пользователей достаточно велико, работать всем с одним и тем же CA может быть нецелесообразно. Дело в том, что поскольку все сертификаты подписаны тем же самым CA, то у каждого пользователя-участника должна быть копия открытого ключа самого CA – она нужна ему для проверки подписей. И такой открытый ключ должен быть передан каждому пользователю абсолютно безопасным способом (в отношении целостности и аутентичности), чтобы пользователь доверял сертификатам этого CA.

Получается, что когда пользователей достаточно много, имеет смысл завести несколько CA, каждый из которых рассылал бы свой открытый ключ той или иной части пользователей. На практике существует не один CA, а целая иерархия. Такая система усложняет вопросы рассылки ключей и доверия, но основные принципы остаются теми же самыми.

Следует упомянуть ряд проблем, связанных с CA. Как можно понять из предыдущего абзаца, иерархическая структура CA может стать неуклюжей и плохо масштабироваться. Тем не менее, эта структура до сих пор является предпочтительной и рекомендуется стандартом SP800-177. Также есть отдельный вопрос безопасности. Глобальная система CA в последние годы становилась мишенью для атак, среди которых было и несколько успешных. Один из способов защитить CA от компрометации – это использование системы имен доменов (DNS), чтобы домены могли выбирать для себя желательные сертификационные СА или вендоров СА. А такое использование DNS требует, чтобы сама DNS была защищена с помощью DNSSEC (Domain Name System Security Extensions), как описано ниже.

Пользователи, не знакомые с криптографией открытого ключа, концепциями аутентификации и цифровых подписей – либо желающие освежить свои знания по этому вопросу, – могут ознакомиться с информационным документом Crypto Portal, содержащим краткое и простое изложение темы. Полезный обзор концепций CA и сертификата открытого ключа содержится в NIST SP 800-32[4].

Доверенная электронная почта

В SP 800-177 описаны и рекомендованы следующие протоколы и стандарты:

  • STARTTLS: расширение безопасности SMTP, позволяющее клиенту и серверу SMTP договориться об использовании TLS (Transport Layer Security) для того, чтобы наладить закрытый обмен данными с аутентификацией по Интернету.
  • S/MIME (Secure Multipurpose Internet Mail Extensions): обеспечивают аутентификацию, целостность, невозможность отказа (nonrepudiation, посредством цифровых подписей) и конфиденциальность (посредством шифрования) сообщений SMTP.
  • DANE (DNS-Based Authentication of Named Entities): предназначен для исправления недостатков системы центров сертификации (CA) за счет создания альтернативного канала аутентификации открытых ключей на основе DNSSEC. В результате те же самые отношения доверия, которые используются для сертификации IP-адресов, используются для сертификации серверов, работающих по этим адресам.
  • SPF (Sender Policy Framework): позволяет владельцу домена указать IP-адреса MTA, уполномоченных отправлять почту от имени домена. SPF использует DNS для того, чтобы владельцы доменов могли создавать записи, связывающие доменное имя с конкретным диапазоном IP-адресов или уполномоченных MTA. Получатель просто сличает текстовую запись SPF (TXT) в DNS, чтобы проверить, имеет ли право предполагаемый отправитель сообщения использовать такой исходный адрес. Почта, поступающая не с уполномоченных IP-адресов, отбрасывается.
  • DKIM (DomainKeys Identified Mail): позволяет «акторам» электронной почты (авторам или операторам) надежно приписать к сообщению свое доменное имя с помощью криптографических методов, чтобы механизмы фильтрации могли выработать точную репутацию домена. MTA могут подписывать выбранные заголовки и тело сообщения. Такая подпись подтверждает исходный домен письма и обеспечивает целостность тела сообщения.
  • DMARC (Domain-basedMessage Authentication, Reporting, and Conformance): публикует требование того, чтобы доменное имя автора было аутентифицировано по DKIM и/или SPF, чтобы владелец домена затребовал от получателя обработку неаутентифицированной почты с помощью этого домена, а также механизм отчетности для отправки отчетов от получателей владельцам доменов. DMARC сообщает отправителям о пропорциональной эффективности их политик SPF и DKIM, а также сигнализирует получателям, какие действия нужно предпринять в различных ситуациях индивидуальных и массовых атак.

На рис. 2 показано, как эти компоненты взаимодействуют между собой, обеспечивая аутентичность и целостность сообщения. Для простоты не показано, что S/MIME также обеспечивает конфиденциальность сообщений путем их шифрования. Вместе эти протоколы обеспечивают всеобъемлющую стратегию безопасности электронной почты в Интернете. В этой статье мы приведем обзоры каждого из них.

Рис. 2. Взаимосвязь DNSSEC, SPF, DKIM, DMARC, DANE и S/MIME для обеспечения аутентичности и целостности сообщений.

STARTTLS:

Существенным обновлением безопасности SMTP стал STARTTLS, определенный в RFC 3207[5]. STARTTLS позволяет добавить к обмену данными между агентами SMTP конфиденциальность и аутентификацию. Благодаря этому агенты SMTP могут защитить часть своей коммуникации или всю ее от прослушивания и атак, установив сеанс TLS (Transport Layer Security) в рамках соединения SMTP. STARTTLS широко используется. Его поддерживают Amazon, Facebook, Google, Microsoft, Yahoo и другие[6]. В 2014 Facebook (которая ежедневно рассылает миллиарды почтовых сообщений) провела исследование, обнаружившее, что 76% имен хостов, получающих почту от Facebook, поддерживают STARTTLS[7].

TLS – это уровень безопасности, реализуемый прямо поверх TCP. TLS – это стандарт Интернета, пришедший на замену Secure Sockets Layer (SSL) и обладающий практически тем же функционалом[8]. При использовании TLS у приложения есть адрес сокета TLS и оно взаимодействует с сокетом адреса TLS у удаленного приложения. Эти адреса отличаются от адресов, используемых теми же приложениями при работе непосредственно поверх TCP. Функции безопасности TLS прозрачны для приложения и для TCP. Поэтому ни TCP, ни приложение не нужно модифицировать для внедрения функций безопасности SSL. TLS обеспечивает три категории: безопасность, конфиденциальность и аутентификацию.

Если клиент не начинает соединение через порт с поддержкой TLS, сервер может ответить сообщением, указывающим, что возможен вариант STARTTLS.

Тогда клиент может отдать команду STARTTLS в потоке команд SMTP, и обе стороны установят безопасное подключение TLS. STARTTLS сейчас работает у многих поставщиков услуг электронной почты и на многих почтовых серверах [9, 10], включая Amazon, Comcast, Dropbox, Facebook, Google, Microsoft и Yahoo.

Как описано в SP800-177, STARTTLS может быть уязвим к атакам типа «промежуточное звено» или MITM (Man-In-The-Middle), когда инициируется по запросу сервера. В этом случае «промежуточное звено» получает запрос STARTTLS с сервера в ответ на запрос соединения и вычеркивает его.  

Запросивший клиент не видит запрос о переходе на TLS и продолжает работать с незащищенным соединением. Однако авторы SP 800-177 решили, что какая-то защита лучше, чем никакой, а потому до тех пор, пока TLS не станет повсеместным и не будет активироваться автоматически, серверы с поддержкой TLS должны предлагать клиентам применить команду STARTTLS. Клиенты TLS должны пытаться либо сразу использовать STARTTLS, либо отдать эту команду по запросу.

S/MIME

Secure/MultipurposeInternet Mail Extension (S/MIME)– это безопасное дополнение к интернет-стандарту электронной почты MIME[11]. S/MIME – это комплексная функция, определенная во многих документах. Наиболее важные документы, описывающие S/MIME, включают следующие[12−19]:

  • RFC5750, S/MIME Version 3.2 Certificate Handling: описывает соглашения по использованию сертификата X.509 в S/MIME v3.2.
  • RFC5751, S/MIME Version 3.2 Message Specification: основной определяющий документ для создания и обработки сообщений S/MIME.
  • RFC4134, Examples of S/MIME Messages: примеры тел сообщений, отформатированных с использованием S/MIME.
  • RFC2634, Enhanced Security Services for S/MIME: описывает четыре дополнительных расширения безопасности для S/MIME.
  • RFC5652, Cryptographic Message Syntax (CMS): описываетCMS. Этот синтаксис служит для цифрового подписания, генерации дайджеста, аутентификации и шифрования произвольного содержимого сообщений.
  • RFC3370, CMS Algorithms: описывает соглашения по использованию нескольких криптографических алгоритмов с CMS.
  • RFC5752, Multiple Signatures in CMS: описывает использование нескольких параллельных подписей в сообщении.
  • RFC1847, Security Multiparts for MIME — Multipart/Signed and Multipart/Encrypted: описывает систему, в рамках которой можно применять службы безопасности к частям тел сообщений MIME. Использование цифровых подписей важно для S/MIME, как мы покажем ниже.

Функционал S/MIME встроен в большинство современных почтовых программ и средств взаимодействия между ними. S/MIME реализует четыре службы для почты: аутентификацию, конфиденциальность, сжатие и совместимость почты.

Аутентификация осуществляется с помощью цифровой подписи. Обычно это RSA с SHA-256. Последовательность следующая:

  1. Отправитель создает сообщение.
  2. С помощью SHA-256 генерируется 256-разрядный дайджест сообщения.
  3. Дайджест шифруется по RSA закрытым ключом отправителя, результат приписывается к сообщению. Также к нему приписывается идентификационная информация подписавшего, которая позволит получателю извлечь нужный открытый ключ.
  4. Получатель расшифровывает и восстанавливает дайджест сообщения по RSA с помощью открытого ключа отправителя.
  5. Получатель генерирует новый дайджест сообщения и сравнивает его с расшифрованным хэшем. Если они совпадают, сообщение признается подлинным.

Комбинация SHA-256 иRSA дает эффективную схему применения цифровой подписи. Поскольку RSA – очень сильный алгоритм, получатель может быть уверен, что цифровая подпись могла быть создана только обладателем парного закрытого ключа. А благодаря применению мощного SHA-256 получатель может быть уверен, что никто больше не смог бы создать новое сообщение, которое совпадает с хэшем, а следовательно, с подписью исходного сообщения.

Хотя цифровые подписи обычно хранятся приписанными к сообщению или файлу, подписанному ими, это не всегда так: поддерживаются и отдельные подписи. Отдельная подпись (detachedsignature) может храниться и передаваться отдельно от подписанного ею сообщения. Этот вариант полезен в целом ряде ситуаций. Например, пользователь может вести отдельный журнал подписей всех отправленных или полученных сообщений. Другое соображение – отдельная подпись исполняемой программы может обнаруживать последующее заражение вирусом. И, наконец, отдельные подписи можно использовать в случае, когда документ (например, юридический контракт) должны подписать несколько сторон. Подпись каждого лица независима и потому применяется только к документу. В противном случае пришлось бы вкладывать подписи, как матрешки: второе лицо подписывало бы и документ, и подпись первого, и так далее.

S/MIME обеспечивает конфиденциальность путем шифрования сообщений секретным ключом, известным также как симметричный ключ (symmetric key). Чаще всего используется AES (Advanced Encryption Standard) со 128-разрядным ключом в режиме CBC (Cipher Block Chaining). Сам ключ также зашифрован, обычно по RSA, как объясняется ниже.

Как всегда, нужно решить проблему рассылки ключей. В S/MIME каждый симметричный ключ, называемый ключом шифрования контента (content-encryption key), используется только один раз. Это значит, что для каждого нового сообщения генерируется новый случайный ключ. Поскольку ключ шифрования контента одноразовый, он привязан к сообщению и передается вместе с ним. Для защиты ключа он зашифровывается открытым ключом получателя.

Последовательность действий выглядит так:

  1. Отправитель генерирует сообщение и случайное 128-разрядное число, которое станет ключом шифрования контента для этого сообщения и только для него.
  2. Сообщение зашифровывается сгенерированным ключом шифрования контента.
  3. Ключ шифрования контента шифруется по RSA открытым ключом получателя, результат приписывается к сообщению.
  4. Получатель расшифровывает и восстанавливает ключ шифрования контента по RSA собственным закрытым ключом.
  5. Сообщение расшифровывается ключом шифрования контента.

Рис. 3. Упрощенная функциональная схема S/MIME.

Как видно на рисунке 3, для одного и того же сообщения реализуются и конфиденциальность, и шифрование. На рисунке показана последовательность, в которой для простого текстового сообщения генерируется подпись и добавляется к сообщению. Затем и текстовое сообщение, и подпись зашифровываются единым блоком с помощью симметричного шифрования, а ключ симметричного шифрования зашифровывается открытым ключом.

В S/MIME операции подписания и шифрования сообщения могут выполняться в любом порядке. Если сообщение сначала подписывается, идентичность отправителя оказывается скрыта шифрованием. Кроме того, обычно гораздо удобнее хранить подпись с текстовой версией сообщения. Также, для целей верификации третьими сторонами, если сначала выполняется подписание, то третьей стороне не нужно возиться с симметричным ключом во время проверки подписи.

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

При использовании S/MIME хотя бы часть передаваемого блока зашифрована. Если используется только служба подписи, то шифруется дайджест сообщения (закрытым ключом отправителя). Если используется служба конфиденциальности, то шифруется и сообщение, и подпись (если есть) — разовым симметричным ключом. Поэтому часть всего получившегося блока состоит из потока произвольных 8-разрядных октетов. Однако многие системы электронной почты могут работать только с блоками, содержащими текст в кодировке ASCII. Для совместимости S/MIME содержи службу, которая преобразует сырой 8-битовый двоичный поток в поток печатаемых символов ASCII. Этот процесс называется 7-битной кодировкой (7-bit encoding). Для этой цели, как правило, используется преобразование Base64. Каждая группа из трех октетов двоичных данных преобразуется в четыре символа ASCII.

S/MIME также может выполнять сжатие сообщения. Сжатие позволяет сэкономить место и при передаче почты, и при хранении файлов. Сжатие можно применять в любой момент относительно подписания и шифрования.

RFC 5751 содержит следующие директивы:

  • Сжатие зашифрованных данных в двоичной кодировке не рекомендуется, поскольку большого эффекта не даст. В то же время данные в кодировке Base64 сжимаются прекрасно.
  • Если используется алгоритм сжатия данных с потерями, а также подписание, то сначала следует сжимать, а потом подписывать.

SP 800-177 рекомендует использовать аутентификацию по цепочке сертификатов от известного центра сертификации. Кроме того, в SP 800-177 сказано, что пользователи, которым требуется больше уверенности в том, что предоставленный открытый ключ соответствует домену отправителя, могут использовать механизм DANE-S/MIME, при котором можно независимо извлечь сертификат и ключ из DNS и выполнить их аутентификацию по описанному ниже алгоритму DANE.

Кроме того, в SP800-177 отмечается, что MUA обычно используют закрытые ключи S/MIME для расшифровки почтового сообщения при каждом его показе, но в хранилище сообщение хранится зашифрованным. Такой режим не рекомендуется, так как получатели зашифрованных сообщений вынуждены бессрочно хранить свой закрытый ключ. Более разумно расшифровывать сообщения до отправки на хранение. При этом само хранилище целесообразно защитить с помощью адекватных криптографических методов (например, шифрования диска), что даст защиту как для зашифрованной, так и для не зашифрованной почты.

OpenPGP

PGP (Pretty Good Privacy) был разработан Филом Зиммерманом (Phil Zimmermann) в качестве общедоступного бесплатного (freeware) пакета, который позволил бы частным лицам безопасно обмениваться почтовыми сообщениями, не вверяя их защиту никаким организациям. Работы по разработке стандартов Интернета для PGP начались очень давно, приведя в конце концов к появлению OpenPGP. OpenPGP – это проект стандарта Интернета, который обеспечивал бы аутентификацию и конфиденциальность электронной почты. По назначению и функционалу он близок к S/MIME, но использует другие форматы сообщений и ключей, а также другой подход к созданию и применению сертификатов. В SP800-177 перечислено множество проблем OpenPGP, в том числе неудобство пользования, плохая масштабируемость при рассылке ключей и отсутствие аутентификации владельцев ключей. Подробно этот вопрос обсуждается в [24] и [25]. Соответственно, авторы SP 800-177 рекомендуют использовать только S/MIME, а от OpenPGP отказаться.

DNS и DNSSEC

В этом разделе мы приведем краткий обзор DNS и DNSSEC, понимание которых нам понадобится в следующих разделах. Система доменных имен (Domain Name System, DNS) – это служба поиска в каталогах, которая устанавливает соответствие между именем хоста в Интернете и его цифровым IP-адресом. DNS состоит из четырех элементов. Пространство доменных имен имеет древовидную структуру и служит для идентификации ресурсов в Интернете. База данных DNS – это набор записей о ресурсах, собранный в распределенную БД; по идее, каждый узел и каждый лист в дереве пространства имен служит именем для набора данных (например, IP-адрес и сервер имен для данного доменного имени), который хранится в записях ресурсов (Resource Record, RR). Серверы имен – это серверные программы, которые содержат информацию о части древовидной структуры доменных имен и связанных RR. Резолверы (Resolver) – это программы, извлекающие информацию из серверов имен в ответ на запросы клиентов. Типовой запрос клиента выглядит как запрос IP-адреса, соответствующего конкретному доменному имени.

База данных DNS разделена на тысячи зон, которые управляются отдельно и отдельными администраторами. Используя эту базу данных, серверы DNS реализуют службу каталогов «имя-адрес» для сетевых приложений, которым нужно найти тот или иной сервер приложений.

DNSSEC (Domain Name System Security Extensions, расширения безопасности DNS) используются несколькими протоколами, обеспечивающими безопасность электронной почты. DNSSEC обеспечивают сквозную защиту благодаря использованию цифровых подписей, созданных администраторами отвечающих зон и проверенных программами-преобразователями получателя. В частности, DNSSEC устраняют необходимость доверять промежуточным серверам имен и резолверам, которые кэшируют записи DNS, поступающими от администратора отвечающей зоны до того, как они поступят к источнику запроса. DNSSEC состоят из набора новых типов записей ресурсов и ряда модификаций существующего протокола DNS.

В сущности, DNSSEC разработаны для защиты клиентов DNS от поддельных или модифицированных записей ресурсов DNS. Для такой защиты используются цифровые подписи, которые обеспечивают: (1) аутентификацию источника данных, чтобы гарантировать, что RR действительно поступила из правильного источника; и (2) проверку целостности данных, чтобы гарантировать неизменность содержимого RR. Администратор зоны DNS подписывает каждый набор записей ресурсов (Resource Record set или RRset) в зоне и публикует этот набор цифровых подписей, вместе с открытым ключом администратора зоны, в самом DNS.

В DNSSEC доверие к открытому ключу источника (для проверки подписей) устанавливается не путем обращения к третьей стороне или цепочке третьих сторон (как в цепочках PKI [Public-Key Infrastructure]), а благодаря тому, что оно начинается с доверенной зоны (например, корневой) и создает цепочку доверия вплоть до текущего источника ответа. Цепочка создается путем последовательных проверок подписей открытого ключа дочерней зоны своим родителем. Открытый ключ доверенной зоны называется якорем, или точкой доверия (trust anchor).

DANE

DANE (DNS-Based Authentication of Named Entities) [27, 28] – это протокол, который помогает доменам указать, каким сертификатам X.509 (массово используемым для TLS) следует доверять в этом домене. DANE позволяет привязывать сертификаты к именам DNS посредством DNSSEC. Этот протокол был предложен в стандарте RFC 6698[29] как метод аутентификации клиента и сервера TLS без центра сертификации (CA).

Если вкратце, DANE представляет собой альтернативный механизм безопасной рассылки информации о доменных именах с помощью DNS. В DANE определен новый тип записей DNS, который позволяет доменам подписывать заявления о том, какие объекты уполномочены представлять домен. Приложения могут либо использовать эти записи в дополнение к существующей системе CA, либо создать новую цепочку доверия, основанную на DNS.

Основанием для разработки DANE стала уязвимость центров сертификации в глобальной системе инфраструктуры открытого ключа (PKI). Разработчики каждого браузера и каждой операционной системы ведут свой список корневых сертификатов CA, служащих якорями доверия. Эти сертификаты называются корневыми сертификатами (root certificates) ПО и хранятся в его банке корневых сертификатов. Схема PKI позволяет получателю сертификата проследить его вплоть до корня. До тех пор, пока корневой сертификат остается надежным и аутентификация происходит успешно, клиент может поддерживать безопасность соединения. Но если любой центр сертификации в Интернете (а их сотни) окажется скомпрометирован, вся система может рассыпаться, как карточный домик. Хакер может получить закрытый ключ CA, получать сертификаты под фальшивым именем или добавлять фальшивые сертификаты в корневой банк. Глобальная инфраструктура PKI не имеет границ, и компрометация одного лишь центра сертификации подрывает целостность всей системы PKI. Кроме того, в некоторых CA «просто» плохо с практиками безопасности. Например, некоторые CA выдавали wildcard-сертификаты, владельцы которых имеют право выпускать субсертификаты для любого домена или объекта в любой точке земного шара.

DANE предназначен для того, чтобы отойти от системы CA как источника безопасности и заменить ее на DNSSEC. Этот протокол хорошо описан в RFC 6698:

«Протокол DANE (DNS-Based Authentication of Named Entities) предлагает возможность использовать инфраструктуру DNSSEC для хранения и подписания ключей и сертификатов, используемых TLS. DANE задуман как предпочтительная основа для привязки открытых ключей к именам DNS, поскольку лица, поручающиеся за привязку данных открытого ключа к данным DNS, являются теми же лицами, которые отвечают за управление теми самыми именами DNS. Хотя получившаяся система и имеет некоторые оставшиеся уязвимые места с точки зрения безопасности, она ограничивает масштаб заявлений, которые может сделать любое лицо, соответственно масштабу именования, реализованному иерархией DNS. В результате DANE воплощает «принцип наименьших привилегий» в безопасности, который отсутствует в нынешней модели публичных центров сертификации».

В DANE определяется новый тип записей DNS, получивший название TLSA, который может применяться как безопасный метод аутентификации сертификатов SSL/TLS. TLSA позволяет:

  • указать границы того, какой CA может поручиться за сертификат или какой конкретно сертификат конечного объекта PKI валиден;
  • указать,что сертификат службы или CA может быть аутентифицирован напрямую в DNS.

TLSA RR позволяет привязать выпуск и доставку сертификатов к конкретному домену. Владелец серверного домена создает запись ресурсов TLSA, которая идентифицирует сертификат и его открытый ключ. Когда клиент получает сертификат X.509 в процессе установки соединения TLS, он сверяется с TLSA RR для соответствующего домена и сопоставляет данные TLSA с сертификатом в рамках процедуры проверки сертификата на клиенте.

На рис. 4 изображен формат TLSA RR в том виде, в котором она передается запрашивающему. Она состоит из четырех полей. Поле Certificate Usage определяет четыре различных модели использования – для пользователей, которым требуются разные формы аутентификации. Перечислим эти модели:

  • PKIX-TA (ограничение CA): указывает, какимCA можно доверять для аутентификации сертификата службы. Эта модель использования ограничивает круг CA, которые могут выпустить сертификат для данной конкретной службы на хосте. Цепочка сертификатов сервера должна пройти проверку PKIX, которая заканчивается на доверенном корневом сертификате, хранящемся на клиенте.
  • PKIX-EE(ограничение сертификатов служб): определяет, каким конкретно сертификатам служб оконечных объектов можно доверять для той или иной службы. Эта модель использования ограничивает круг оконечных сертификатов, которые могут использоваться для данной конкретной службы на хосте. Цепочка сертификатов сервера должна пройти проверку PKIX, которая заканчивается на доверенном корневом сертификате, хранящемся на клиенте.
  • DANE-TA(задание якоря доверия): указывает управляемый доменом CA, который должен служить якорем доверия. Эта модель использования позволяет администратору имен доменов указать новый якорь доверия – например, если домен выпускает собственные сертификаты силами собственного CA, который вряд ли окажется в наборе якорей доверия конечных пользователей. Цепочка сертификатов сервера самовыпускается и не должна проходить проверку на доверенном корневом сертификате, хранящемся на клиенте.
  • DANE-EE (сертификат, выданный доменом): указывает управляемый доменом CA, который должен служить якорем доверия. Такое использование сертификатов позволяет администратору имен доменов выпускать сертификаты для домена, не привлекая сторонний CA. Цепочка сертификатов сервера самовыпускается и не должна проходить проверку на доверенном корневом сертификате, хранящемся на клиенте.

Рис. 4. Формат передачи TSLA RR.

Первые две модели использования предназначены для того, чтобы сосуществовать с публичной системой CA и усиливать ее. Последние две модели работают без публичных CA.

Поле Selector указывает, нужно ли сопоставлять полный сертификат или только значение открытого ключа. Сопоставление осуществляется между сертификатом, представленным в ходе переговоров TLS, и сертификатом из TLSA RR. Поле Matching Type указывает, как выполняется сопоставление сертификатов. Варианты следующие: полное совпадение, совпадение хэшей SHA-256 и совпадение хэшей SHA-512. Certificate Association Data – это сырые данные сертификата в шестнадцатеричном формате.

DANE может применяться совместно с SMTP поверх TLS, как описано в STARTTLS, чтобы полнее обеспечить безопасность доставки электронной почты. DANE может аутентифицировать сертификат сервера отправки SMTP, с которым взаимодействует пользовательский почтовый клиент (MUA). Также он может аутентифицировать подключения TLS между серверами SMTP (MTA). Использование DANE с SMTP задокументировано в RFC7672[30].

Как уже обсуждалось, SMTP может использовать расширение STARTTLS, чтобы выполнять SMTP поверх TLS, чтобы все почтовое сообщение плюс конверт SMTP оказались зашифрованы. Этот вариант применяется, если обе стороны поддерживают STARTTLS. Даже если для обеспечения конфиденциальности задействован TLS, он уязвим к следующим типам атак:

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

DANE может решить обе проблемы. Домен может использовать наличие TLSA RR в качестве индикатора того,что необходимо шифрование, тем самым устранив возможность злонамеренного отказа от него. Домен может аутентифицировать сертификат, используемый при настройке соединения TLS, с помощью TLSA RR, подписанной по DNSSEC.

DNSSEC может применяться совместно с S/MIME, чтобы полнее обеспечить безопасность доставки электронной почты, аналогично DANE. Такое применение задокументировано в RFC8162[21], в котором предложена новая SMIMEA DNS RR. Цель SMIMEA RR – связать сертификаты с доменными именами DNS.

Сообщения S/MIME часто содержат сертификаты, которые могут оказаться полезны при аутентификации отправителя сообщения и при шифровании ответных сообщений. Для этого требуется, чтобы получающий MUA проверял сертификат предполагаемого отправителя. SMIMEA RR могут стать безопасным методом такой проверки.

В сущности, SMIMEA RR будет иметь тот же самый формат и содержимое, что и TLSA RR, и тот же самый функционал. Разница в том, что SMIMEA RR рассчитана на потребности MUA в работе с доменными именами, указанными в почтовых адресах в теле сообщения, а не с доменными именами, значащимися во внешнем конверте SMTP.

SPF (Sender Policy Framework)

Sender Policy Framework (SPF) – это стандартный способ для домена отправителя указать список MTA, уполномоченных отправлять почту от имени домена. SPF решает следующую проблему: в нынешней инфраструктуре электронной почты любой хост может поставить любое доменное имя в любой идентификатор в заголовке письма: не требуется, чтобы хост ставил обязательно имя домена, где он сам находится.

Такая свобода самовыражения влечет за собой два больших недостатка:

  • Она очень сильно мешает бороться со спамом, или, выражаясь формальным языком, несанкционированными массовыми почтовыми рассылками (Unsolicited Bulk E-mail или UBE). Обработчикам почты трудно отфильтровывать почту от известных источников спама.
  • Домены административного управления (Administrative Management Domain, ADMD) закономерно озабочены простотой, с которой можно использовать чужие доменные имена, часто со злонамеренными целями.

Однако основным ограничением SPF является то, что он заставляет почту идти по определенному пути и ломается, когда легитимная почта отклоняется от этого пути – в частности, когда сообщение проходит через список рассылки.

SPF определен в RFC7208[31]. Он представляет собой протокол, посредством которого ADMD могут уполномочивать хосты использовать свои доменные имена в полях MAIL FROM и HELO. (Следует отметить, что это доменное имя представляет собой обратный адрес для сообщений об ошибках и не обязано совпадать с адресом отправителя.) Совместимые с этим стандартом ADMD публикуют записи SPF в DNS с указанием того, каким хостам разрешается использовать доменные имена, а совместимые со стандартом получатели почты используют опубликованные записи SPF для проверки полномочий MTA-отправителей с помощью конкретного HELO или MAIL FROM.

SPF работает путем проверки IP-адреса MTA соседнего клиента выше по течению на предмет политик, закодированных в любой записи SPF, обнаруженной в домене отправителя. Домен отправителя – это домен, задействованный в соединении SMTP, а не домен, указанный в поле Author From заголовка сообщения, отображаемом в MUA. Поэтому проверки SPF можно применять до получения содержимого письма от отправителя.

На рисунке 5 приведен пример того, как можно использовать SPF. Предположим, что IP-адрес отправителя 192.168.0.1. От MTA с доменным именем mta.example.net приходит сообщение. Отправитель в конверте ставит в теге MAIL FROM значение alice@example.org, т.е. указывает, что сообщение исходит из домена example.org. Но в заголовке сообщения указано alice.sender@example.net. Получатель по SPF запрашивает SPF RR, соответствующую example.org, чтобы проверить, указан ли IP-адрес 192.168.0.1 в списке как уполномоченный отправитель, и принимает меры по результатам проверки RR.

Домен отправителя должен идентифицировать всех отправителей в данном домене и добавить эти данные в DNS в виде отдельной ресурсной записи. Затем домен отправителя кодирует соответствующую политику для каждого отправителя с помощью синтаксиса SPF. Кодирование осуществляется в записи ресурса TXT DNS в виде списка механизмов и модификаторов. Механизмы служат для определения IP-адреса или диапазона адресов, с которыми нужно выполнить сравнение, а модификаторы указывают политику для соответствующего сравнения. Синтаксис SPF довольно сложен и может выражать сложные взаимоотношения между отправителями. См. RFC 7208.

Рис. 5. Пример: заголовок конверта SMTP не совпадает с заголовком сообщения.

Если SPF реализован у получателя, объект SPF использует домен адресов MAIL FROM: и IP-адрес отправителя из конверта SMTP для опроса SPF TXT RR. Проверки SPF можно начать до получения тела письма, что может привести к блокировке передачи содержимого сообщения. Или же можно получить и буферизовать все сообщение до окончания всех проверок. В любом случае проверки должны быть завершены до того, как почтовое сообщение отправится в папку «Входящие» конечного пользователя.

Проверка включает в себя следующие правила:

  1. Если SPF TXT RR не возвращается, то по умолчанию сообщение будет принято.
  2. Если SPF TXT RR содержит ошибки форматирования, то по умолчанию сообщение будет принято.
  3. В противном случае судьбу сообщения определят механизмы и модификаторы в составе RR.

Если говорить об одном лишь SPF, можно спорить, правильно ли выбранное по умолчанию поведение – принять сообщение. Однако нужно иметь в виду, что SPF обычно работает вместе с целым рядом инструментов предотвращения злоупотреблений, а агрегированный механизм фильтрации обычно не принимает сообщение на основе результатов лишь одного из своих инструментов, такого как SPF.

Работа SPF проиллюстрирована на рис. 6. В 2016 году SPF был внедрен более чем в 27% всех доменов Интернета [32].

Рис. 6. Работа SPF.

DKIM

DKIM (Domain Keys Identified Mail) позволяет лицу, роли или организации, являющимися владельцами домена подписания, принять на себя некую ответственность за сообщение, связав с ним свой домен. Домен может быть организацией автора сообщения, операционным реле или одним из их агентов. DKIM отделяет идентичность подписавшего сообщение от идентичности предполагаемого автора сообщения. Принятие ответственности проверяется зашифрованной подписью и прямым запросом на выдачу соответствующего открытого ключа к домену подписания.

Я неслучайно написал в начале предыдущего абзаца слово «некую». Дело в том, что текст, прямо «охваченный» подписью, не проверяется на аутентичность.

Получатели сообщения (или агенты, действующие от их имени) могут проверить подпись, напрямую запросив у домена подписания соответствующий открытый ключ, и таким образом установить, что сообщение было обработано кем-то, кто обладает закрытым ключом домена подписания. DKIM является стандартом Интернета и определен в документе RFC 6376 [34]. DKIM широко используется целым рядом почтовых провайдеров, включая корпорации, госструктуры, Gmail, Yahoo и многих интернет-провайдеров (ISP). По состоянию на 2016 год DKIM, по оценке, использовался примерно на 40% сайтов в Интернете [35].

Административный блок (Administrative Unit, AU) – это часть пути почтового сообщения, которая находится под единым административным управлением. DKIM главным образом сосредоточен на хакерских атаках извне AU получателей и заявленного отправителя и борется с ними опосредованно, путем создания проверяемой подписи легитимных писем от административного блока.

В работе с такими внешними AU доверительные отношения, необходимые для отправки аутентифицированных сообщений, могут не существовать и недостаточно масштабируются для того, чтобы иметь практический смысл. В то же время при работе с такими AU имеются другие средства (такие как отправка аутентифицированных сообщений), которые легче внедряются и чаще применяются, чем DKIM. Внешние злоумышленники обычно пытаются сыграть на обезличенном характере электронной почты, благодаря которому большинство MTA получателей принимают все поступившие письма, чтобы доставить их в свой локальный домен. Хакеры могут создавать сообщения без подписей, с неправильными подписями или же с правильными подписями, но из доменов с плохой отслеживаемостью. Они также могут выдавать свои сообщения за почтовые рассылки, поздравительные открытки или другие сообщения от легитимных агентов, которые отправляют сообщения или пересылают чужие.

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

Обратите внимание, что подпись используется необычно: она не удостоверяет подписанный объект. Здесь выбор того, что именно подписать, работает просто как способ приклеить фрагмент d=domain name ко всему сообщению способом, который трудно сымитировать. У получателя агент доставки почты может получить соответствующий открытый ключ по DNS и проверить подпись, тем самым убедившись, что сообщение поступило из заявленного административного домена. Таким образом DKIM позволяет организации поручиться за почтовое сообщение, отправленное из домена, который она не контролирует. Такой подход отличается от S/MIME, где для подписания содержимого сообщения используется закрытый ключ отправителя. Основания для DKIM базируются на следующих соображениях:

  • Для работы S/MIME необходимо применение S/MIME и пользователем-отправителем, и пользователем-получателем. Почти у всех пользователей основная масса входящей почты не использует S/MIME, а основная масса почты, которую пользователь отправляет вовне, тоже предназначена лицам, не использующим S/MIME.
  • S/MIME подписывает только содержимое письма. Поэтому заголовок по RFC 5322 [36],описывающий источник письма, оказывается уязвимым.
  • DKIM не включен в клиентские программы (MUA) и потому прозрачен для пользователя – последнему не нужно ничего делать.
  • DKIM можно настроить так, чтобы он применялся ко всей почте из сотрудничающих доменов.
  • DKIM позволяет добросовестному отправителю доказать, что именно он отправил данное письмо, и не допустить подделки подписи DKIM.

На рисунке 7 приведен простой пример работы DKIM. Начнем с того, что пользователь создает сообщение. Затем оно передается в службу обработки сообщений (MHS) и поступает в MSA, находящийся в рамках административного домена пользователя. Почтовый клиент генерирует электронное письмо.

Рис. 7. Простой пример внедрения DKIM.

Содержимое письма плюс избранные заголовки RFC 5322 подписываются провайдером почты с использованием закрытого ключа провайдера. Подписавший относится к какому-либо домену: это может быть корпоративная локальная сеть, ISP или открытая почтовая служба, такая как Gmail. Затем подписанное сообщение проходит по Интернету через несколько MTA. В точке назначения MDA извлекает открытый ключ поступившей подписи и проверяет ее, а затем передает сообщение почтовому клиенту получателя. По умолчанию используется алгоритм подписания RSA с SHA-256. Также можно использовать RSA с SHA-1.

На рисунке 8, взятом из RFC 5585 [37], элементы работы DKIM показаны более подробно. Базовая обработка сообщений разделена между подписавшим доменом административного управления (ADMD) и проверяющим ADMD. В самом простом варианте эта процедура ограничивается исходным ADMD и ADMD доставки, но может включать в себя и другие ADMD по пути обработки.

Подписание осуществляется уполномоченным модулем в подписавшем ADMD, при этом используется закрытая информация из банка ключей. В пределах исходного ADMD подписать сообщение может MUA, MSA или MTA. Проверка тоже осуществляется уполномоченным модулем в подписавшем ADMD. Это может быть MTA, MDA или MUA в пределах ADMD получателя. Такой модуль проверяет подпись или определяет, нужна ли была такая подпись.

Для проверки подписи используется открытая информация из банка ключей. Если подпись проходит проверку, то выполняется оценка подписавшего по репутационной информации и такая информация передается в систему фильтрации сообщений.

Рис. 8. Функциональная схема DKIM.

Если подпись не проходит проверку либо подписи, использующей домен автора, просто нет, то можно извлечь (удаленно и/или локально) сведения о том, какая практика подписания действует для такого автора, и передать ее в систему фильтрации сообщений. Например, если отправитель (допустим, Gmail) использует DKIM, но подпись DKIM отсутствует, то сообщение считается злонамеренным.

Подпись вставляется в сообщение RFC 5322 в виде дополнительного поля в заголовке, начиная с ключевого слова Dkim-Signature. Вы можете увидеть примеры в собственном почтовом ящике, выбрав параметр View Long Headers (или похожий) для полученного письма.

Перед подписанием сообщения выполняется процедура, называемая каноникализацией или нормализацией (canonicalization) (у этого термина встречается и перевод «канонизация», но я поостерегусь причислять электронную почту к лику святых – перев.) заголовка и тела сообщения RFC 5322. Нормализация необходима для того, чтобы сообщение могло «пережить» возможные мелкие изменения по пути доставки, такие как смена кодировки, обрезание хвостовых пробелов в строках, «свертывание» и «развертывание» строк заголовка. Задача нормализации в том, чтобы выполнить минимальное преобразование сообщения (для целей подписания: само сообщение не модифицируется, поэтому проверяющий будет должен нормализовать письмо еще раз) так, чтобы максимально повысить вероятность того, что у получателя получится то же самое каноническое значение. В DKIM определены два алгоритма нормализации заголовков («простой» – simple и «спокойный» – relaxed) и два алгоритма для тел (с теми же названиями). Простой алгоритм практически нетерпим к модификациям, в то время как спокойный нормально переносит обычные модификации.

DMARC

DMARC (Domain-Based Message Authentication, Reporting, and Conformance), определенный в RFC 7489 [38], позволяет отправителям электронной почты указывать политику ее обработки, типы отчетов, которые могут возвращать отправителю получатели, и частоту таких отчетов.

DMARC работает с SPF и DKIM. SPF позволяет отправителям уведомлять получателей (по DNS) о том, легитимна ли почта, якобы поступившая от этого отправителя, и как с ней следует поступить: доставить, отметить как подозрительную или выбросить. Однако ни в SPF, ни в DKIM нет механизма, который бы сообщал получателям, что используется SPF или DKIM. Нет и механизма обратной связи, чтобы информировать отправителей об эффективности методов борьбы со спамом. Например, если получатель получает сообщение без подписи DKIM, то в DKIM нет возможности сообщить получателю, что это значит: письмо подлинное, но его отправитель не использует DKIM – либо что письмо поддельное. В сущности, DMARC решает эти проблемы, указывая: а) будет ли использоваться SPF и/или DKIM; б) как должен поступить получатель, если они не используются; и в) как получателям следует отправлять отчеты о совокупных результатах работы по домену.

DKIM, SPF и DMARC удостоверяют различные аспекты сообщения. DKIM удостоверяет домен, приписавший к сообщению подпись. SPF работает с конвертом SMTP, определенным по RFC5321 [39]. Он может удостоверить либо домен, указанный в поле MAIL FROM конверта SMTP, либо домен HELO, либо оба сразу. Эти домены могут быть разными и обычно не видны конечному пользователю.

DMARC удостоверяет домен From в заголовке сообщения по RFC 5322. Это поле играет центральную роль в работе DMARC, поскольку это обязательное поле заголовка, а потому оно обязательно будет присутствовать в совместимых сообщениях, а большинство MUA интерпретируют поле From по RFC 5322 как источник сообщения и передают часть его содержимого конечным пользователям. Конечный пользователь считает адресом отправителя именно тот почтовый адрес, который значится в этом поле. Поэтому он является столь лакомой мишенью для злоумышленников.

DMARC требует, чтобы содержимое поля From совпадало с аутентифицированным идентификатором (Authenticated Identifier) в DKIM или SPF. В случае DKIM сличаются домен подписания DKIM и домен From. В случае SPF сличаются домен аутентификации SPF и домен From.

Отправитель почты, использующий DMARC, обязан использовать также SPF и/или DKIM. Отправитель публикует в DNS политику DMARC, которая указывает получателям, как обращаться с сообщениями, якобы поступившими из домена отправителя. Эта политика выражена в виде ресурсной записи DNS TXT, сопоставленной доменному имени отправителя. Кроме того, отправитель должен также указать почтовый адрес для отправки сводных и аналитических отчетов. Поскольку эти почтовые адреса публикуются в DNS TXT RR без шифрования, они легко обнаруживаются, а в результате становятся мишенями для спама. Поэтому публикатору DNS TXT RR нужно задействовать какие-либо контрмеры.

Аналогично SPF и DKIM, политика DMARC в TXT RR записана в виде последовательности пар «тег=значение», разделенных точками с запятой. После публикации DMARC RR сообщения от этого отправителя обычно обрабатываются следующим образом:

  1. Владелец домена создает политику SPF и публикует ее в своей базе данных DNS. Владелец домена также настраивает свою систему для генерации подписей DKIM. И, наконец, владелец домена публикует в DNS политику обработки сообщений DMARC.
  2. Автор создает электронное письмо и передает его в выделенную службу отправки сообщений домена.
  3. Служба отправки передает нужные данные в модуль подписания DKIM, получает цифровую подпись DKIM и дописывает ее к сообщению.
  4. Служба отправки передает подписанное сообщение своей выделенной транспортной службе для маршрутизации к указанному получателю (или получателям).

Сообщение, созданное на стороне отправителя, поступает в транспортную службу получателя (возможно, по пути пройдя через другие пункты пересылки). На стороне получателя при использовании DMARC происходит следующее:

  1. Получатель выполняет стандартные проверки, такие как проверка по черным спискам IP-адресов и спискам репутации доменов, а также применение квот на письма от конкретного источника.
  2. Получатель извлекает поле From по RFC 5322 из сообщения, получая адрес. Это должен быть один адрес допустимого формата, иначе письмо считается битым и отбрасывается.
  3. Получатель запрашивает запись DMARC DNS для домена отправителя. Если такой записи нет, работа DMARC завершается.
  4. Получатель выполняет проверку подписи DKIM. Если в письме несколько подписей DKIM, одна должна пройти проверку.
  5. Получатель запрашивает запись SPF для домена отправителя и выполняет проверки SPF.
  6. Получатель выполняет проверку совпадения идентификаторов для поля RFC 5321 From и результатов, полученных из записей SPFи DKIM (если есть).
  7. Результаты этих проверок передаются в модуль DMARC вместе с доменом автора. Модуль DMARC пытается извлечь политику из записей DNS для этого домена. Если ее нет, модуль DMARC определяет домен организации и пытается извлечь политику из записей DNS уже для этого домена.
  8. Если политика найдена, она комбинируется с доменом автора и результатами SPF и DKIM. По итогам генерируется результат политик DMARC (успех или неудача), а также (необязательно) могут генерироваться два типа отчетов.
  9. Транспортная служба получателя по результатам работы DMARC либо доставляет сообщение в почтовый ящик адресата, либо выполняет другие действия в соответствии со своей локальной политикой.
  10. При наличии запроса транспортная служба получателя собирает данные из сеанса доставки сообщения для обратной связи.

На рисунке 9, адаптированном с сайта DMARC.org, приведена сводная функциональная схема отправки и получения.

Рис. 9. Функциональная схема DMARC.

Отчеты DMARC дают отправителю обратную связь по его политикам SPF, DKIM, сличения идентификаторов и обращения с сообщениями. По результатам отправитель может доработать свои политики. Отправляются два типа отчетов: сводные отчеты (AggregateReport) и аналитические отчеты (Forensic Report).

Сводные отчеты отправляются получателями периодически и содержат сводные данные по успехам и неудачам аутентификации сообщение, в том числе:

  • политику DMARC отправителя за отчетный период;
  • параметры обработки сообщений получателям (доставка, помещение в карантин, отказ);
  • результаты SPF для данного идентификатора SPF;
  • результаты DKIM для данного идентификатора DKIM;
  • совпадение/несовпадение идентификаторов;
  • результаты с разбивкой по поддоменам отправителя;
  • пару доменов отправителя и получателя;
  • примененную политику и ее отличия от запрошенной (если отличается);
  • количество успешных аутентификаций;
  • общее число полученных сообщений.

Эта информация помогает отправителю выявить пробелы в своей почтовой инфраструктуре и политике. АвторыSP 800-177 рекомендуют доменам отправителя начинать с политики DMARC p=none, чтобы судьба сообщения, не прошедшего ту или иную проверку, решалась локальными политиками получателя. По мере сбора сводных отчетов DMARC отправитель получит богатый материал для оценки того, в какой мере его почта проходит проверки внешними получателями, и сможет настроить политику p=reject, которая будет означать, что любые сообщения, не прошедшие проверки SPF, DKIM и совпадения, должны отбрасываться. Получатели же, проводя собственный анализ трафика, могут определить, является ли политика отправителя p=reject достаточно надежной для применения.

Аналитический отчет помогает отправителю настроить компоненты SPF и DKIM, а также оповещает его о том, что его домен стал частью фишинговой/спамерской кампании. Аналитические отчеты по формату аналогичны сводным, но со следующими отличиями:

  • Получатели включают в отчет максимальную (в разумных пределах) часть сообщения и его заголовка, чтобы домен отправителя мог расследовать происшествие. Также добавляется поле Identity-Alignment с полями DKIM и SPF DMARC (при необходимости).
  • Дополнительно может быть добавлено поле Delivery-Result. Если сообщение было подписано по DKIM, добавляются поля DKIM Domain, DKIM Identity и DKIM Selector.Дополнительно также могут быть добавлены поля DKIM Canonical для заголовка и тела.
  • Добавляется дополнительное поле неудачной аутентификации DMARC – для случаев, когда сличение аутентификации дает несовпадение.

С момента своего появления DMARC сразу же стал популярен. Тысячи компаний с его помощью перехватили миллиарды злонамеренных писем, якобы исходивших из доменов этих компаний, защитив тем самым своих сотрудников и клиентов от фишинга, спама и т.д. Недавно два крупнейших почтовых провайдера в мире – Google и Yahoo – объявили, что распространяют эту защиту на новые интернет-домены под своим контролем.

Итоги

IETF разработала серию протоколов для обеспечения всеобъемлющей безопасности электронной почты в Интернете. Многие из них нашли широкое применение, и NIST рекомендует весь набор к использованию.

Благодарности

Автор пользуется случаем выразить свою благодарность рецензенту за множество подробных и дельных замечаний.

  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •  
  •