Електронна пошта: плутанина S/MIME та TLS — що справді покращує безпеку

Що TLS і S/MIME реально роблять (і чого не роблять)

TLS для пошти: захищає дорогу, а не посилку

Коли кажуть «пошта зашифрована», зазвичай мають на увазі: «наш поштовий сервер використовує TLS при обміні з іншими серверами».
Це шифрування транспорту. Воно захищає дані під час передачі між:

• вашим клієнтом і провайдером (IMAPS/POP3S/HTTPS), та/або
• вашим вихідним поштовим сервером і вхідним сервером отримувача (SMTP з STARTTLS).

Це важливо. Без TLS будь-хто, хто має доступ до мережевого шляху, може прослуховувати повідомлення.
З TLS пасивне перехоплення стає набагато складнішим.

Але TLS не означає наскрізної приватності. Ваше повідомлення все ще:

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

TLS — як замкнений вантажівка-кур’єр. Працівники складу все одно відкривають кожну коробку при отриманні.

S/MIME: захищає посилку, але вимагає справжньої адресної книги й дисципліни

S/MIME підписує та/або шифрує вміст повідомлення за допомогою сертифікатів користувачів.
Дві різні функції:

• Цифровий підпис (цілісність + автентифікація відправника, за умови довіри до сертифіката): підтверджує, що повідомлення не було змінене, і прив’язує його до ключа підпису.
• Шифрування (конфіденційність): лише отримувачі з відповідними приватними ключами можуть розшифрувати.

Це ближче до «наскрізного» захисту, але будьте обережні з цим словосполученням. Якщо ви розшифровуєте на шлюзі
для сканування, архівування або додавання банерів, ви просто змістили «кінець» з пристрою користувача на шлюз.
Іноді це прийнятно. Іноді це сама суть. Просто називайте речі своїми іменами.

Загальне непорозуміння в одному реченні

TLS захищає транспорт покроково; S/MIME захищає об’єкт повідомлення наскрізно (або хоча б через кілька хопів), але залежить від управління сертифікатами.

Короткий жарт №1: Якщо в політиці написано «пошта зашифрована» без уточнення TLS чи S/MIME, це зашифровано так само, як «ми все моніторимо» означає «у нас десь є дашборд».

Що найчастіше покращує безпеку

У реальному корпоративному середовищі найбільшими факторами зниження ризику зазвичай не є «увімкніть S/MIME усюди».
Це:

1. Коректний транспортний захист (TLS, який дійсно узгоджується, з розумними шифрами та валідацією сертифікатів там, де можливо).
2. Контроли проти підробки (SPF, DKIM, DMARC) для запобігання видачі себе за інших та зменшення фішингу.
3. Добра гігієна ідентичностей і кінцевих пристроїв (MFA, управління пристроями, патчинг, EDR).
4. Цільове наскрізне шифрування (S/MIME) для дуже чутливих потоків, де ви можете підтримувати життєвий цикл PKI.

Якщо ви лише робите S/MIME, але тримаєте DMARC у режимі «none», ви закрили щоденник, але залишили відчинені двері.
Зловмисникам не обов’язково читати вашу пошту, якщо вони можуть переконливо відправити «нові реквізити банку» від імені вашого CFO.

Моделі загроз, які мають значення в реальних компаніях

1) Пасивне перехоплення в мережі

Уявіть: скомпрометований Wi‑Fi, ворожий сегмент провайдера або хтось, хто «підслуховує» внутрішній канал
між філією та дата-центром. TLS — ваш базовий захист у цьому випадку.
Без TLS SMTP — це безпека листівки.

S/MIME також допомагає, але це перебір, якщо ваш основний ризик — «не просочитися по дроту»
і ви можете правильно забезпечити TLS.

2) Скомпроментована пошта інфраструктура

Якщо провайдер пошти або шлюз скомпрометовано (або змушено видати доступ), TLS нічого не зробить, оскільки
зловмисник бачить пошту після її завершення на сервері. Шифрування S/MIME може запобігти
розкриттю вмісту якщо приватні ключі зберігаються на кінцевих пристроях і ви не робите розшифровку на шлюзі.

3) Підробка повідомлень і «фрод у ланцюжку відповідей»

Зловмисники обожнюють змінювати PDF-фактури й переписувати платіжні інструкції. Правильно перевірений
S/MIME-підпис дає криптографічну цілісність: повідомлення (та вкладення) не були змінені після підпису.
TLS не дає вам наскрізної цілісності при пересиланні, зберіганні та повторній доставці.

4) Підробка й видавання себе за когось

Користувачі бачать «Ім’я CEO» в полі From і панічно клікають.
TLS цього не зупинить. S/MIME-підписи можуть допомогти для внутрішньої комунікації
(користувачі можуть навчитися довіряти індикатору «підписано»), але в операційному плані
DMARC — ваш практичний контроль для загального інтернету.

5) Відповідність і юридична захищеність

Багато організацій хочуть «шифрування» для галочки. Добре. Але будьте чесні щодо того, що ви перевіряєте.
Якщо вимога — «шифрувати під час передачі», TLS достатній. Якщо вимога — «тільки призначені отримувачі можуть читати»,
потрібне шифрування на рівні повідомлення (S/MIME або еквівалент) плюс сильне оброблення ключів.

Сценарій відмови — це написання політик, які ви не можете довести. Аудиторам не важливі ваші емоції;
їм потрібні докази.

Факти й історичний контекст, які варто знати (щоб не повторювати помилки 1999 року)

1. SMTP було спроектовано без шифрування та автентифікації. Тоді він припускав дружню мережу співпрацюючих хостів. Тепер це виглядає наївно.
2. STARTTLS додали пізніше як механізм оновлення. За замовчуванням він є оппортуністичним: якщо інша сторона не пропонує його, сесія продовжується у відкритому вигляді, якщо ви не застосуєте політику.
3. Ранні атаки зі зниження рівня безпеки експлуатували можливості «strip» для STARTTLS. Якщо атакувач може змінювати трафік, він іноді може прибрати оголошення про STARTTLS і змусити передачу у відкритому вигляді, якщо відправник не наполягає на TLS.
4. S/MIME походить із сімейства Secure MIME і культури корпоративного PKI. Він добре узгоджується з корпоративними центрами сертифікації, смарткартами та керованими ідентичностями — за умови, що все добре налагоджено.
5. PGP і S/MIME вирішували схожі проблеми, але утворили різні екосистеми. PGP зосередився на децентралізованій «мережі довіри»; S/MIME — на ієрархічних CA і корпоративній видачі.
6. DMARC з’явився відносно недавно порівняно зі SMTP. Його широко впровадили після років проблем із фішингом; він залежить від SPF і DKIM та концепції вирівнювання, що плутає всіх принаймні раз.
7. Депрекація SHA‑1 була каталізатором змін. Старі S/MIME і TLS-розгортання ламалися, коли слабкі хеші й підписи перестали приймати сучасні клієнти.
8. Термін дії сертифікатів — не теоретичний ризик. Прострочені сертифікати не лише ламають TLS; вони руйнують індикатори довіри S/MIME і можуть створити «непідписану» поведінку, яку користувачі ігноруватимуть.
9. Провайдери дедалі частіше роблять TLS за замовчуванням, але не завжди з політичними гарантіями. Ви можете мати «переважно TLS» і все ж таки витікати для певного трафіку партнерів, якщо не застосовувати примусових політик.

TLS в SMTP: STARTTLS, MTA-STS, DANE і складні моменти

STARTTLS: оппортуністичний, поки ви не зробите його обов’язковим

SMTP зі STARTTLS — поширене розгортання: підключаєтеся на порт 25, вітаєтеся, дивитеся, чи сервер оголошує STARTTLS,
потім узгоджуєте TLS і продовжуєте. У моделі «оппортуністичний» за замовчуванням:

• Якщо TLS доступний і хендшейк вдається, ви отримуєте шифрування.
• Якщо TLS недоступний, ви все одно доставляєте — у відкритому вигляді — тому що доставка пошти пріоритетніша за приватність.

Це не «безпечна пошта». Це «найкраща спроба». Іноді це добре; іноді це порушує політику.
Якщо ваш ризик-модель каже, що відкритий текст неприйнятний, потрібні механізми примусу.

MTA-STS: політика «вимагати TLS для цього домену»

MTA-STS дозволяє домену опублікувати політику, яка приблизно каже: «при відправленні до нас вимагати TLS і перевіряти наш сертифікат MX».
Це зменшує атаки зі зниження рівня і робить відмови явними (пошта може відхилятися замість зниження рівня).
Це не досконало — отримання політики й довіра до неї — окрема тема — але це практичний важіль.

DANE: TLS з достовірністю через DNSSEC

DANE прив’язує очікуваний TLS-сертифікат/ключ до DNS (захищеного DNSSEC). Це елегантно, але впровадження різниться.
Якщо ви можете надійно запускати DNSSEC і підтримувати його, DANE може дати сильніші гарантії автентичності, ніж
публічна CA-екосистема для SMTP.

Що TLS дає вам реально

TLS для SMTP передусім захищає від пасивного прослуховування і тривіального перехоплення.
Він також зменшує прості модифікації вмісту в дорозі, але не дає довготривалої, наскрізної цілісності,
бо повідомлення може бути змінено на серверах і переслано знову.

Перевага величезна для базової гігієни. Але не перебільшуйте її як «тільки отримувач може читати».

Операційні проблеми, з якими ви зіткнетеся

• Старі партнери, які некоректно підтримують TLS або мають зламані сертифікати.
• Мідлбокси, які заважають узгодженню TLS або нав’язують дивні пріоритети шифрів.
• Помилкова впевненість від «ми налаштували TLS одного разу» без перевірки реальних узгоджених сесій і відкатів.
• Невідповідні політики: відділ безпеки вимагає «вимагати TLS», а продажі хочуть «ніколи не відхиляти листи». Виберіть одне. Або сегментуйте за партнерами й типами повідомлень.

S/MIME на практиці: підписи, шифрування та реальність PKI

Почніть з підписування, а не з шифрування

Якщо ви спробуєте впровадити S/MIME-шифрування всюди одразу, ви виявите проблеми з розповсюдженням сертифікатів,
виявленням отримувачів і відновленням ключів о 2:00 ночі під час ескалації з VIP.
Почніть з підписів:

• Користувачі отримують сертифікат; клієнти підписують вихідні повідомлення.
• Отримувачі можуть перевірити цілісність і ідентичність (якщо довіряють ланцюгу видачі).
• Ви нарощуєте операційну вправність: запис, поновлення, відкликання, конфігурування клієнтів і усунення несправностей.

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

Чому шифрування складніше за підписування

Щоб зашифрувати комусь, потрібен його публічний ключ. Це означає:

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

Також: потрібна історія відновлення ключів. Люди втрачають ноутбуки. Люди йдуть з компанії.
Якщо ваша політика відповідності вимагає розшифровувати старі листи, треба проєктувати ескроу/архівацію ключів.
Це вже не «чисте наскрізне шифрування», але може бути необхідно.

Взаємодія зі шлюзами: де S/MIME починає поводитися дивно

Багато підприємств використовують шлюзи безпеки пошти для DLP, сканування на зловмисне ПЗ, додавання підписів і журнелювання.
S/MIME руйнує модель «змінити повідомлення»: зашифрований вміст не можна сканувати без розшифровки, а підписані повідомлення
стають недійсними, якщо ви додаєте банери або змінюєте хедери/тіло.

Ви повинні вибрати:

• Справжнє кінцеве S/MIME: шлюзи не модифікують вміст; сканування відбувається на кінцях або до шифрування. Сильна приватність, операційні зміни.
• Шлюзове розшифрування/перешифрування: шлюз має ключі. Операційно простіше для сканування та архівування, але довіра централізована (і зона ураження зростає).
• Лише підпис + транспорт TLS: прагматично для багатьох організацій; знижує плутанину, схожу на підробку всередині, і покращує цілісність без повного життєвого циклу шифрування.

Індикатори довіри: користувачі їх неправильно тлумачать

Користувачі бачать іконки. Вони роблять висновки. «Замочок» може означати TLS до сервера, S/MIME-шифрування або щось інше.
Ваше завдання — зробити індикатор послідовним і навчити, що він означає:

• Підписано: «Я можу перевірити, хто підписав, і що повідомлення не змінювалося.»
• Зашифровано: «Лише власники приватних ключів можуть це прочитати.»
• TLS: «Повідомлення не відправлялося у відкритому вигляді по мережі (переважно).»

Підробка не вирішується шифруванням: SPF, DKIM, DMARC

Будьмо відвертими: найпоширеніший інцидент з електронною поштою в корпоративному середовищі — це не підслуховування SMTP.
Це коли хтось відправляє переконливе повідомлення, яке виглядає ніби від вашого домену (або керівників),
і людина виконує те, що вказано в повідомленні.

SPF: хто має право відправляти від імені домену (якось)

SPF перевіряє, чи IP-адреса відправника авторизована в DNS. Він відповідає здебільшого на питання: «Чи цей сервер має право відправляти пошту,
прикидаючись, що вона з цього домену?» Це не криптографічний підпис повідомлення.
Він також легко ламається при пересиланні, якщо не застосовувати пом’якшення.

DKIM: повідомлення підписане доменом

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

DMARC: політика і вирівнювання

DMARC каже приймачу, що робити, коли SPF/DKIM перевірки не проходять, і вимагає «вирівнювання» між видимим From
і автентифікованими ідентифікаторами. DMARC з політикою «reject» — відчутний контроль проти підробки.
DMARC у режимі «none» — це про звітування, а не про захист.

Якщо ви хочете зупинити масове видавання себе за інших — доберіться до DMARC з примусовою політикою.
Якщо вам потрібна приватність для окремих потоків — додавайте S/MIME-шифрування. Якщо потрібна базова гігієна — налаштуйте TLS правильно.
Це різні інструменти.

Три корпоративні міні-історії з передової

Міні-історія №1: інцидент через хибне припущення (TLS ≠ «шифрована пошта»)

Середня сервісна компанія мала політику «вся пошта зашифрована». ІТ вірили в це.
У них був увімкнений STARTTLS на вихідному MTA, і дашборди показували високий рівень TLS.
Безпека погодилася. Юристи раділи. Ніхто не питав: «а що, якщо інша сторона не підтримує TLS?»

Новий партнер у регульованій галузі почав отримувати повідомлення у відкритому вигляді, тому що їхній вхідний
сервіс не пропонував STARTTLS на одному з кількох MX-хостів під час міграції. MTA відправника вчинив як робить SMTP:
доставив лист. Вміст включав персональні дані і контракти, які «мали бути зашифровані».

Відкриття не було драматичним. Адмін пошти партнера написав спокійно: «Ми бачимо незашифровані SMTP-з’єднання з ваших IP.
Це очікувано?» Раптом усі по-новому прочитали політику.

Виправлення не було «впровадити S/MIME завтра». Вони сегментували: застосували примус TLS для цього домену через політику MTA,
налаштували моніторинг відкритого тексту і оновили формулювання політики, щоб відокремити «шифрування транспорту» від «шифрування повідомлення».
Юристи не люблять неоднозначностей. Зловмисники їх обожнюють.

Міні-історія №2: оптимізація, що зламала систему (футери шлюзу vs DKIM і S/MIME)

Інша організація хотіла єдине брендування й юридичні відмови. Їхній шлюз додав футер
до всіх вихідних повідомлень. Запит на зміну виглядав нешкідливо: «лише додати кілька рядків».

За кілька днів показники проходження DMARC впали для певних потоків. Партнери поскаржилися на попередження, схожі на підробку.
Шлюз змінював тіло після DKIM-підпису для деяких потоків, зламуючи підписи. У отримувачів із жорсткішою політикою DMARC листи відхилялися.

Потім внутрішні перевірки S/MIME теж почали відмовляти. Підписані повідомлення змінювалися шлюзом,
роблячи підпис недійсним. Користувачі бачили «підпис недійсний» і засвоїли найгірший урок: ігнорувати попередження.

Відкат був клопітким, бо футер тепер вважався «обов’язковим». Зрештою вони почали модифікувати лише непідписану пошту,
перенесли крок підписування після вставлення футера для певних систем і виділили потоки, де вміст не можна змінювати.
Оптимізація: централізовані футери. Результат: зруйновані сигнали довіри. Класика.

Міні-історія №3: нудна, але правильна практика, що врятувала становище (дисципліна життєвого циклу сертифікатів)

Глобальний виробник використовував S/MIME-підписування для керівництва і фінансових команд. Нічого пафосного. Нудна частина була в тому, що
вони ставилися до сертифікатів як до продакшн-залежностей: інвентар, автоматизація поновлення, поетапні розгортання і сповіщення
задовго до закінчення терміну дії. Ніяких героїчних рішень. Просто строки виконані заздалегідь.

Під час суперечки з постачальником їм потрібно було довести, що ланцюжок повідомлень не змінювався після відправлення.
Постачальник стверджував, що «умови платежу були змінені пізніше». Компанія змогла надати підписані повідомлення,
підписи на яких і надалі проходили валідацію, бо вони зберегли ланцюги підписування і записи про стан видавця CA.

Юристам не довелося сперечатися про скріншоти чи експорт поштових скриньок. Вони мали криптографічні докази цілісності.
Це не «магічна безпека». Це результат виконання невеселих PKI-завдань вчасно.

Це та перемога в безпеці, яка ніколи не потрапляє в пресрелізи. Вона просто рятує від мовчазних втрат грошей.

Практичні завдання: команди, виводи та рішення

Це не лабораторні команди. Це «я на чергуванні і мені треба знати, що насправді відбувається» команди.
Кожне завдання містить: команду, що означає вивід, і рішення, яке ви приймаєте на основі цього.

Завдання 1: Перевірити, чи SMTP-сервер пропонує STARTTLS і подивитися сертифікат

cr0x@server:~$ openssl s_client -starttls smtp -connect mx.partner.example:25 -servername mx.partner.example -showcerts
CONNECTED(00000003)
depth=2 C=US, O=Example Root CA, CN=Example Root CA 1
verify return:1
depth=1 C=US, O=Example Issuing CA, CN=Example Issuing CA 10
verify return:1
depth=0 CN=mx.partner.example
verify return:1
---
250-STARTTLS
---
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS_AES_256_GCM_SHA384
    Verify return code: 0 (ok)

Значення: Сервер оголошує STARTTLS, узгоджує TLS 1.3, і сертифікат валідний (verify return code 0).
Рішення: Ви можете безпечно вимагати TLS для цього партнера, якщо політика це вимагає; сертифікат і переговори виглядають здоровими.

Завдання 2: Виявити оппортуністичний TLS, що відкотився до відкритого тексту (без STARTTLS)

cr0x@server:~$ (echo "EHLO probe.example"; sleep 1; echo "QUIT") | nc -w 3 mx.legacy.example 25
220 mx.legacy.example ESMTP
250-mx.legacy.example
250-SIZE 20480000
250-PIPELINING
250 HELP

Значення: Немає рядка 250-STARTTLS. Цей хост не погодиться на TLS.
Рішення: Якщо це домен, з яким ви обробляєте чутливі дані, додайте політику «вимагати TLS» і приймайте відмови, або використайте альтернативний захищений канал.

Завдання 3: Підтвердити, що ваш Postfix дійсно використовує TLS для вихідної доставки

cr0x@server:~$ sudo postconf -n | egrep 'smtp_tls_security_level|smtp_tls_loglevel|smtp_tls_policy_maps'
smtp_tls_security_level = may
smtp_tls_loglevel = 1
smtp_tls_policy_maps = hash:/etc/postfix/tls_policy

Значення: TLS опортуністичний (may), рівень логування низький, і є мапа політик.
Рішення: Тримайте may глобально, але вимагайте encrypt для конкретних партнерів/доменів у tls_policy. Тимчасово підніміть рівень логів під час налагодження.

Завдання 4: Примусити TLS для одного домену-партнера в Postfix і перевірити мапу

cr0x@server:~$ sudo bash -lc 'printf "partner.example encrypt\n" >> /etc/postfix/tls_policy && postmap /etc/postfix/tls_policy && postmap -q partner.example /etc/postfix/tls_policy'
encrypt

Значення: Postfix вимагатиме TLS для partner.example.
Рішення: Це прагматичне виправлення, коли політика каже «ніколи в відкритому вигляді до цього партнера». Очікуйте відмов, якщо їхній TLS зламається; це і є сенс.

Завдання 5: Перевірити логи вихідної доставки на предмет узгодження TLS vs відкритий текст (Postfix)

cr0x@server:~$ sudo grep -E 'status=sent|TLS connection established|no starttls' /var/log/mail.log | tail -n 6
Jan 04 10:11:33 mail postfix/smtp[12091]: TLS connection established to mx.partner.example[203.0.113.10]:25: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384
Jan 04 10:11:34 mail postfix/smtp[12091]: 4F2C220A1F: to=<ap@partner.example>, relay=mx.partner.example[203.0.113.10]:25, delay=1.2, delays=0.1/0/0.6/0.5, dsn=2.0.0, status=sent (250 2.0.0 Ok)
Jan 04 10:12:02 mail postfix/smtp[12110]: warning: TLS is required, but was not offered by host mx.legacy.example[198.51.100.20]
Jan 04 10:12:02 mail postfix/smtp[12110]: 9A8D420A45: to=<acct@legacy.example>, relay=none, delay=0.5, dsn=4.7.4, status=deferred (TLS is required, but was not offered by host mx.legacy.example[198.51.100.20])

Значення: Перше повідомлення відправлено через TLS. Друге відкладено, бо TLS був потрібен, але недоступний.
Рішення: Для чутливих доменів це правильна поведінка. Зв’яжіться з партнером або організуйте альтернативну доставку; не «тимчасово дозволяйте відкритий текст» і не забувайте про це.

Завдання 6: Перевірити узгоджений протокол/шифр TLS з MTA, що підтримує submission (587)

cr0x@server:~$ openssl s_client -starttls smtp -connect smtp.example.com:587 -servername smtp.example.com 2>/dev/null | egrep 'Protocol|Cipher|Verify return code'
    Protocol  : TLSv1.2
    Cipher    : ECDHE-RSA-AES256-GCM-SHA384
    Verify return code: 0 (ok)

Значення: TLS працює, але узгоджено TLS 1.2 (не обов’язково погано). Сертифікат валідний.
Рішення: Якщо ваш мінімум — TLS 1.2+, все добре. Якщо вам потрібен TLS 1.3, налаштуйте сервер і перевірте сумісність клієнтів.

Завдання 7: Помітити невідповідність сертифіката (поширено при балансировщиках і старих MX)

cr0x@server:~$ openssl s_client -starttls smtp -connect mx.weird.example:25 -servername mx.weird.example 2>/dev/null | openssl x509 -noout -subject -issuer
subject=CN=mail.othername.example
issuer=CN=Example Issuing CA 10,O=Example Issuing CA,C=US

Значення: CN сертифіката не співпадає з іменем сервера, до якого ви підключилися.
Рішення: Опортуністичний TLS все ще може шифрувати, але автентифікований TLS (MTA-STS чи сувора валідація) може зламатися. Виправте сертифікат/SAN або налаштуйте DNS/MX-цілі.

Завдання 8: Перевірити локальний S/MIME сертифікат на прострочку і призначення ключа

cr0x@server:~$ openssl x509 -in alice-smime.crt -noout -subject -issuer -dates -text | egrep 'Subject:|Issuer:|Not Before|Not After|Key Usage|Extended Key Usage' -A1
Subject: CN=Alice Example, emailAddress=alice@example.com
Issuer: CN=Corp Issuing CA 3
Not Before: Jan  1 00:00:00 2025 GMT
Not After : Jan  1 00:00:00 2026 GMT
Key Usage: Digital Signature, Key Encipherment
Extended Key Usage: E-mail Protection

Значення: Сертифікат дійсний для захисту пошти і спливе 1 січня 2026 року.
Рішення: Налаштуйте сповіщення про поновлення задовго до закінчення; якщо EKU не містить «E-mail Protection», не витрачайте час на налагодження Outlook — перевипустіть сертифікат правильно.

Завдання 9: Перевірити S/MIME-підпис у збереженому листі

cr0x@server:~$ openssl smime -verify -in signed.eml -CAfile corp-root-ca.pem -out /tmp/verified.txt
Verification successful

Значення: Підпис цілий і ланцюжок веде до наданого CA-бандла.
Рішення: Якщо користувач скаржиться, що «підпис недійсний», відтворіть це. Якщо верифікація падає — перевірте модифікації шлюзом або відсутні проміжні CA.

Завдання 10: Розшифрувати S/MIME-повідомлення, щоб підтвердити, що воно справді зашифроване наскрізно

cr0x@server:~$ openssl smime -decrypt -in encrypted.eml -recip bob-smime.crt -inkey bob-smime.key -out /tmp/decrypted.txt

Значення: Якщо команда вдається і дає plain text, повідомлення справді було S/MIME-шифроване для Боба.
Рішення: Якщо розшифрування не вдається, ймовірно у вас неправильний приватний ключ, застарілий сертифікат або повідомлення ніколи не було S/MIME-шифрованим (лише TLS у дорозі).

Завдання 11: Перевірити, чи домен публікує DMARC і яка політика

cr0x@server:~$ dig +short TXT _dmarc.example.com
"v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; adkim=s; aspf=s"

Значення: Політика DMARC — reject зі суворим вирівнюванням DKIM і SPF.
Рішення: Цей домен серйозно ставиться до анти-підробки. Якщо це ваш домен — добре. Якщо ні — очікуйте, що їхні отримувачі відхилятимуть невирівняні повідомлення; підлаштуйте свої системи.

Завдання 12: Перевірити запис DKIM для селектора (поширена проблема після ротації)

cr0x@server:~$ dig +short TXT s1._domainkey.example.com
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAt3..."

Значення: Публічний ключ DKIM опублікований для селектора s1.
Рішення: Якщо DMARC-звіти показують провали DKIM після розгортання, перевірте, чи селектор у заголовках листа співпадає з опублікованим записом і чи ключ не обрізано через помилку в DNS.

Завдання 13: Підтвердити SPF-запис і виявити небезпечні «+all» або відсутні include

cr0x@server:~$ dig +short TXT example.com | grep -i 'v=spf1'
"v=spf1 ip4:203.0.113.0/24 include:_spf.mailvendor.example -all"

Значення: SPF авторизує один діапазон IP і включення постачальника, і використовує -all для жорсткого відхилення всього іншого.
Рішення: Це бажана форма. Якщо бачите ~all, ви в «soft fail» режимі; часто це прийнятно під час міграції, але не є кінцевим станом.

Завдання 14: Переглянути файл листа на предмет Received-хедерів і Authentication-Results

cr0x@server:~$ sed -n '1,80p' suspicious.eml | egrep -i '^(From:|To:|Subject:|Received:|Authentication-Results:|DKIM-Signature:)'
From: "Finance Ops" <finance@example.com>
To: ap@partner.example
Subject: Updated remittance details
Received: from unknown (HELO smtp.attacker.example) (198.51.100.99) by mx.partner.example with ESMTP; Fri, 03 Jan 2026 21:02:11 +0000
Authentication-Results: mx.partner.example; dmarc=fail (p=reject) header.from=example.com; spf=fail smtp.mailfrom=example.com; dkim=none

Значення: DMARC і SPF провалилися; DKIM відсутній. Це класичний випадок підробки.
Рішення: Розглядайте як інцидент імперсонації, а не як «проблему TLS». Виправлення — примусове DMARC для вашого домену і навчання користувачів, а не «зашифруйте ще більше».

Завдання 15: Перевірити, чи ваш сервіс рекламує правильні TLSA-записи (DANE) (якщо ви використовуєте DNSSEC)

cr0x@server:~$ dig +short TLSA _25._tcp.mx.example.com
3 1 1 9F4A0A4E3E3B2A6F5E0D0F19C0A9E3C7B7D3A1F9E8B8C2E6A0D0C1B2A3F4E5D6

Значення: TLSA-запис існує для MX-хоста. Чи довіряють йому відправники — залежить від валідації DNSSEC.
Рішення: Якщо ви покладаєтесь на DANE, моніторьте статус DNSSEC і свіжість записів; зламана ланка тут — мовчазна регресія безпеки.

Завдання 16: Підтвердити, що ланцюжок сертифікатів, який подає MTA, містить проміжні

cr0x@server:~$ openssl s_client -starttls smtp -connect mx.example.com:25 -servername mx.example.com -showcerts 2>/dev/null | awk '/BEGIN CERTIFICATE/{i++} {print > ("/tmp/cert" i ".pem")}'

cr0x@server:~$ for f in /tmp/cert*.pem; do echo "== $f =="; openssl x509 -noout -subject -issuer -in "$f"; done
== /tmp/cert1.pem ==
subject=CN=mx.example.com
issuer=CN=Corp Issuing CA 3
== /tmp/cert2.pem ==
subject=CN=Corp Issuing CA 3
issuer=CN=Corp Root CA

Значення: Сервер подає листок + проміжний. Добре.
Рішення: Якщо проміжні відсутні, деякі пірингові партнери за суворих TLS-політик не зможуть валідовати. Виправте конфігурацію ланцюжка до того, як вимагати MTA-STS.

Короткий жарт №2: Ротація сертифікатів — єдиний спорт, де «зробимо пізніше» надійно перетворюється на «зараз, у вогні».

Одна ідея з надійності, бо вона тут ідеально підходить: перефразована ідея — Werner Vogels:
«Усе ламається; проєктуйте системи й операції, припускаючи це». S/MIME і TLS не є винятком.

Швидкий план діагностики

Коли хтось каже «безпека пошти зламана», зазвичай це означає одне з чотирьох: (1) лист відхилився, (2) лист доставлений, але позначений як підозрілий, (3) підпис недійсний, або (4) шифрування не сталося.
Не починайте з аргументів про терміни. Почніть із ізоляції шару, що вийшов з ладу.

Перше: визначте, що мало означати «захищено»

1. Очікування транспортного захисту: чи TLS мав бути обов’язковим для цього отримувача/домену?
2. Очікування захисту повідомлення: чи S/MIME підпис і/або шифрування були вимогою?
3. Очікування ідентичності: чи мета була запобігти підробці (DMARC), а не конфіденційність?

Друге: знайдіть, де сталася помилка (клієнт, шлюз, MTA, отримувач)

1. Клієнтський шар: Outlook/Apple Mail показує «не підписано», просить сертифікат або не може розшифрувати.
2. Шлюз: повідомлення змінено, додано футер, DLP перезаписує вміст.
3. MTA: STARTTLS не узгодився, невідповідність сертифіката, політика відмовляє у відкритому тексті.
4. Отримувач: їхній DMARC відкидає, їхній TLS некоректний, їхній S/MIME trust store не містить вашого CA.

Третє: підтвердіть факти доказами

1. Перевірте логи MTA на предмет узгодження TLS і помилок політики (TLS connection established, TLS is required).
2. Пробийте MX отримувача за допомогою openssl s_client -starttls smtp, щоб підтвердити STARTTLS, сертифікат і протокол.
3. Проаналізуйте заголовки повідомлення на Authentication-Results, DKIM, SPF і DMARC.
4. Якщо це S/MIME: використайте openssl smime -verify і переконайтеся, що шлюз його не торкався.

Четверте: вирішіть, закривати чи відкривати відмови

Тут більшість команд ухиляються від рішення і натомість створюють «тимчасові виключення», що стають постійними.
Для чутливих партнерів — закривайте відмову (bounce/defer при відсутності TLS).
Для загального інтернету оппортуністичний TLS прийнятний, але тоді не кажіть «вся пошта зашифрована».

Поширені помилки (симптоми → корінь → виправлення)

1) «Ми використовуємо TLS», але партнер показує відкриті сесії

Симптоми: Партнер повідомляє про відкриті SMTP-сесії; ваша команда наполягає, що TLS увімкнено.

Корінь: STARTTLS опортуністичний; ви не застосували вимогу TLS для цього домену, або один MX-хост не оголошує STARTTLS.

Виправлення: Примусьте TLS за доменом (policy maps), перевірте всі MX-хости і моніторьте відкат до відкритого тексту явно.

2) «S/MIME підписи недійсні» відразу після зміни шлюзу

Симптоми: Користувачі бачать попередження про недійсний підпис; верифікація непостійна; лише деякі маршрути уражені.

Корінь: Шлюз змінює тіло/заголовки після підпису (футери, банери, переписування посилань).

Виправлення: Перестаньте модифікувати підписаний вміст; підписуйте після модифікацій; або виділіть потоки, що обходять переписування.

3) S/MIME-шифрування працює всередині компанії, але ламається для зовнішніх партнерів

Симптоми: Опція «шифрувати» недоступна для зовнішнього отримувача, або пошту не можуть розшифрувати на їхньому боці.

Корінь: Відсутність виявлення публічних ключів, застарілий/прострочений сертифікат отримувача або партнер не довіряє вашій CA-ланці.

Виправлення: Встановіть процес обміну сертифікатами; використовуйте публічно довірені S/MIME сертифікати для крос-організаційних робочих процесів; перевірте EKU і SAN з адресою електронної пошти.

4) DMARC у режимі «reject» і раптом ваша легітимна системна пошта відхиляється

Симптоми: Сповіщення SaaS або CRM відхиляються у отримувачів; у заголовках з’являється провал DMARC.

Корінь: Система надсилає від вашого домену у From без вирівняного DKIM або SPF (поширене з третьосторонніми відправниками).

Виправлення: Налаштуйте DKIM-підписування для цього відправника під вашим доменом, або використайте піддомен з окремою DMARC-політикою; не послаблюйте DMARC для всього домену.

5) «Шифрування пошти» ламає журнальне збирання і eDiscovery

Симптоми: Команда комплаєнсу не може прочитати журналізовані листи; архіви зберігають нечитаємі бінарні дані.

Корінь: Справжнє кінцеве S/MIME-шифрування без проєктування архівації/розшифрування.

Виправлення: Прийміть рішення навмисно: ескроу ключів, журнальне збереження перед шифруванням, або погодьтеся, що деякі повідомлення не читаються централізовано. Задокументуйте і погодьте з юристами.

6) TLS-помилки з’являються лише для деяких отримувачів і лише інколи

Симптоми: Випадкові відхилення/відкладання з причини збоїв TLS-хендшейку.

Корінь: У отримувача декілька MX-хостів з непослідовним TLS або ваш MTA підключається до різних маршрутів; іноді ви потрапляєте на «хороший» хост.

Виправлення: Протестуйте всі MX-цілі; змусьте партнера виправити їхній флот; тимчасово використайте політики за хостом, якщо ваш MTA це підтримує, або прийміть затримки доставки.

7) Користувачі вважають, що «замочок» означає «ніхто не може це прочитати»

Симптоми: Користувачі надсилають чутливі дані в надії на конфіденційність; розслідування показують «але ж це було замочком».

Корінь: Невизначеність у UI: замочок може показувати TLS до сервера або S/MIME; недостатнє навчання та маркування.

Виправлення: Стандартизувати видимий індикатор і словник; опублікувати внутрішній одно-сторінковий гайд зі скріншотами; тамувати «шифрувати» для певних класифікацій через політику, коли можливо.

8) Поновлення сертифікатів викликають раптові S/MIME-збої

Симптоми: Деякі отримувачі не можуть розшифрувати нові зашифровані листи після поновлення; старі листи розшифровуються добре.

Корінь: Відправник шифрує до старого публічного ключа, що закешований у каталозі; каталог не оновлено або існує кілька сертифікатів.

Виправлення: Впровадьте контрольоване перекривання: публікуйте нові сертифікати, зберігайте старі для розшифрування і переконайтеся, що каталог та клієнти оновлюють ключі.

Контрольні списки / покроковий план

Покроково: визначте, що саме ви захищаєте (припиніть складання всього під «шифрування»)

1. Перерахуйте категорії повідомлень: публічні, внутрішні, конфіденційні, регульовані.
2. Для кожної категорії вирішіть: вимагати TLS? вимагати S/MIME-підпис? вимагати S/MIME-шифрування?
3. Визначте поведінку при відмові: bounce/defer чи дозволити відкритий текст. Оформіть це як політику, а не як усні знання.
4. Вирішіть, де дозволена розшифровка (лише на кінцях чи на шлюзі). Узгодьте з юридичним відділом і комплаєнсом.

Покроково: зробіть TLS реальним (не абстрактним)

1. Інвентаризуйте вихідні MTA і реле (включаючи SaaS-відправників, що використовують ваш домен).
2. Увімкніть і перевірте STARTTLS; виправте ланцюжки сертифікатів і імена.
3. Увімкніть логування на рівні, що показує результати узгодження TLS під час розгортання.
4. Впровадьте примус TLS за доменом для чутливих партнерів.
5. Розгляньте MTA-STS для вашого домену, щоб інші могли вимагати TLS при відправленні до вас.
6. Додайте моніторинг, що сповіщає про відкриті доставки до доменів, які мають бути зашифровані.

Покроково: розгорніть S/MIME, не знищивши службу підтримки

1. Почніть з підписування для пілотної групи (керівники/фінанси/юристи). Спочатку зробіть валідацію надійною.
2. Виберіть модель видачі: внутрішній CA для внутрішнього використання, публічно довірений для зовнішніх партнерських робочих процесів.
3. Впровадьте автоматизацію запису та поновлення сертифікатів там, де можливо.
4. Визначте обробку ключів: прив’язка до пристрою, смарткарти або програмні сховища; опишіть резервне копіювання та відновлення.
5. Вирішіть, як працювати зі шлюзами, що змінюють вміст; виділіть підписані/зашифровані потоки.
6. Розширюйте шифрування для обґрунтованих робочих процесів; не примушуйте всіх «бо комплаєнс».

Покроково: виправте підробку (бо це все ще джерело найбільшого болю)

1. Опублікуйте точний SPF; включіть усіх легітимних відправників; уникайте надто широких механізмів.
2. Увімкніть DKIM-підписування для основних потоків (корпоративний MTA, хмарні набори, сторонні відправники).
3. Увімкніть DMARC-звітування, щоб бачити, хто відправляє від вашого імені.
4. Переведіть DMARC з none → quarantine → reject поетапно з планом підготовки.
5. Опрацюйте крайові випадки: пересилання, розсилки й системи, що не можуть підписувати DKIM; використовуйте піддомени.

Операційний чекліст: що моніторити постійно

• Коефіцієнт успішного TLS за доменом призначення; алерт на відкритий текст для доменів з «TLS-required».
• Зростання черги MTA через відкладення політики TLS (поломка партнера).
• Вікна прострочення сертифікатів S/MIME (30/14/7 днів) для критичних користувачів.
• Агрегати DMARC: показники проходження та топ несанкціонованих джерел.
• Зміни в шлюзі, які можуть модифікувати вміст (і тим самим ламати DKIM/S/MIME).

FAQ

1) Якщо в нас TLS скрізь, чи потрібен ще S/MIME?

Залежить від моделі загроз. TLS захищає під час передачі; провайдери та шлюзи все ще читають повідомлення.
Використовуйте S/MIME-шифрування, коли потрібна конфіденційність повідомлень через межі інфраструктури пошти, або коли потрібна довготривала цілісність через підписи.

2) Чи зупиняє S/MIME фішинг?

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

3) Чи безпечний STARTTLS?

Опортуністичний STARTTLS кращий за нічого і широко використовується. Це не гарантія: доставка може відкотитися до відкритого тексту.
Якщо потрібні гарантії, застосовуйте примус TLS за доменом (і розгляньте MTA-STS чи DANE там, де доречно).

4) Чому підписані листи інколи показують «недійсний підпис», хоча нічого зловмисного не сталося?

Тому що щось змінило повідомлення після підпису: шлюз додав футер, банер, переписав посилання або навіть деяке поштове ПЗ змінило вміст.
Виправлення — перестати модифікувати підписаний вміст або перемістити підписування після модифікацій.

5) У чому різниця між S/MIME-підписом і DKIM?

Підпис S/MIME — це підпис на рівні користувача/повідомлення і пов’язаний з індивідуальною сертифікаційною ідентичністю (або хоча б з індивідуальним ключем).
DKIM — це підпис на рівні домену і прив’язує повідомлення до ключа домену-відправника. DKIM чудовий для інфраструктури проти підробки; S/MIME — для цілісності на рівні кінцевого отримувача та доказів непроспростування (в межах обмежень).

6) Чи розшифровувати S/MIME на шлюзі для DLP і сканування шкідливого ПЗ?

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

7) Чи можна вимагати TLS для всієї вихідної інтернет-пошти?

Можна, але будьте готові до відхилень у старих доменів і непідготованих партнерів. Більшість організацій обирають «оппортуністичний для загального інтернету, примусовий для чутливих партнерів».
Головне — чесність у політиці й моніторинг, щоб відкритий текст не став сюрпризом.

8) Що ламає S/MIME-шифрування під час ротації сертифікатів?

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

9) Чи є S/MIME «наскрізним шифруванням», як у сучасних чат-додатках?

Може бути ближчим ніж TLS, але пошта все ще має пересилання, архіви, шлюзи та вимоги до відновлення ключів. Багато підприємств навмисно вводять центральний доступ для комплаєнсу. Називайте це «шифрування на рівні повідомлення» і конкретизуйте межі довіри.

10) Яка мінімальна життєздатна позиція безпеки пошти для типової компанії?

TLS увімкнено і перевірено на вхід/вихід, DMARC з планом досягнення примусового режиму, DKIM на всіх легітимних відправниках,
і S/MIME-підписування для ролей з високим ризиком. Додавайте S/MIME-шифрування вибірково там, де це обґрунтовано й підтримується.

Висновок: що робити наступного тижня

Якщо у вашій організації сварка «TLS проти S/MIME» триває — ви вже втрачаєте час. Це не взаємозамінні речі; вони покривають різні сценарії відмов.
TLS — це базова гігієна транспорту. S/MIME — захист повідомлення з витратами PKI. DMARC — ваш робочий кінь проти підробки.

Практичні кроки на тиждень, які не впадуть від амбіцій:

1. Перепишіть внутрішню політику: припиніть говорити «пошта зашифрована» і вказуйте «TLS у дорозі» або «S/MIME шифрування повідомлення».
2. Виміряйте реальність: запустіть перевірки STARTTLS для ключових партнерів і перевірте логи MTA на відкат до відкритого тексту.
3. Примусьте TLS лише там, де це має значення (партнери, регульовані потоки) і приймайте відмови як функцію безпеки.
4. Розпочніть рух DMARC у бік примусового режиму; не залишайте його в «none» і не прикидайтеся, що це захист.
5. Запустіть пілот S/MIME-підписування для невеликої групи, потім масштабування. Ставтеся до життєвого циклу сертифікатів як до продакшн-завдання.

Пошта ніколи не буде «вирішена» так, як деякі вендори обіцяють. Але ви можете зробити її передбачуваною, перевірюваною і значно безпечнішою.
Ось як виглядає продакшн-безпека: менше міфів, більше логів.