Аутентификация по электронной почте
Методы, направленные на предоставление проверяемой информации о происхождении сообщений электронной почты

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

Первоначальная основа интернет-почты, Simple Mail Transfer Protocol (SMTP), не имеет такой функции, поэтому поддельные адреса отправителя в электронных письмах (практика, известная как подделка электронных писем ) широко использовались в фишинге , спаме и различных видах мошенничества. Для борьбы с этим было разработано множество конкурирующих предложений по аутентификации электронной почты. К 2018 году [обновлять]были широко приняты три из них — SPF , DKIM и DMARC . [1] [2] Результаты такой проверки могут использоваться в автоматизированной фильтрации электронной почты или могут помочь получателям при выборе соответствующего действия.

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

Обоснование

В начале 1980-х годов, когда был разработан Simple Mail Transfer Protocol (SMTP), он не предусматривал реальной проверки отправляющего пользователя или системы. Это не было проблемой, пока системы электронной почты управлялись доверенными корпорациями и университетами, но с коммерциализацией Интернета в начале 1990-х годов спам , фишинг и другие преступления все чаще связаны с электронной почтой.

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

Позиция, основанная на владении доменом, появилась в начале 2000-х годов. [3] [4] Она подразумевает грубую аутентификацию, учитывая, что домены появляются в правой части адресов электронной почты после знака at . Тонкая аутентификация на уровне пользователя может быть достигнута другими способами, такими как Pretty Good Privacy и S/MIME . В настоящее время цифровая идентификация должна управляться каждым человеком.

Выдающимся обоснованием аутентификации электронной почты является возможность автоматизировать фильтрацию электронной почты на принимающих серверах. Таким образом, поддельные сообщения могут быть отклонены до того, как они попадут в папку «Входящие» пользователя. В то время как протоколы стремятся разработать способы надежной блокировки недоверенной почты, индикаторы безопасности могут помечать неаутентифицированные сообщения, которые все еще попадают в папку «Входящие». Исследование 2018 года показывает, что индикаторы безопасности могут снизить коэффициент кликабельности более чем на десять пунктов, с 48,9% до 37,2% пользователей, которые открывают поддельные сообщения. [5]

Характер проблемы

SMTP определяет транспорт сообщения , а не его содержимое . Таким образом, он определяет почтовый конверт и его параметры, такие как отправитель конверта , но не заголовок (кроме информации трассировки ) и не тело самого сообщения. STD 10 и RFC  5321 определяют SMTP (конверт), в то время как STD 11 и RFC  5322 определяют сообщение (заголовок и тело), ​​формально именуемое форматом сообщения Интернета .

SMTP определяет трассировочную информацию сообщения, которая сохраняется в заголовке, используя следующие два поля: [6]

  • Получено : когда SMTP-сервер принимает сообщение, он вставляет эту запись трассировки в верхнюю часть заголовка (от последней к первой).
  • Return-Path : когда SMTP-сервер доставки завершает доставку сообщения, он вставляет это поле в верхнюю часть заголовка.

Почтовый агент пользователя (MUA) знает исходящий почтовый SMTP-сервер из своей конфигурации. MTA (или сервер ретрансляции) обычно определяет, к какому серверу подключаться, просматривая запись ресурса MX (Mail eXchange) DNS для доменного имени каждого получателя .

Путь, изображенный ниже, можно реконструировать на основе полей заголовка трассировки , которые каждый хост добавляет в верхнюю часть заголовка при получении сообщения: [6]

Аутентификация электронной почты может быть осложнена наличием промежуточного ретранслятора. A и B явно принадлежат к домену административного управления автора, тогда как D и E являются частью сети получателя. Какую роль играет C ?
Return-Path: <author@example.com> Получено: с D.example.org пользователем E.example.org с помощью SMTP ; Вт, 05 фев 2013 11:45:02 -0500 Получено: с C.example.net пользователем D.example.org с помощью SMTP ; Вт, 05 фев 2013 11:45:02 -0500 Получено: с B.example.com ( b.example.com [ 192.0.2.1 ]) пользователем C.example.net (то есть мной ) с идентификатором ESMTP 936ADB8838C для <different-recipient@example.net> ; Вт, 05 фев 2013 08:44:50 -0800 (PST) Получено: от A.example.com от B.example.com с SMTP ; Вт, 05 фев 2013 17:44:47 +0100 Получено: от [ 192.0.2.27 ] от A.example.com с SMTP ; Вт, 05 фев 2013 17:44:42 +0100

Первые несколько строк в верхней части заголовка обычно доверяются получателем. Эти строки пишутся машинами в Административном Домене Управления ( ADMD ) получателя, которые действуют в соответствии со своим явным мандатом. Напротив, строки, которые доказывают участие A и B , а также MUA предполагаемого автора, могут быть подделкой, созданной C. Поле Received:, показанное выше, является эпохальной частью заголовка. Поле Return-Path:написано E , агентом доставки почты (MDA), на основе конверта сообщения . Дополнительные поля трассировки, предназначенные для аутентификации электронной почты, могут заполнять верхнюю часть заголовка.

Обычно сообщения, отправленные ADMD автора, идут напрямую в MX получателя (то есть B → D на рисунках). ADMD отправителя может добавлять токены аутентификации только в том случае, если сообщение проходит через его ящики. Наиболее распространенные случаи можно схематизировать следующим образом:

Схематическое изображение наиболее распространенных способов передачи сообщения электронной почты от его автора к получателю.

Отправка из сети ADMD (MUA 1)

  • MSA ADMD аутентифицирует пользователя, либо на основе его IP-адреса , либо с помощью других средств аутентификации SMTP. В зависимости от адреса получателя сообщение может следовать по обычному пути или проходить через список рассылки или службу пересылки. [примечание 1] B может быть исходящим SMTP-прокси или смарт-хостом . [примечание 2]
  • Если локальная сеть не блокирует исходящие соединения через порт 25, [примечание 3] пользователь может развернуть некоторое программное обеспечение «direct-to-mx». [примечание 4] Обычно зомби и другие вредоносные хосты ведут себя таким образом.
  • Если MUA настроен неправильно, он также может использовать другой ретранслятор, например устаревший открытый ретранслятор , который часто не аутентифицирует пользователя.

Пользователь роуминга (MUA 2)

  • В большинстве случаев все еще возможно использовать собственную ADMD MSA. [примечание 5]
  • Исходящие соединения с портом 25 могут быть перехвачены и туннелированы на прозрачный прокси-сервер. [примечание 4]
  • MUA можно настроить на использование SMTP-ретранслятора, который провайдер локальной сети предлагает в качестве бонуса. [примечание 4]

Отключенный пользователь

  • Электронная открытка может отправлять почту от имени клиента, который набрал адрес электронной почты на локальной клавиатуре; некоторые веб-формы можно считать работающими аналогичным образом. [примечание 4]

Раздел примечаний

  1. ^ Например, получатель может указать Gmail пересылать сообщения на другой адрес электронной почты. Отправитель не обязательно знает об этом.
  2. ^ Правильно настроенные прокси-серверы отображаются как часть ADMD автора.
  3. ^ Некоторые ADMD блокируют исходящее соединение с портом 25 (SMTP), чтобы избежать этого. Эта упреждающая техника описана в RFC 5068. Кроме того, некоторые блокируют входящие SMTP-соединения с IP-адресов , указанных как dialup /DSL/cable.
  4. ^ abcd В данном случае СДВГ автора вообще не задействован.
  5. ^ Некоторые интернет-провайдеры блокируют порт 587, хотя в RFC 5068 четко сказано:

    Поставщики доступа НЕ ДОЛЖНЫ блокировать пользователям доступ к внешнему Интернету с использованием порта 587 ОТПРАВКИ.

Широко используемые методы аутентификации

СПФ

SPF аутентифицирует IP-адрес отправителя.

SPF позволяет получателю проверить, что электронное письмо, которое, как утверждается, пришло с определенного домена, пришло с IP-адреса, авторизованного администраторами этого домена. Обычно администратор домена авторизует IP-адреса, используемые его собственными исходящими MTA, включая любой прокси или смарт-хост. [7] [8]

IP-адрес отправляющего MTA гарантированно является действительным по протоколу управления передачей , поскольку он устанавливает соединение, проверяя, что удаленный хост доступен. [9] Получающий почтовый сервер получает команду HELO SMTP вскоре после установки соединения и Mail from:в начале каждого сообщения. Оба они могут содержать доменное имя. Верификатор SPF запрашивает у системы доменных имен (DNS) соответствующую запись SPF, которая, если она существует, будет указывать IP-адреса, авторизованные администратором этого домена. Результатом может быть «пройдено», «не пройдено» или какой-то промежуточный результат — и системы, как правило, учитывают это при фильтрации спама. [10]

ДКИМ

DKIM аутентифицирует части содержимого сообщения.

DKIM проверяет содержимое сообщения , развертывая цифровые подписи . Вместо использования цифровых сертификатов ключи для проверки подписи распространяются через DNS. Таким образом, сообщение связывается с доменным именем. [11]

Администратор домена, совместимый с DKIM, генерирует одну или несколько пар асимметричных ключей , затем передает закрытые ключи подписывающему MTA и публикует открытые ключи в DNS. Метки DNS структурированы как selector._domainkey.example.com, где селектор идентифицирует пару ключей и _domainkeyявляется фиксированным ключевым словом, за которым следует имя подписывающего домена, так что публикация происходит под руководством ADMD этого домена. Непосредственно перед внедрением сообщения в транспортную систему SMTP подписывающий MTA создает цифровую подпись, которая охватывает выбранные поля заголовка и тела (или только его начало). Подпись должна охватывать существенные поля заголовка, такие как From:, To:, Date:, и Subject:, а затем добавляется к самому заголовку сообщения в качестве поля трассировки. Любое количество ретрансляторов может получать и пересылать сообщение, и на каждом этапе подпись может быть проверена путем извлечения открытого ключа из DNS. [12] Пока промежуточные ретрансляторы не изменяют подписанные части сообщения, его DKIM-подписи остаются действительными.

ДМАРК

DMARC позволяет специфицировать политику для аутентифицированных сообщений. Он построен на основе двух существующих механизмов: Sender Policy Framework (SPF) и DomainKeys Identified Mail (DKIM).

Он позволяет административному владельцу домена публиковать политику в своих записях DNS , чтобы указать, какой механизм (DKIM, SPF или оба) используется при отправке электронной почты с этого домена; как проверять From:поле, представленное конечным пользователям; как получатель должен обрабатывать сбои, а также механизм отчетности о действиях, выполненных в соответствии с этими политиками.

Другие методы

Были предложены и другие методы, но теперь они либо устарели, либо еще не получили широкой поддержки. К ним относятся Sender ID , Certified Server Validation , DomainKeys и нижеперечисленные:

АДСП

ADSP допускал спецификацию политики для сообщений, подписанных доменом автора. Сначала сообщение должно было пройти аутентификацию DKIM, затем ADSP мог потребовать карательного обращения, если сообщение не было подписано доменом(ами) автора — согласно From:полю заголовка. [13]

В ноябре 2013 года статус ADSP был понижен до исторического. [14]

ВБР

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

Отправитель может подать заявку на получение справки в подтверждающем органе. Ссылка, если она принята, публикуется в ветви DNS, управляемой этим органом. Подтвержденный отправитель должен добавлять VBR-Info:поле заголовка к отправляемым им сообщениям. Он также должен добавлять подпись DKIM или использовать какой-либо другой метод аутентификации, например SPF. Получатель, после проверки личности отправителя, может проверить заявленную справку, VBR-Info:просмотрев ссылку. [15]

iprev

Приложениям следует избегать использования этого метода в качестве средства аутентификации. [16] Тем не менее, он часто выполняется, и его результаты, если таковые имеются, записываются в Received:поле заголовка помимо информации TCP, требуемой спецификацией SMTP.

Обратный IP, подтвержденный поиском IP-адреса только что найденного имени, является лишь указанием на то, что IP был правильно настроен в DNS. Обратное разрешение диапазона IP-адресов может быть делегировано ADMD, который их использует, [17] или может оставаться под управлением сетевого провайдера. В последнем случае нельзя получить никакой полезной идентификации, связанной с сообщением.

DNSWL

Поиск в DNSWL (белом списке на основе DNS) может дать оценку отправителю, возможно, включая его идентификационные данные.

Результаты аутентификации

RFC 8601 определяет поле заголовка трассировки Authentication-Results:, в котором получатель может записывать результаты проверок подлинности электронной почты, которые он выполнил. [16] Несколько результатов для нескольких методов могут быть представлены в одном поле, разделенные точкой с запятой и заключенные в соответствующий перенос.

Например, следующее поле предположительно написано receiver.example.orgи сообщает результаты SPF и DKIM :

Результаты аутентификации: receiver.example.org ; spf=pass smtp.mailfrom = example.com ; dkim=pass header.i=@example.com

Первый токен после имени поля, receiver.example.org, является идентификатором сервера аутентификации, токеном, известным как authserv-id . Приемник, поддерживающий RFC 8601, несет ответственность за удаление (или переименование) любого ложного заголовка, утверждающего, что он принадлежит его домену, чтобы нисходящие фильтры не могли запутаться. Однако эти фильтры все равно необходимо настроить, так как они должны знать, какие идентификаторы может использовать домен.

Для Mail User Agent (MUA) немного сложнее узнать, каким личностям он может доверять. Поскольку пользователи могут получать электронную почту с нескольких доменов — например, если у них несколько адресов электронной почты — любой из этих доменов может пропустить Authentication-Results:поля, потому что они выглядят нейтральными. Таким образом, злонамеренный отправитель может подделать authserv-id , которому пользователь будет доверять, если сообщение придет с другого домена. Законный Authentication-Results:обычно появляется чуть выше Received:поля того же домена, с которого было передано сообщение. Дополнительные Received:поля могут появляться между ним и верхней частью заголовка, поскольку сообщение передавалось внутри между серверами, принадлежащими тому же доверенному ADMD.

Internet Assigned Numbers Authority ведет реестр параметров аутентификации электронной почты. Однако не все параметры должны быть зарегистрированы. Например, могут быть локальные значения «политики», предназначенные только для внутреннего использования сайта, которые соответствуют локальной конфигурации и не требуют регистрации.

Смотрите также

Ссылки

  1. ^ Ханг Ху; Пэн Пэн; Ган Ван (2017). «На пути к принятию антиспуфинговых протоколов». arXiv : 1711.06654 [cs.CR].
  2. ^ kerner, Sean Michael (2 января 2018 г.). «DMARC Email Security Adoption Grows in US Government» (Принятие мер по обеспечению безопасности электронной почты DMARC растет в правительстве США). eWeek . Получено 24 ноября 2018 г.
  3. ^ "Email Authentication Summit". workshop . Федеральная торговая комиссия . 9–10 ноября 2004 г. Архивировано из оригинала 3 июня 2012 г. Получено 4 февраля 2013 г. Однако в отчете аутентификация на уровне домена была определена как перспективная технологическая разработка.
  4. ^ Майкл Хаммер (14 августа 2020 г.). «авторизация третьей стороны». dmarc-ietf (список рассылки) . Получено 14 августа 2020 г.
  5. ^ Ханг Ху; Ган Ван (15 августа 2018 г.). Сквозные измерения атак с подменой электронной почты. стр.  1095–1112 . ISBN 9781939133045. {{cite book}}: |work=проигнорировано ( помощь )
  6. ^ ab John Klensin (октябрь 2008 г.). "Trace Information". Simple Mail Transfer Protocol. IETF . sec. 4.4. doi : 10.17487/RFC5321 . RFC 5321 . Получено 1 февраля 2013 г. Когда сервер SMTP принимает сообщение для ретрансляции или окончательной доставки, он вставляет запись трассировки (также называемую взаимозаменяемо "строкой отметки времени" или строкой "Получено") в верхней части почтовых данных. Эта запись трассировки указывает идентификационные данные хоста, отправившего сообщение, идентификационные данные хоста, получившего сообщение (и вставляющего эту отметку времени), а также дату и время получения сообщения. Ретранслируемые сообщения будут иметь несколько строк отметок времени.
  7. ^ Скотт Киттерман (апрель 2014 г.). Структура политики отправителя (SPF) для авторизации использования доменов в электронной почте, версия 1. IETF . doi : 10.17487/RFC7208 . RFC 7208 . Получено 26 апреля 2014 г. Есть три места, где можно использовать методы для смягчения непреднамеренных сбоев SPF с посредниками.
  8. ^ J. Klensin (октябрь 2008 г.). "Псевдоним". Simple Mail Transfer Protocol. IETF . раздел 3.9.1. doi : 10.17487/RFC5321 . RFC 5321. Получено 15 февраля 2013 г.
  9. ^ Подделка IP-адреса возможна, но обычно подразумевает более низкий уровень преступного поведения (взлом и проникновение, прослушивание телефонных разговоров и т. д.), который слишком рискован для обычного хакера или спамера, или небезопасные серверы, не реализующие RFC 1948, см. также Протокол управления передачей#Перехват соединения .
  10. ^ Скотт Киттерман (21 ноября 2009 г.). "Насколько надежно блокировать/отклонять при сбое SPF?". spf-help . gossamer-threads.com. Я думаю, что в целом это нормально, если вы предлагаете механизм для внесения в белый список пересылок, не являющихся SRS.
  11. ^ D. Crocker; T. Hansen; M. Kucherawy, ред. (сентябрь 2011 г.). Подписи DomainKeys Identified Mail (DKIM). IETF . doi : 10.17487/RFC6376 . RFC 6376 . Получено 18 февраля 2013 г. DomainKeys Identified Mail (DKIM) позволяет человеку, роли или организации претендовать на определенную ответственность за сообщение, связывая с сообщением доменное имя, которое им разрешено использовать.
  12. ↑ Дэйв Крокер (16 октября 2007 г.). «Часто задаваемые вопросы о DKIM». DKIM.org . Получено 17 февраля 2013 г.
  13. ^ E. Allman; J. Fenton; M. Delany; J. Levine (август 2009 г.). DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP). IETF . doi : 10.17487/RFC5616 . RFC 5616 . Получено 18 февраля 2013 г. .
  14. ^ Барри Лейба (25 ноября 2013 г.). «Изменить статус ADSP (RFC 5617) на исторический». IETF .
  15. ^ P. Hoffman; J. Levine; A. Hathcock (апрель 2009 г.). Подтверждено ссылкой. IETF . doi : 10.17487/RFC5518 . RFC 5518 . Получено 18 февраля 2013 г. .
  16. ^ ab Murray Kucherawy (май 2019 г.). Поле заголовка сообщения для указания статуса аутентификации сообщения. IETF . doi : 10.17487/RFC8601 . RFC 8601 . Получено 12 июня 2023 г. .
  17. ^ H. Eidnes; G. de Groot; P. Vixie (март 1998 г.). Бесклассовое делегирование IN-ADDR.ARPA. IETF . doi : 10.17487/RFC2317 . RFC 2317 . Получено 18 февраля 2013 г. .
Взято с "https://en.wikipedia.org/w/index.php?title=Email_authentication&oldid=1234513640"