Из Википедии, бесплатной энциклопедии
Перейти к навигации Перейти к поиску

Аутентификация или проверка электронной почты - это набор методов, направленных на предоставление проверяемой информации о происхождении сообщений электронной почты путем проверки права собственности на домен любых агентов передачи сообщений (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]

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

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

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

Аутентификация электронной почты может быть затруднена из-за наличия промежуточного ретранслятора. A и B явно принадлежат автору ADMD, в то время как D и E являются частью сети получателя. Какую роль играет C ?
Обратный путь: <[email protected]> Поступила в редакцию:  от 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         для <[email protected]> ; Вт, 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. ^ a b c d В данном случае ADMD автора вообще не задействован.
  5. ^ Некоторые интернет-провайдеры блокируют порт 587, хотя в RFC 5068 четко сказано:

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

Широко распространенные методы аутентификации [ править ]

SPF [ править ]

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

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

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

DKIM [ править ]

Основная статья: Почта, идентифицированная с помощью DomainKeys
DKIM аутентифицирует части содержимого сообщения.

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

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

DMARC [ править ]

Основная статья: Доменная проверка подлинности сообщений, отчетность и соответствие

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

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

Другие методы [ править ]

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

ADSP [ править ]

Основная статья: Правила подписи авторского домена

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

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

VBR [ править ]

Основная статья: Подтверждение по ссылке

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

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

iprev [ править ]

Основная статья: Обратный DNS с прямым подтверждением

Приложениям следует избегать использования этого метода в качестве средства аутентификации. [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 = передать smtp.mailfrom = example.com ;  dkim = передать [email protected]

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

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

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

См. Также [ править ]

  • DMARC  - система предотвращения мошенничества с электронной почтой
  • Шифрование электронной почты
  • Подмена  электронной почты - создание спама или фишинговых сообщений электронной почты с поддельными идентификационными данными или адресом отправителя.
  • Ident  - Интернет-протокол, который помогает идентифицировать пользователя определенного TCP-соединения.
  • Безопасный обмен сообщениями

Ссылки [ править ]

  1. ^ Ханг Ху; Пэн Пэн; Ганг Ван (2017). «На пути к принятию протоколов защиты от спуфинга». arXiv : 1711.06654 [ cs.CR ].
  2. ^ Кернер, Шон Майкл. «Принятие DMARC безопасности электронной почты растет в правительстве США» . eWeek . Проверено 24 ноября 2018 года .
  3. ^ "Саммит проверки подлинности электронной почты" . мастерская . Федеральная торговая комиссия . 9-10 ноября 2004 года Архивировано из первоисточника 3 июня 2012 . Проверено 4 февраля 2013 года . Однако в отчете аутентификация на уровне домена была определена как многообещающая технологическая разработка.CS1 maint: неподходящий URL ( ссылка )
  4. ↑ Майкл Хаммер (14 августа 2020 г.). «авторизация третьей стороны» . dmarc-ietf (список рассылки) . Дата обращения 14 августа 2020 .
  5. ^ Ханг Ху; Ганг Ван (15 августа 2018 г.). «Сквозные измерения атак с использованием спуфинга электронной почты» . 27-й симпозиум по безопасности USENIX .
  6. ^ a b Джон Кленсин (октябрь 2008 г.). «Информация о трассировке» . Простой протокол передачи почты . IETF . сек. 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). «Псевдоним» . Простой протокол передачи почты . IETF . сек. 3.9.1. DOI : 10,17487 / RFC5321 . RFC 5321 . Проверено 15 февраля 2013 года .
  9. ^ Подделка IP-адреса возможна, но обычно связана с более низким уровнем преступного поведения (взлом и проникновение, прослушивание телефонных разговоров и т. Д.), Что слишком рискованно для типичного хакера или спамера, или небезопасные серверы, не реализующие RFC 1948, см. Также Управление передачей Протокол # Перехват соединения .
  10. ^ Скотт Kitterman (21 ноября 2009). «Насколько надежно блокировать / отклонять при сбое SPF?» . spf-help . gossamer-threads.com. Я думаю, это нормально, если вы предлагаете механизм для внесения в белый список серверов пересылки, не поддерживающих SRS.
  11. ^ Д. Крокер; Т. Хансен; М. Кучерави, ред. (Сентябрь 2011 г.). Подпись электронной почты с идентификацией ключей (DKIM) . IETF . DOI : 10,17487 / RFC6376 . RFC 6376 . Проверено 18 февраля 2013 года . DomainKeys Identified Mail (DKIM) позволяет человеку, роли или организации брать на себя некоторую ответственность за сообщение, связывая доменное имя с сообщением, которое им разрешено использовать.
  12. ↑ Дэйв Крокер (16 октября 2007 г.). «Часто задаваемые вопросы DKIM» . DKIM.org . Проверено 17 февраля 2013 года .
  13. ^ Э. Оллман; Дж. Фентон; М. Делани; Дж. Левин (август 2009 г.). Почта с идентификационными ключами домена (DKIM). Правила подписи домена (ADSP) автора . IETF . DOI : 10,17487 / RFC5616 . RFC 5616 . Проверено 18 февраля 2013 года .
  14. ↑ Барри Лейба (25 ноября 2013 г.). «Измените статус ADSP (RFC 5617) на Исторический» . IETF .
  15. ^ П. Хоффман; Дж. Левин; А. Хэткок (апрель 2009 г.). Поручиться по ссылке . IETF . DOI : 10,17487 / RFC5518 . RFC 5518 . Проверено 18 февраля 2013 года .
  16. ^ a b Мюррей Кучерави (август 2015 г.). Поле заголовка сообщения для индикации статуса аутентификации сообщения . IETF . DOI : 10,17487 / RFC7601 . RFC 7601 . Проверено 30 сентября 2015 года .
  17. ^ Х. Эйднес; Г. де Гроот; П. Викси (март 1998 г.). Бесклассовое делегирование IN-ADDR.ARPA . IETF . DOI : 10,17487 / RFC2317 . RFC 2317 . Проверено 18 февраля 2013 года .