Аутентификация по электронной почте
Аутентификация электронной почты , или валидация , — это набор методов, направленных на предоставление проверяемой информации о происхождении сообщений электронной почты путем проверки владения доменом любых агентов передачи сообщений (MTA), которые участвовали в передаче и, возможно, изменении сообщения.
Исходная основа электронной почты в Интернете, Simple Mail Transfer Protocol (SMTP), не имеет такой функции, поэтому поддельные адреса отправителей в электронных письмах (практика, известная как подмена электронной почты ) широко используются при фишинге , спаме в электронной почте и различных видах мошенничества. Для борьбы с этим было разработано множество конкурирующих предложений по аутентификации электронной почты. К 2018 году [update] три получили широкое распространение – SPF , DKIM и DMARC . [1] [2] Результаты такой проверки могут быть использованы при автоматической фильтрации электронной почты или могут помочь получателям при выборе подходящего действия.
В этой статье не рассматривается аутентификация пользователей при отправке и получении электронной почты.
Обоснование
[ редактировать ]В начале 1980-х годов, когда был разработан простой протокол передачи почты (SMTP), он не предусматривал реальной проверки отправителя пользователя или системы. Это не было проблемой, пока системы электронной почты управлялись доверенными корпорациями и университетами, но с момента коммерциализации Интернета в начале 1990-х годов спам , фишинг выяснилось, что и другие преступления все чаще связаны с электронной почтой.
Аутентификация электронной почты является необходимым первым шагом на пути к определению происхождения сообщений и, таким образом, к повышению эффективности политики и законов.
Зависимость от владения доменом — это позиция, возникшая в начале 2000 года. [3] [4] Он подразумевает грубую аутентификацию, учитывая, что домены появляются в правой части адресов электронной почты, после знака at . Точная аутентификация на уровне пользователя может быть достигнута другими способами, такими как Pretty Good Privacy и S/MIME . В настоящее время цифровая идентичность должна управляться каждым человеком.
Важным обоснованием аутентификации электронной почты является возможность автоматизировать фильтрацию электронной почты на принимающих серверах. Таким образом, поддельные сообщения могут быть отклонены до того, как они попадут в папку «Входящие» пользователя. В то время как протоколы стремятся разработать способы надежной блокировки ненадежной почты, индикаторы безопасности могут помечать неаутентифицированные сообщения, которые все же попадают в папку «Входящие». Исследование 2018 года показывает, что показатели безопасности могут снизить рейтинг кликов более чем на десять пунктов: от 48,9% до 37,2% пользователей, открывающих поддельные сообщения. [5]
Характер проблемы
[ редактировать ]SMTP определяет транспорт сообщений , а не их содержимое . Таким образом, он определяет почтовый конверт и его параметры, такие как отправитель конверта , но не заголовок (кроме информации трассировки ) и не тело самого сообщения. ЗППП 10 и RFC 5321 определяет SMTP (конверт), а STD 11 и RFC 5322 определяет сообщение (заголовок и тело), формально называемое форматом интернет-сообщения .
SMTP определяет информацию трассировки сообщения, которая сохраняется в заголовке с использованием следующих двух полей: [6]
- Получено : когда SMTP-сервер принимает сообщение, он вставляет эту запись трассировки вверху заголовка (от последней к первой).
- Return-Path : когда SMTP-сервер доставки осуществляет окончательную доставку сообщения, он вставляет это поле вверху заголовка.
Почтовый агент пользователя (MUA) знает SMTP-сервер исходящей почты из своей конфигурации. MTA (или сервер ретрансляции) обычно определяет, к какому серверу подключиться, просматривая запись ресурса MX (Mail eXchange) DNS- каждого получателя для доменного имени .
Путь, изображенный ниже, можно реконструировать на основе полей заголовка трассировки , которые каждый хост добавляет в начало заголовка при получении сообщения: [6]
Return-Path: <[email protected]>
Received: from D.example.org by E.example.org with SMTP; Tue, 05 Feb 2013 11:45:02 -0500
Received: from C.example.net by D.example.org with SMTP; Tue, 05 Feb 2013 11:45:02 -0500
Received: from B.example.com (b.example.com [192.0.2.1])
by C.example.net (which is me) with ESMTP id 936ADB8838C
for <[email protected]>; Tue, 05 Feb 2013 08:44:50 -0800 (PST)
Received: from A.example.com by B.example.com with SMTP; Tue, 05 Feb 2013 17:44:47 +0100
Received: from [192.0.2.27] by A.example.com with SMTP; Tue, 05 Feb 2013 17:44:42 +0100
Получатель обычно доверяет первым нескольким строкам в верхней части заголовка. Эти строки пишутся машинами в домене административного управления ( ADMD ) получателя, которые действуют в соответствии со своими явными полномочиями. Напротив, строки, доказывающие причастность A и B предполагаемого автора, , а также MUA могут быть подделкой, C. созданной Received: Поле, показанное выше, является эпохальным фрагментом заголовка. Return-Path: пишется E , агентом доставки почты (MDA), на основе конверта сообщения . Дополнительные поля трассировки, предназначенные для аутентификации электронной почты, могут заполняться в верхней части заголовка.
Обычно сообщения, отправленные ADMD автора, попадают непосредственно в MX адресата (то есть B → D на рисунках). ADMD отправителя может добавлять токены аутентификации только в том случае, если сообщение проходит через его ящики. Наиболее распространенные случаи можно схематично представить следующим образом:
Отправка из сети ADMD (MUA 1)
[ редактировать ]- ADMD MSA аутентифицирует пользователя либо на основе его IP-адреса , либо на основе других средств аутентификации SMTP. В зависимости от адреса получателя сообщение может следовать обычным путем или пройти через список рассылки или службу пересылки. [примечание 1] B может быть исходящим SMTP-прокси или смарт-хостом . [примечание 2]
- Если локальная сеть не блокирует исходящие соединения через порт 25, [примечание 3] пользователь может развернуть некоторое программное обеспечение «direct-to-mx». [примечание 4] Обычно зомби и другие вредоносные хосты ведут себя именно так.
- Если MUA плохо настроен, он также может использовать другое реле, например устаревшее открытое реле , которое часто не аутентифицирует пользователя.
Пользователь роуминга (MUA 2)
[ редактировать ]- В большинстве случаев все еще возможно использовать собственный ADMD MSA. [примечание 5]
- Исходящие соединения к порту 25 могут быть перехвачены и туннелированы на прозрачный прокси-сервер. [примечание 4]
- MUA можно настроить на использование ретранслятора SMTP, который провайдер локальной сети предлагает в качестве бонуса. [примечание 4]
Отключенный пользователь
[ редактировать ]- Электронная карта может отправлять почту от имени клиента, который набрал адреса электронной почты на локальной клавиатуре; можно считать, что некоторые веб-формы работают аналогичным образом. [примечание 4]
Примечания к разделу
[ редактировать ]- ^ Например, получатель может поручить Gmail пересылать сообщения на другой адрес электронной почты. Отправитель не обязательно знает об этом.
- ^ Правильно настроенные прокси появляются как часть ADMD автора.
- ^ Некоторые ADMD блокируют исходящее соединение с портом 25 (SMTP), чтобы избежать этого. Этот упреждающий метод описан в RFC 5068. Кроме того, некоторые блокируют входящие SMTP-соединения с IP-адресов , перечисленных как коммутируемое соединение /DSL/кабельное соединение.
- ^ Перейти обратно: а б с д В данном случае СДВД автора вообще не задействован.
- ^ Некоторые интернет-провайдеры блокируют порт 587, хотя в RFC 5068 четко сказано:
Поставщики доступа НЕ ДОЛЖНЫ блокировать пользователям доступ к внешнему Интернету с использованием порта ПОДАЧИ 587.
Широко используемые методы аутентификации
[ редактировать ]СПФ
[ редактировать ]
SPF позволяет получателю проверить, что электронное письмо, якобы полученное из определенного домена, исходит с IP-адреса, авторизованного администраторами этого домена. Обычно администратор домена авторизует IP-адреса, используемые его собственными исходящими MTA, включая любые прокси-серверы или смарт-хосты. [7] [8]
IP-адрес отправляющего MTA гарантированно действителен согласно протоколу управления передачей , поскольку он устанавливает соединение, проверяя доступность удаленного хоста. [9] Принимающий почтовый сервер получает HELO Команда SMTP вскоре после установки соединения и Mail from: в начале каждого сообщения. Оба они могут содержать доменное имя. Средство проверки SPF запрашивает у системы доменных имен (DNS) соответствующую запись SPF, которая, если она существует, будет указывать IP-адреса, авторизованные администратором этого домена. Результатом может быть «пройдено», «не пройдено» или какой-либо промежуточный результат, и системы обычно учитывают это при фильтрации спама. [10]
ДКИМ
[ редактировать ]
DKIM проверяет содержимое сообщения , применяя цифровые подписи . Вместо использования цифровых сертификатов ключи для проверки подписи распространяются через DNS. Таким образом, сообщение будет связано с доменным именем. [11]
Администратор домена, совместимый с DKIM, генерирует одну или несколько пар асимметричных ключей , затем передает закрытые ключи подписывающему MTA и публикует открытые ключи в DNS. Метки DNS структурированы как selector._domainkey.example.com, где селектор идентифицирует пару ключей, и _domainkey — это фиксированное ключевое слово, за которым следует имя подписывающего домена, чтобы публикация происходила под управлением ADMD этого домена. Непосредственно перед внедрением сообщения в транспортную систему SMTP подписывающий MTA создает цифровую подпись, которая охватывает выбранные поля заголовка и тела (или только его начало). Подпись должна охватывать основные поля заголовка, такие как From:, To:, Date:, и Subject:, а затем добавляется в сам заголовок сообщения как поле трассировки. Любое количество ретрансляторов может получать и пересылать сообщение, и на каждом прыжке подпись может быть проверена путем получения открытого ключа из DNS. [12] Пока промежуточные ретрансляторы не изменяют подписанные части сообщения, его DKIM-подписи остаются действительными.
ДМАРК
[ редактировать ]DMARC позволяет указать политику для аутентифицированных сообщений. Он построен на основе двух существующих механизмов: инфраструктуры политики отправителей (SPF) и почты, идентифицированной по ключам домена (DKIM).
Это позволяет администратору домена публиковать политику в своих записях DNS , чтобы указать, какой механизм (DKIM, SPF или оба) используется при отправке электронной почты из этого домена; как проверить From: поле, представленное конечным пользователям; как получатель должен реагировать на сбои, а также механизм отчетности о действиях, выполненных в соответствии с этими политиками.
Другие методы
[ редактировать ]Был предложен ряд других методов, но сейчас они либо устарели, либо еще не получили широкой поддержки. К ним относятся идентификатор отправителя , проверка сертифицированного сервера , ключи домена и перечисленные ниже:
АДСП
[ редактировать ]ADSP позволил указать политику для сообщений, подписанных доменом автора. Сообщение должно было сначала пройти аутентификацию DKIM, после чего ADSP мог потребовать применения наказания, если сообщение не было подписано доменом(ами) автора — согласно From: поле заголовка. [13]
ADSP был понижен до исторического уровня в ноябре 2013 года. [14]
ВБР
[ редактировать ]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 результаты :
Authentication-Results: receiver.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.
Управление по присвоению номеров в Интернете ведет реестр параметров аутентификации электронной почты . Однако не все параметры необходимо регистрировать. Например, могут существовать локальные значения «политики», предназначенные только для внутреннего использования сайта, которые соответствуют локальной конфигурации и не требуют регистрации.
См. также
[ редактировать ]- DMARC – Система предотвращения мошенничества с электронной почтой
- Шифрование электронной почты
- Подмена электронной почты — создание спама или фишинговых сообщений по электронной почте с поддельной личностью или адресом отправителя.
- Идентификатор — Интернет-протокол, который помогает идентифицировать пользователя определенного TCP-соединения.
- Безопасный обмен сообщениями
Ссылки
[ редактировать ]- ^ Ханг Ху; Пэн Пэн; Ган Ван (2017). «На пути к принятию протоколов борьбы со спуфингом». arXiv : 1711.06654 [ cs.CR ].
- ^ Кернер, Шон Майкл (2 января 2018 г.). «В правительстве США растет внедрение системы безопасности электронной почты DMARC» . электронная неделя . Проверено 24 ноября 2018 г.
- ^ «Саммит по аутентификации электронной почты» . мастерская . Федеральная торговая комиссия . 9–10 ноября 2004 г. Архивировано из оригинала 3 июня 2012 г. . Проверено 4 февраля 2013 г.
Однако в отчете аутентификация на уровне домена названа многообещающей технологической разработкой.
{{cite web}}: CS1 maint: неподходящий URL ( ссылка ) - ^ Майкл Хаммер (14 августа 2020 г.). «разрешение третьей стороны» . dmarc-ietf (список рассылки) . Проверено 14 августа 2020 г.
- ^ Ханг Ху; Ган Ван (15 августа 2018 г.). Сквозные измерения атак спуфинга электронной почты . стр. 1095–1112. ISBN 9781939133045 .
{{cite book}}:|work=игнорируется ( помогите ) - ^ Перейти обратно: а б Джон Кленсин (октябрь 2008 г.). «Информация о следах» . Простой протокол передачи почты . IETF . сек. 4.4. дои : 10.17487/RFC5321 . РФК 5321 . Проверено 1 февраля 2013 г.
Когда SMTP-сервер принимает сообщение либо для ретрансляции, либо для окончательной доставки, он вставляет запись трассировки (также называемую взаимозаменяемо «строкой отметки времени» или «строкой получения») вверху почтовых данных. Эта запись трассировки указывает идентификатор узла, отправившего сообщение, идентификатор узла, получившего сообщение (и вставляющего эту отметку времени), а также дату и время получения сообщения. Ретранслируемые сообщения будут иметь несколько строк отметок времени.
- ^ Скотт Киттерман (апрель 2014 г.). Структура политики отправителей (SPF) для авторизации использования доменов в электронной почте, версия 1 . IETF . дои : 10.17487/RFC7208 . РФК 7208 . Проверено 26 апреля 2014 г.
Есть три места, где можно использовать методы для устранения непреднамеренных сбоев SPF с помощью медиаторов.
- ^ Дж. Кленсин (октябрь 2008 г.). "Псевдоним " Простой протокол передачи почты . IETF . сек. 3.9.1. дои : 10.17487/RFC5321 . РФК 5321 . Получено 15 февраля.
- ^ Подделка IP-адреса возможна, но обычно предполагает более низкий уровень преступного поведения (взлом и проникновение, прослушивание телефонных разговоров и т. д.), которые слишком опасны для типичного хакера или спамера, или небезопасных серверов, не реализующих RFC 1948, см. также Управление передачей . Протокол#Перехват соединения .
- ^ Скотт Киттерман (21 ноября 2009 г.). «Насколько надежно блокировать/отклонять в случае сбоя SPF?» . spf-помощь . gossamer-threads.com.
Я думаю, что в целом это нормально, если вы предлагаете механизм внесения в белый список серверов пересылки, не относящихся к SRS.
- ^ Д. Крокер; Т. Хансен; М. Кучерави, ред. (сентябрь 2011 г.). Подписи идентифицируемой почты DomainKeys (DKIM) . IETF . дои : 10.17487/RFC6376 . РФК 6376 . Проверено 18 февраля 2013 г.
DomainKeys Identified Mail (DKIM) позволяет человеку, роли или организации брать на себя некоторую ответственность за сообщение, связывая с сообщением доменное имя, которое им разрешено использовать.
- ^ Дэйв Крокер (16 октября 2007 г.). «Часто задаваемые вопросы по DKIM» . DKIM.org . Проверено 17 февраля 2013 г.
- ^ Э. Оллман; Дж. Фентон; М. Делани; Дж. Левин (август 2009 г.). DomainKeys Identified Mail (DKIM) Практика подписи домена автора (ADSP) . IETF . дои : 10.17487/RFC5616 . РФК 5616 . Проверено 18 февраля 2013 г.
- ^ Барри Лейба (25 ноября 2013 г.). «Изменить статус ADSP (RFC 5617) на Исторический» . IETF .
- ^ П. Хоффман; Дж. Левин; А. Хэткок (апрель 2009 г.). Подтверждаем ссылкой . IETF . дои : 10.17487/RFC5518 . РФК 5518 . Проверено 18 февраля 2013 г.
- ^ Перейти обратно: а б Мюррей Кучерави (май 2019 г.). Поле заголовка сообщения для указания статуса аутентификации сообщения . IETF . дои : 10.17487/RFC8601 . РФК 8601 . Проверено 12 июня 2023 г.
- ^ Х. Эйднес; Г. де Гроот; П. Викси (март 1998 г.). Бесклассовое делегирование IN-ADDR.ARPA . IETF . дои : 10.17487/RFC2317 . РФК 2317 . Проверено 18 февраля 2013 г.