Як працює електронна пошта?

По-перше, ви використовуєте поштовий агент користувача або MUA для читання та надсилання електронної пошти з вашого пристрою (наприклад, gmail або поштової програми на пристроях Apple). Ці програми активні лише тоді, коли ви ними користуєтесь.

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

Електронні листи зберігаються віддалено, доки ви не відкриєте MUA для перевірки електронної пошти. Електронні листи доставляються агентами доставки пошти (MDA), які зазвичай комплектуються MTA.

Раніше пошта надсилалась на поштовий сервер за допомогою SMTP або простого протоколу передачі пошти. SMTP - це протокол зв'язку для електронної пошти.

Навіть зараз, хоча багато власні системи, такі як Microsoft Exchange та програми веб-пошти, такі як Gmail, використовують власні протоколи всередині, вони використовують SMTP для передачі повідомлень за межами своїх систем (наприклад, якщо користувач Gmail хоче надіслати електронне повідомлення клієнту Outlook).

Потім пошта буде завантажена з сервера за допомогою протоколу Post Office (POP3). POP3 - це протокол рівня додатків, який забезпечує доступ через мережу протоколу Інтернету (IP) для користувацької програми для зв’язку з поштовою скринькою на поштовому сервері. Він може підключатися, отримувати повідомлення, зберігати їх на комп'ютері клієнта, а також видаляти або зберігати на сервері.

Він був розроблений, щоб мати можливість керувати тимчасовими підключеннями до Інтернету, наприклад, комутованим (таким чином, він просто підключався та отримував електронну пошту при підключенні та дозволяв переглядати повідомлення в режимі офлайн). Це було більш популярним, коли комутований доступ був більш поширеним.

Зараз протокол IMAP, протокол доступу до Інтернет-повідомлень, здебільшого замінив POP3. IMAP може дозволити декільком клієнтам керувати однією і тією ж поштовою скринькою (так що ви можете читати свою електронну пошту з робочого столу, ноутбука, телефону тощо, і всі ваші повідомлення будуть там, упорядковані однаково).

Зрештою, веб-пошта замінила обидва. Веб-пошта дозволяє входити на веб-сайт і отримувати повідомлення з будь-якого місця або з будь-якого пристрою (так!), Проте під час його використання вам потрібно бути підключеним до Інтернету. Якщо веб-сайт (наприклад, gmail) є вашим MUA, вам не потрібно знати налаштування SMTP або IMAP-сервера.

Як захищається електронна пошта?

На жаль, безпека насправді не була вбудована в поштові протоколи з самого початку (як і більшість початківських інтернет-протоколів). Сервери просто очікували прийняти будь-яке повідомлення від кого-небудь і передати його на будь-який інший сервер, який може допомогти направити повідомлення до кінцевого пункту призначення (одержувач у полі to:).

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

У відповідь ми спільно спробували реалізувати декілька заходів, які заважають людям читати чужі повідомлення (шифрування), і перевіряємо, що повідомлення насправді надходили від передбачуваного відправника (автентифікація).  

У більшості місць використовується TLS (захист транспортного рівня, заміна SSL, рівень захищених сокетів), криптографічний протокол, який забезпечує шифрування при передачі. Він забезпечує захист, коли повідомлення передається, але не коли дані перебувають у стані спокою (наприклад, зберігаються на вашому комп’ютері).

Це гарантує, що повідомлення не змінюється та не переглядається під час подорожі з MTA на MTA. Однак це не підтверджує, що повідомлення не було змінено під час поїздки.

Наприклад, якщо електронна пошта проходить через кілька поштових серверів до того, як досягне кінцевого пункту призначення, використання TLS забезпечить її зашифрування між серверами, але кожен сервер може змінити вміст повідомлення. Для цього ми створили SPF, DKIM та DMARC.

SPF (Sender Policy Framework)

SPF дозволяє власнику домену (наприклад, google.com) встановити запис TXT у своєму DNS, який визначає, яким серверам дозволено надсилати пошту з цього домену (інструкції щодо того, як це зробити для різних провайдерів хостингу, див. сайт).

Як це працює?

У цьому записі перераховані дозволені пристрої (як правило, за IP), які можуть закінчуватися одним із таких варіантів:

-all = Якщо перевірка не вдається (джерело електронного листа не є одним із перелічених пристроїв), результатом є HardFail. Більшість поштових систем позначатимуть ці повідомлення як спам.

? all = = Якщо перевірка не вдається (джерело електронної пошти не є одним із перелічених пристроїв), результат нейтральний. Це зазвичай використовується для тестування, а не виробничих доменів.

~ all = Якщо перевірка не вдається (джерелом електронного листа не є один із перелічених пристроїв), результатом є SoftFail. Це означає, що це повідомлення підозріле, але не обов’язково є відомим поганим. Деякі поштові системи позначатимуть ці повідомлення як спам, але більшість - не.

Заголовки SPF можуть бути корисними для самих серверів, оскільки вони обробляють повідомлення. Наприклад, якщо сервер знаходиться на краю мережі, він знає, що повідомлення, які він отримує, повинні надходити від серверів у записі SPF відправника. Це допомагає серверам швидше позбавлятися від спаму. Хоча це звучить чудово, на жаль, є кілька основних проблем із SPF.

  1. SPF не повідомляє поштовому серверу, що робити з повідомленням - це означає, що повідомлення може пройти перевірку SPF і все одно доставити.
  2. Запис SPF не дивиться на адресу "від", яку бачить користувач, він дивиться на "шлях повернення". Це в основному еквівалент адреси зворотного зв'язку, яку ви пишете в листі. Він повідомляє поштовим серверам, які обробляють лист, куди повернути повідомлення (і воно зберігається в заголовках електронної пошти - по суті, сервери технічної інформації використовують для обробки електронної пошти).

    Це означає, що я можу помістити все, що хочу, в адресу from: і це не вплине на перевірку SPF. Насправді хакер може відносно підробити обидві ці електронні адреси. Оскільки шифрування не відбувається, заголовкам SPF не можна повністю довіряти.

  3. Записи SPF потрібно постійно оновлювати, що може бути важко у великих організаціях, що постійно змінюються.
  4. Переадресація перерв SPF. Це пов’язано з тим, що якщо електронне повідомлення від, скажімо, google.com, переадресовується через [email protected], відправник конверта залишається незмінним (в адресі from все ще пише google.com). Приймаючий поштовий сервер вважає, що він претендує на адресу google.com, але надходить з bobsburgers.com, тому він не проходить перевірку SPF (хоча пошта насправді надходить з google.com).

Щоб дізнатись більше про SPF, перегляньте ці статті. Ви можете перевірити, чи є в певному домені тут налаштовані записи SPF та DMARC.

DKIM (ідентифікована пошта DomainKeys)

DKIM схожий на SPF. Він також використовує записи TXT у DNS надсилаючого домену, а також забезпечує певну автентифікацію самого повідомлення. Він намагається підтвердити, що повідомлення не були змінені під час передачі.

Як це працює?

Надсилаючий домен генерує пару відкритого / приватного ключів і поміщає відкритий ключ у запис DNS TXT домену (якщо ви не знаєте, що таке пара відкритого / приватного ключа, ознайомтесь із цією статтею з криптографії).

Потім поштові сервери домену (на зовнішній межі - сервери, які надсилають пошту за межами домену (наприклад, з gmail.com на outlook.com)) використовують приватний ключ для генерації підпису всього тіла повідомлення, включаючи заголовки.

Для генерації підпису зазвичай потрібно хешувати та шифрувати текст (докладніше про цей процес читайте в цій статті).

Приймаючі поштові сервери використовують відкритий ключ у записі DNS TXT для дешифрування підпису, а потім хешують повідомлення та відповідні заголовки (будь-які заголовки, створені, коли пошта знаходилася в інфраструктурі відправника - наприклад, якщо кілька серверів gmail обробили електронну пошту до неї) було надіслано зовнішньо на outlook.com).

Потім сервер перевірить, чи відповідають два хеші. Якщо вони це роблять, повідомлення, швидше за все, не змінюється (якщо хтось не скомпрометував приватний ключ відправника) і законно від передбачуваного відправника. Якщо хеші не збігаються, повідомлення надходить або не від передбачуваного відправника, або воно було змінене яким-небудь іншим транзитним сервером, або обидва.

DKIM дуже добре справляється з одним цілком конкретним завданням - відповідаючи на запитання "чи було це повідомлення електронної пошти змінено під час передачі чи ні від передбачуваного відправника?". Однак це все, що він робить. Це не говорить вам про те, як поводитися з електронними листами, які не пройшли цей тест, який сервер міг змінити повідомлення або які зміни були внесені.  

DKIM також використовується деякими постачальниками послуг Інтернету або постачальниками послуг Інтернету для визначення репутації вашого домену (ви надсилаєте багато спаму? Ви мало залучені? Як часто ваші електронні листи підскакують?).

Щоб дізнатись більше про DKIM, перегляньте цю статтю. Ви можете перевірити запис DKIM тут.

DMARC (автентифікація повідомлень на основі домену, звітування та відповідність)

DMARC - це, по суті, інструкції для поштових серверів про те, як обробляти записи SPF та DKIM. Він не виконує власних тестів, але повідомляє поштовим серверам, як обробляти перевірки, які виконують SPF та DKIM.

Інтернет-провайдери, які беруть участь, переглядатимуть опубліковані записи DMARC і використовуватимуть їх, щоб визначити, як боротися з DKIM або SPF не вдається. Так, наприклад, часто підроблений бренд може опублікувати запис DMARC, який говорить, що якщо DKIM або SPF не вдаються, скиньте повідомлення.

Часто постачальники послуг Інтернету також надсилають вам звіти про діяльність вашого домену з джерелом електронного листа та про те, чи передано воно / не вдалося DKIM / SPF. Це означає, що ви зможете побачити, коли люди підробляють (претендують на надсилання) ваш домен або змінюють ваші повідомлення.

Для того, щоб впровадити DMARC, вам потрібно створити запис DMARC, виходячи з ваших потреб (від моніторингу вашого електронного трафіку до з’ясування того, якими є всі ваші джерела електронної пошти, до прохання вжити заходів, таких як відхилення будь-яких електронних листів, які не відповідають DKIM або SPF). Ви можете дізнатись більше про це тут і тут.

Щоб дізнатись більше про DMARC, перегляньте цю статтю. Ви можете перевірити, чи є в певному домені тут налаштовані записи SPF та DMARC.

Загорнути

Жоден із цих заходів безпеки не є досконалим, але разом вони гідно допомагають нам покращити безпеку електронних систем у всьому світі.

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

Однак більшість протоколів, на які покладається поточний Інтернет, були розроблені для раннього Інтернету - для невеликої групи ентузіастів, науковців та урядових людей - а не всесвітньої мережі, в якій ми управляємо будівлями, розумними пристроями, громадським транспортом, атомними електростанціями. (!), і так далі.

Таким чином, оскільки Інтернет продовжує розширюватися, нам потрібно продовжувати адаптуватися та розробляти нові способи захисту систем, на які ми покладаємось.