Аутентифікація електронної пошти

Автентифікація електронної пошти або перевірка — це набір методів, спрямованих на надання інформації про походження повідомлень електронної пошти шляхом перевірки права власності на домен будь-яких агентів передачі повідомлень (MTA), які брали участь у передачі та, можливо, зміні повідомлення.

Оригінальна основа електронної пошти в Інтернеті, Simple Mail Transfer Protocol (SMTP), не має такої функції, тому підроблені адреси відправника в електронних листах (практика, відома як підробка електронної пошти) широко використовуються для фішингу, спаму електронної пошти та різних видів шахрайства. Щоб боротися з цим, було розроблено багато конкуруючих пропозицій автентифікації електронної пошти, але лише нещодавно отримали широке поширення три — SPF, DKIM і DMARC. Результати такої перевірки можуть бути використані в автоматизованому фільтруванні електронної пошти або можуть допомогти одержувачам під час вибору відповідної дії.

У цій статті не розглядається автентифікація користувачів під час надсилання та отримання електронних листів.

Обґрунтування

На початку 1980-х років, коли був розроблений простий протокол передачі пошти (SMTP), він не передбачав реальної перевірки користувача або системи, що відправляє. Це не було проблемою, поки системами електронної пошти керували перевірені корпорації та університети, але після комерціалізації Інтернету на початку 1990-х років спам, фішинг та інші злочини все частіше стосуються електронної пошти. Автентифікація електронної пошти є необхідним першим кроком до визначення походження повідомлень і, таким чином, підвищення ефективності політики та законів.

На початку 2000 року виникла позиція щодо власності на домен. Це передбачає грубу автентифікацію, оскільки домени відображаються в правій частині адрес електронної пошти після значка at. Точну автентифікацію на рівні користувача можна досягти за допомогою інших засобів, таких як Pretty Good Privacy та S/MIME. Наразі цифровою ідентичністю має керувати кожен окремо.

Важливим аргументом для автентифікації електронної пошти є можливість автоматизувати фільтрацію електронної пошти на серверах-одержувачах. Таким чином, підроблені повідомлення можуть бути відхилені до того, як вони надходять до папки «Вхідні» користувача. У той час як протоколи прагнуть розробити способи надійного блокування ненадійної пошти, індикатори безпеки можуть позначати неавтентифіковані повідомлення, які все ще надходять до папки «Вхідні». Дослідження 2018 року показує, що показники безпеки можуть знизити коефіцієнт кліків більш ніж на десять пунктів, з 48,9 % до 37,2 % користувачів, які відкривають підроблені повідомлення.

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

SMTP визначає транспортування повідомлень, а не вміст повідомлення. Таким чином, він визначає поштовий конверт та його параметри, такі як відправник конверта, але не заголовок (крім інформації трасування), і не тіло самого повідомлення. Стандарти STD 10 та RFC 5321 визначають SMTP (конверт), тоді як STD 11 іRFC 5322 визначають повідомлення (заголовок і тіло), яке офіційно називається форматом Інтернет-повідомлення.

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

• Отримано: коли SMTP-сервер приймає повідомлення, він вставляє цей запис трасування у верхній частині заголовка (від останнього до першого).
• Шлях повернення (Return-Path): коли SMTP-сервер доставки здійснює остаточну доставку повідомлення, він вставляє це поле у верхній частині заголовка.

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

Шлях, зображений нижче, можна реконструювати на основі полів заголовка трасування, які кожен хост додає до верхньої частини заголовка, коли отримує повідомлення:

Автентифікація електронної пошти може бути ускладнена наявністю проміжного реле. A і B явно належать до домену адміністративного управління автора, тоді як D і E є частиною мережі одержувачів. Яку роль відіграє С ?

Return-Path: <[e-mail]> 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 <[e-mail]>; 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)

• MSA ADMD атентифікує користувача на основі його IP-адреси або інших засобів автентифікації SMTP. Залежно від адреси одержувача повідомлення може проходити звичайним шляхом або проходити через список розсилки або службу пересилання. B може бути вихідним SMTP-проксі або смарт-хостом.
• Якщо локальна мережа не блокує вихідні з'єднання через порт 25, користувач може розгорнути певне програмне забезпечення «direct-to-mx». Зазвичай так поводяться зомбі та інші шкідливі хости.
• Якщо MUA погано налаштований, він також може використовувати інший ретранслятор, наприклад застарілий відкритий ретранслятор, який часто не автентифікує користувача.

Користувач у роумінгу (MUA 2)

• У більшості випадків все ще можна використовувати власний ADMD MSA.
• Вихідні підключення до порту 25 можуть бути перехоплені та тунельовані до прозорого проксі-сервера.
• MUA можна налаштувати на використання ретранслятора SMTP, який провайдер локальної мережі пропонує як бонус.

Відключений користувач

• Цифрова листівка може надсилати пошту від імені клієнта, який ввів адресу електронної пошти на локальній клавіатурі; можна вважати, що деякі вебформи працюють аналогічно.

Примітки до розділу

1. Наприклад, одержувач може вказати Gmail куди пересилати повідомлення на іншу електронну адресу. Відправник не обов'язково про це знає.
2. Правильно налаштовані проксі відображаються як частина ADMD автора.
3. Деякі ADMD блокують вихідне підключення до порту 25 (SMTP), щоб уникнути цього. Ця проактивна техніка описана в RFC 5068. Крім того, деякі блокують вхідні SMTP-з'єднання з IPs зазначений як dialup/DSL/cable.
4. В даному випадку про ADMD автора взагалі не йдеться.
5. Деякі провайдери блокують порт 587, хоча RFC 5068 чітко говорить:

Використовувані методи аутентифікації

SPF

SPF автентифікує IP-адресу відправника.

SPF дозволяє одержувачу перевірити, чи електронний лист, який, як стверджується, надійшов із певного домену, надходить з IP-адреси, авторизованої адміністраторами цього домену. Зазвичай адміністратор домену авторизує IP-адреси, які використовуються його власними вихідними MTA, включаючи будь-який проксі-сервер або смарт-хост.

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

DKIM

DKIM аутентифікує частини вмісту повідомлення.

DKIM перевіряє вміст повідомлення, розгортаючи цифрові підписи. Замість використання цифрових сертифікатів ключі для перевірки підпису поширюються через DNS. Таким чином, повідомлення пов'язується з доменним ім'ям.

Адміністратор домену, сумісний із DKIM, генерує одну або кілька пар асиметричних алгоритмів шифрування, потім передає приватні ключі MTA, що підписує, і публікує відкриті ключі в DNS. Мітки DNS структуровані як selector . _domainkey.example.com, де селектор ідентифікує пару ключів, а _domainkey — це фіксоване ключове слово, за яким іде ім'я підписуючого домену, щоб публікація відбувалася під контролем ADMD цього домену. Безпосередньо перед введенням повідомлення в транспортну систему SMTP підписуючий MTA створює цифровий підпис, який охоплює вибрані поля заголовка та тіла (або лише його початок). Підпис має охоплювати основні поля заголовка, такі як From:, To:, Date:, і Subject:, а потім додається до самого заголовка повідомлення як поле трасування. Будь-яка кількість ретрансляторів може отримати та пересилати повідомлення, і на кожному стрибку підпис може бути перевірений шляхом отримання відкритого ключа з DNS. Поки проміжні ретранслятори не змінюють підписані частини повідомлення, його DKIM-підписи залишаються дійсними.

DMARC

DMARC дозволяє вказувати політику для автентифікованих повідомлень. Він створений на основі двох існуючих механізмів: Sender Policy Framework (SPF) і DomainKeys Identified Mail (DKIM).

Це дозволяє адміністративному власнику домену публікувати політику в своїх DNS-записах, щоб указати, який механізм (DKIM, SPF або обидва) використовується під час надсилання електронної пошти з цього домену; як перевірити поле From:, представлене кінцевим користувачам; як одержувач повинен справлятися з помилками — і механізм звітування про дії, виконані відповідно до цих політик.

Інші методи

Було запропоновано низку інших методів, але зараз вони або застаріли, або ще не отримали широкої підтримки. До них належать — ідентифікатор відправника, перевірка сертифікованого сервера, ключі домену та наведені нижче:

ADSP

ADSP дозволив специфікацію політики для повідомлень, підписаних доменом автора. Повідомлення повинно було спочатку пройти автентифікацію DKIM, а потім ADSP міг вимагати каральної обробки, якщо повідомлення не було підписане доменом(-ами) автора — відповідно до поля заголовка From:

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

VBR

VBR додає гарантію до вже аутентифікованої особи. Для цього методу потрібні всесвітньо визнані органи, які сертифікують репутацію доменів.

Відправник може подати заявку на отримання довідки до ваучерного органу. Посилання, якщо воно прийняте, публікується у гілці DNS, яким керує цей орган. Гарантований відправник повинен додати поле заголовка VBR-Info: до повідомлень, які він надсилає. Він також повинен додати підпис DKIM або використовувати інший метод автентифікації, наприклад SPF. Одержувач після підтвердження особи відправника, може перевірити гарантію, заявлену в VBR-Info: шляхом пошуку посилання.

iprev

Програми повинні уникати використання цього методу як засобу автентифікації. Незважаючи на це, його часто використовують, а його результати, якщо такі є, записують у поле заголовка Received: окрім інформації TCP, яка вимагається специфікацією SMTP.

Зворотня IP-адреса, підтверджена пошуком IP-адреси щойно знайденого імені, є лише ознакою того, що IP-адресу була правильно налаштовано в DNS. Зворотне вирішення діапазону IP-адрес може бути делеговано ADMD, який їх використовує, або може залишатися під керуванням провайдера мережі. В останньому випадку неможливо отримати корисну ідентифікаційну інформацію, пов'язану з повідомленням.

DNSWL

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

Автентифікація-результати

RFC 8601 визначає поле заголовка трасування Authentication-Results: де одержувач може записати результати перевірок автентифікації електронної пошти, які він виконав. Кілька результатів для кількох методів можна повідомити в одному полі, розділивши їх крапкою з комою та обернувши відповідним чином.

Наприклад, таке поле нібито створено receiver.example.org і повідомляє про результати SPF та DKIM:

Authentication-Results: receiver.example.org;  spf=pass smtp.mailfrom=example.com;  dkim=pass header.i=@example.com 

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

Для поштового агента користувача (MUA) трохи важче дізнатися, яким ідентифікаторам він може довіряти. Оскільки користувачі можуть отримувати електронну пошту з кількох доменів — наприклад, якщо у них є кілька адрес електронної пошти — будь-який з цих доменів може пропускати поля Authentication-Results: оскільки вони виглядають нейтральними. Таким чином, зловмисний відправник може підробити ідентифікатор authserv, якому користувач довіряв би, якби повідомлення надійшло з іншого домену. Справжні Authentication-Results: зазвичай з'являються відразу над полем Received: тим самим доменом, з якого було передано повідомлення. Додатково Received: поля можуть з'являтися між цим і верхньою частиною заголовка, оскільки повідомлення було передано внутрішньо між серверами, що належать тому самому довіреному ADMD.

Орган з присвоєння номерів Інтернету веде реєстр параметрів автентифікації електронної пошти[ 7 квітня 2022 у Wayback Machine.]. Однак не всі параметри потрібно реєструвати. Наприклад, можуть існувати локальні значення «політики», розроблені лише для внутрішнього використання сайту, які відповідають локальній конфігурації і не потребують реєстрації.

Див. також

• DMARC – технологія, що дозволяє отримувачу електронної пошти перевірити справжність її відправника;
• Шифрування електронної пошти;
• Ident — протокол, описаний в RFC 1413, призначений для ідентифікації користувача, який встановлює TCP — з'єднання.

Примітки

1. A bot will complete this citation soon. Click here to jump the queue«Towards the Adoption of Anti-spoofing Protocols». MISSING LINK.. 
2. kerner, Sean Michael. DMARC Email Security Adoption Grows in U.S. Government. eWeek. Процитовано 24 листопада 2018. 
3. . workshop. Federal Trade Commission. November 9–10, 2004. Архів оригіналу за 3 June 2012. Процитовано 4 лютого 2013. «The Report, however, identified domain-level authentication as a promising technological development» 
4. Hang Hu; Gang Wang (15 серпня 2018). . 27th USENIX Security Symposium. Архів оригіналу за 19 лютого 2022. Процитовано 19 лютого 2022. 
5. [[[:Шаблон:Cite IETF/makelink]] Simple Mail Transfer Protocol]. Шаблон:Cite IETF/doctypes.  {{citation}}: Проігноровано невідомий параметр |mode= (довідка)
6. [[[:Шаблон:Cite IETF/makelink]] Sender Policy Framework (SPF) for Authorizing Use of Domains in E-Mail, Version 1]. doi:10.17487/RFC7208. Шаблон:Cite IETF/doctypes.  {{citation}}: Проігноровано невідомий параметр |mode= (довідка)
7. [[[:Шаблон:Cite IETF/makelink]] Simple Mail Transfer Protocol]. doi:10.17487/RFC5321. Шаблон:Cite IETF/doctypes.  {{citation}}: Проігноровано невідомий параметр |mode= (довідка)
8. IP Address forgery is possible, but generally involves a lower level of criminal behavior (breaking and entering, wiretapping, etc.), which are too risky for a typical hacker or spammer, or insecure servers not implementing RFC 1948, see also Transmission Control Protocol#Connection hijacking.
9. Scott Kitterman (21 листопада 2009). . spf-help. gossamer-threads.com. Архів оригіналу за 7 травня 2016. Процитовано 19 лютого 2022. «I think it's generally fine as long as you offer a mechanism for whitelisting of non-SRS forwarders.» 
10. [[[:Шаблон:Cite IETF/makelink]] DomainKeys Identified Mail (DKIM) Signatures]. doi:10.17487/RFC6376. Шаблон:Cite IETF/doctypes.  {{citation}}: Проігноровано невідомий параметр |mode= (довідка)
11. Dave Crocker (16 жовтня 2007). . DKIM.org. Архів оригіналу за 29 вересня 2017. Процитовано 17 лютого 2013. 
12. [[[:Шаблон:Cite IETF/makelink]] DomainKeys Identified Mail (DKIM) Author Domain Signing Practices (ADSP)]. Шаблон:Cite IETF/doctypes.  {{citation}}: Проігноровано невідомий параметр |mode= (довідка)
13. Barry Leiba (25 листопада 2013). . IETF. Архів оригіналу за 5 березня 2016. Процитовано 19 лютого 2022. 
14. [[[:Шаблон:Cite IETF/makelink]] Vouch By Reference]. doi:10.17487/RFC5518. Шаблон:Cite IETF/doctypes.  {{citation}}: Проігноровано невідомий параметр |mode= (довідка)
15. [[[:Шаблон:Cite IETF/makelink]] Message Header Field for Indicating Message Authentication Status]. Шаблон:Cite IETF/doctypes.  {{citation}}: Проігноровано невідомий параметр |mode= (довідка)
16. [[[:Шаблон:Cite IETF/makelink]] Classless IN-ADDR.ARPA delegation]. doi:10.17487/RFC2317. Шаблон:Cite IETF/doctypes.  {{citation}}: Проігноровано невідомий параметр |mode= (довідка)