stringtranslate.com

Аутентификация по электронной почте

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

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

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

Обоснование

В начале 1980-х годов, когда был разработан простой протокол передачи почты (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]

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

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

Аутентификация электронной почты может быть осложнена наличием промежуточного ретранслятора. A и B явно принадлежат домену административного управления автора, тогда как D и E являются частью сети получателя. Какую роль играет С ?
Путь возврата: <[email protected]> Получено: от D.example.org от E.example.org с помощью SMTP ; Вт, 05 февраля 2013 г., 11:45:02 -0500 Получено: от C.example.net от D.example.org с SMTP ; Вт, 5 февраля 2013 г., 11:45:02 -0500 Получено: от B.example.com ( b.example.com [ 192.0.2.1 ]) от C.example.net (это я ) с идентификатором ESMTP 936ADB8838C для <различное [email protected]> ; Вт, 5 февраля 2013 г., 08:44:50 -08:00 (тихоокеанское стандартное время) Получено: от 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)

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

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

Примечания к разделу

  1. ^ Например, получатель может поручить Gmail пересылать сообщения на другой адрес электронной почты. Отправитель не обязательно знает об этом.
  2. ^ Правильно настроенные прокси появляются как часть ADMD автора.
  3. ^ Некоторые ADMD блокируют исходящее соединение с портом 25 (SMTP), чтобы избежать этого. Этот упреждающий метод описан в RFC 5068. Кроме того, некоторые блокируют входящие SMTP-соединения с IP-адресов , перечисленных как коммутируемое соединение /DSL/кабельное соединение.
  4. ^ abcd В данном случае ADMD автора вообще не задействован.
  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 позволяет указать политику для аутентифицированных сообщений. Он построен на основе двух существующих механизмов: инфраструктуры политики отправителей (SPF) и почты, идентифицированной с помощью DomainKeys (DKIM).

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

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

Был предложен ряд других методов, но сейчас они либо устарели, либо еще не получили широкой поддержки. К ним относятся идентификатор отправителя , проверка сертифицированного сервера , ключи домена и перечисленные ниже:

АДСП

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

ADSP был понижен в звании до исторического уровня в ноябре 2013 года .

ВБР

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

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

ипрев

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

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

DNSWL

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

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

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

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

Результаты аутентификации: получатель.example.org ; spf=pass smtp.mailfrom = example.com ; dkim=pass [email protected]

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

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

Управление по присвоению номеров в Интернете ведет реестр параметров аутентификации электронной почты. Однако не все параметры необходимо регистрировать. Например, могут существовать локальные значения «политики», предназначенные только для внутреннего использования сайта, которые соответствуют локальной конфигурации и не требуют регистрации.

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

Рекомендации

  1. ^ Ханг Ху; Пэн Пэн; Ган Ван (2017). «На пути к принятию протоколов борьбы со спуфингом». arXiv : 1711.06654 [cs.CR].
  2. ↑ Кернер, Шон Майкл (2 января 2018 г.). «В правительстве США растет внедрение безопасности электронной почты DMARC». электронная неделя . Проверено 24 ноября 2018 г.
  3. ^ «Саммит по аутентификации электронной почты» . мастерская . Федеральная торговая комиссия . 9–10 ноября 2004 г. Архивировано из оригинала 3 июня 2012 г. . Проверено 4 февраля 2013 г. Однако в отчете аутентификация на уровне домена названа многообещающей технологической разработкой.{{cite web}}: CS1 maint: неподходящий URL ( ссылка )
  4. ↑ Майкл Хаммер (14 августа 2020 г.). «разрешение третьей стороны». dmarc-ietf (список рассылки) . Проверено 14 августа 2020 г.
  5. ^ Ханг Ху; Ган Ван (15 августа 2018 г.). Комплексные измерения атак спуфинга электронной почты. стр. 1095–1112. ISBN 9781939133045. {{cite book}}: |work=игнорируется ( помощь )
  6. ^ аб Джон Кленсин (октябрь 2008 г.). «Следовая информация». Простой протокол передачи почты. IETF . сек. 4.4. дои : 10.17487/RFC5321 . РФК 5321 . Проверено 1 февраля 2013 г. Когда SMTP-сервер принимает сообщение либо для ретрансляции, либо для окончательной доставки, он вставляет запись трассировки (также называемую взаимозаменяемо «строкой отметки времени» или «строкой получения») вверху почтовых данных. Эта запись трассировки указывает идентификатор узла, отправившего сообщение, идентификатор узла, получившего сообщение (и вставляющего эту отметку времени), а также дату и время получения сообщения. Ретранслируемые сообщения будут иметь несколько строк отметок времени.
  7. ^ Скотт Киттерман (апрель 2014 г.). Структура политики отправителей (SPF) для авторизации использования доменов в электронной почте, версия 1. IETF . дои : 10.17487/RFC7208 . РФК 7208 . Проверено 26 апреля 2014 г. Есть три места, где можно использовать методы для устранения непреднамеренных сбоев SPF с помощью медиаторов.
  8. ^ Дж. Кленсин (октябрь 2008 г.). «Псевдоним». Простой протокол передачи почты. IETF . сек. 3.9.1. дои : 10.17487/RFC5321 . РФК 5321 . Проверено 15 февраля 2013 г.
  9. ^ Подделка IP-адреса возможна, но обычно предполагает более низкий уровень преступного поведения (взлом и проникновение, прослушивание телефонных разговоров и т. д.), которые слишком опасны для типичного хакера или спамера, или небезопасных серверов, не реализующих RFC 1948, см. также Управление передачей. Протокол#Перехват соединения .
  10. ↑ Скотт Киттерман (21 ноября 2009 г.). «Насколько надежно заблокировать/отклонить сбой SPF?». spf-помощь . gossamer-threads.com. Я думаю, что в целом это нормально, если вы предлагаете механизм внесения в белый список серверов пересылки, не относящихся к SRS.
  11. ^ Д. Крокер; Т. Хансен; М. Кучерави, ред. (сентябрь 2011 г.). Подписи идентифицируемой почты DomainKeys (DKIM). IETF . дои : 10.17487/RFC6376 . РФК 6376 . Проверено 18 февраля 2013 г. DomainKeys Identified Mail (DKIM) позволяет человеку, роли или организации брать на себя некоторую ответственность за сообщение, связывая с сообщением доменное имя, которое им разрешено использовать.
  12. ↑ Дэйв Крокер (16 октября 2007 г.). «Часто задаваемые вопросы о DKIM». DKIM.org . Проверено 17 февраля 2013 г.
  13. ^ Э. Оллман; Дж. Фентон; М. Делани; Дж. Левин (август 2009 г.). DomainKeys Identified Mail (DKIM) Практика подписи домена автора (ADSP). IETF . дои : 10.17487/RFC5616 . РФК 5616 . Проверено 18 февраля 2013 г.
  14. ↑ Барри Лейба (25 ноября 2013 г.). «Измените статус ADSP (RFC 5617) на Исторический». IETF .
  15. ^ П. Хоффман; Дж. Левин; А. Хэткок (апрель 2009 г.). Подтверждаем ссылкой. IETF . дои : 10.17487/RFC5518 . РФК 5518 . Проверено 18 февраля 2013 г.
  16. ^ аб Мюррей Кучерави (май 2019 г.). Поле заголовка сообщения для указания статуса аутентификации сообщения. IETF . дои : 10.17487/RFC8601 . РФК 8601 . Проверено 12 июня 2023 г.
  17. ^ Х. Эйднес; Г. де Гроот; П. Викси (март 1998 г.). Бесклассовое делегирование IN-ADDR.ARPA. IETF . дои : 10.17487/RFC2317 . РФК 2317 . Проверено 18 февраля 2013 г.