Explore

Частина 1. TLS: твій перший і останній рубіж безпеки

🔰 Вступ

❓ Про що взагалі мова?

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

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

Тому перший базовий рівень захисту – це транспортне шифрування, тобто гарантія того, що:

ніхто не зможе підслухати наші дані (конфіденційність),

дані дійдуть до адресата без змін (цілісність),

ми точно знаємо, з ким встановлюємо з'єднання (автентичність).

Цю функцію виконує протокол TLS (Transport Layer Security).

📝 Що розглянем?

Сьогодні ми розглянемо:

Що таке TLS, де він застосовується і як працює під капотом

Як виглядає процес встановлення захищеного з’єднання

Які бувають помилки та вразливості у конфігурації

Як налаштувати HTTPS у .NET веб-сервісі

📍 Огляд

📋 Що таке TLS?

TLS (Transport Layer Security) – це криптографічний протокол, який забезпечує захищену передачу даних між клієнтом і сервером по мережі. Він працює на транспортному рівні (між TCP і HTTP) і відповідає за те, щоб:

Дані були зашифровані – щоб ніхто не міг їх підслухати

Дані не були змінені по дорозі – перевірка цілісності

Клієнт міг упевнено ідентифікувати сервер – завдяки цифровому сертифікату

Сервер міг ідентифікувати клієнта – у випадку mutual TLS (mTLS)

TLS - це не просто шифрування даних. Це складний протокол, який включає:

обмін ключами

автентифікацію через сертифікати

встановлення сесійного шифрування

захист від атак типу downgrade, replay, MitM

🏛️ Трохи історії

TLS не з’явився з нізвідки – це результат тривалого розвитку. Усе почалося з SSL (Secure Sockets Layer), перших спроб Netscape захистити передавання даних в інтернеті.

SSL 2.0 (1995) був першим публічним релізом, але мав серйозні проблеми: слабке шифрування, відсутність перевірки цілісності, частина даних передавалась відкрито. У SSL 3.0 (1996) ситуація покращилась, з’явився повноцінний handshake і підтримка сертифікатів, але згодом знайшли серйозну уразливість, що була використана в POODLE-атаках.

З 1999 року розвиток перейшов під крило IETF (Internet Engineering Task Force), і замість SSL з’явився TLS 1.0 – з новими алгоритмами, але ще сумісний з попередніми версіями. TLS 1.1 (2006) лише частково виправив недоліки, тому їх обидві вважають застарілими.

Справжнім проривом став TLS 1.2 (2008): підтримка сучасного шифрування (AES-GCM, SHA-2), розширення гнучкості та кращий захист від атак. Ця версія і досі найпоширеніша в продакшн-системах.

Нарешті, TLS 1.3 (2018) – це сучасний мінімалістичний і безпечний протокол: скорочений handshake, обов’язкова forward secrecy, вилучення всіх слабких алгоритмів. Він рекомендований для нових проєктів і широко підтримується в браузерах, мобільних застосунках і API.

Якщо ваша система ще підтримує TLS 1.0 або 1.1 - це критична вразливість. Підтримка цих версій заборонена сучасними стандартами безпеки.

Версія

Рік

Основні зміни

Проблеми / Недоліки

Поточний статус

SSL 1.0

1994

Внутрішній прототип

Критичні помилки в дизайні

❌ Ніколи не випущено

SSL 2.0

1995

Перше публічне шифрування для HTTP

Відсутність цілісності, слабке шифрування

❌ Заборонено (з 2011)

SSL 3.0

1996

Підтримка сертифікатів, handshake

Уразливість до POODLE, атаки на downgrade

❌ Заборонено (з 2015)

TLS 1.0

1999

Стандартизація, HMAC, backward compatibility

CBC-атаки, застарілі алгоритми (SHA-1, RC4)

❌ Заборонено (з 2020)

TLS 1.1

2006

Рандомізація IV, мікропокращення

Застарілі криптографічні підходи

❌ Заборонено (з 2020)

TLS 1.2

2008

AEAD (GCM), SHA-2, нові cipher suites

Потрібна правильна конфігурація для безпеки

✅ Використовується

TLS 1.3

2018

1-раунд handshake, тільки сучасні алгоритми

Немає підтримки старих систем, обмеження для DPI

🟢 Рекомендовано

There are no rows in this table

⁠

🔨 Де застосовують TLS?

Сьогодні TLS – це не просто про “щоб був HTTPS”. Це універсальний механізм захисту, який використовується:

У користувацьких додатках – при роботі з вебсайтами, REST API, мобільними чи десктопними застосунками. Фактично, якщо ви бачите https:// у URL – це TLS у дії.

У системах реального часу – таких як gRPC, WebSockets чи SignalR, де TLS захищає стрімінгові дані та двостороннє з’єднання.

У електронному листуванні – SMTPS = SMTP over TLS

У передачі файлів – FTPS = FTP over TLS

У внутрішній інфраструктурі – зокрема, між мікросервісами, API Gateway та сервісами в zero-trust архітектурах, IoT-пристроями. Навіть у приватних мережах вже не можна покладатися на “мережеву довіру”.

При інтеграції з зовнішніми системами – банківські сервіси, платіжні шлюзи, державні API, провайдери ідентичності (OAuth2, OpenID Connect) вимагають TLS як обов’язкову умову безпеки.

У системах з регуляторними вимогами – таких як GDPR, HIPAA, PCI-DSS, де TLS є мінімальним стандартом захисту персональних або фінансових даних.

🔐 Основи криптографії TLS

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

🔑 Симетричне та асиметричне шифрування

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

🔸 Симетричне шифрування

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

Цей тип шифрування дуже швидкий і чудово підходить для обробки великих обсягів інформації. Саме тому TLS використовує симетричне шифрування для передачі всіх даних після встановлення захищеного з'єднання.

Однак основна проблема симетричної криптографії – як безпечно передати сам ключ між клієнтом і сервером, якщо початкове з’єднання ще незахищене? Власне, саме ця проблема і стала причиною для розвитку асиметричних методів.

⁠

🔸 Асиметричне шифрування

Асиметричне шифрування використовує пару ключів: один публічний, інший приватний. Дані, зашифровані публічним ключем, можна розшифрувати лише відповідним приватним ключем, і навпаки.

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

Недолік – повільна робота, особливо при великих обсягах інформації.

⁠

#️⃣ Хеш-функції та ЕЦП

TLS – це не лише про шифрування, але й про цілісність даних і встановлення довіри. Для цього протокол використовує криптографічні хеш-функції та цифрові підписи.

🔸 Що таке хеш-функція?

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

Ключові властивості:

Детермінованість: одне й те саме повідомлення завжди дає один і той самий хеш.

Односторонність: неможливо обчислити оригінальні дані, знаючи лише хеш.

Стійкість до колізій: важко знайти два різні повідомлення з однаковим хешем.

У TLS зазвичай використовуються SHA-2 (SHA-256, SHA-384) або SHA-3. Старіші (MD5, SHA-1) більше не рекомендуються через виявлені колізії.

🔸 Що таке цифровий підпис?

Цифровий підпис – це криптографічний аналог підпису "від руки", який дозволяє перевірити, що дані:

надійшли від певного відправника (автентичність);

не були змінені по дорозі (цілісність).

Принцип роботи:

Відправник обчислює хеш повідомлення.

Потім він шифрує цей хеш своїм приватним ключем.

Отриманий результат – це і є цифровий підпис.

Одержувач, маючи публічний ключ, розшифровує підпис і порівнює з самостійно обчисленим хешем. Якщо значення співпали – повідомлення дійсне і не було змінене.

🎫 Сертифікати відкритого ключа

У TLS цифрові підписи реалізуються за допомогою сертифікатів X.509, які містять:

публічний ключ сервера,

інформацію про власника (наприклад, доменне ім’я),

термін дії сертифіката,

підпис центру сертифікації (CA).

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

Коли клієнт (браузер або застосунок) отримує сертифікат:

Він перевіряє, чи сертифікат дійсний (не прострочений, не відкликаний).

Перевіряє, чи його підписано надійним CA, якому він довіряє.

Якщо все гаразд – довіра до сервера встановлена, і можна використовувати публічний ключ із сертифіката для обміну ключами або перевірки підписів.

🎯 Як працює TLS?

Комунікація за допомогою TLS включає в себе два етапи – встановлення безпечного зʼєднання та подальший безпечний обмін даними. За перше відповідає протокол рукостискання TLS (TLS Handshake Protocol), за інше – протокол запису (Record Protocol).

Оскільки наразі більше 95% інфраструктури працює з TLS 1.2, розглянемо деталі на його основі.

🤝 TLS Handshake Protocol

TLS Handshake Protocol – це окрема фаза в роботі TLS, яка відповідає за:

автентифікацію сторін (здебільшого сервера),

узгодження криптографічних алгоритмів,

обмін параметрами для формування сесійного ключа,

забезпечення цілісності та захисту від атак на етапі встановлення з’єднання.

Handshake відбувається до того, як дані почнуть передаватися в зашифрованому вигляді.

Загальна схема

⁠

Повідомлення

Хто надсилає

Умова надсилання

Вміст

ClientHello

Клієнт

Підтримувані версії TLS

Список cipher suites (набір алгоритмів шифрування, MAC, обміну ключами)

client_random

Розширення – SNI (Server Name Indication), ALPN (Application-Layer Protocol Negotiation, наприклад, http/1.1, h2, gRPC), підтримка стиснення, інш

ServerHello

Сервер

Вибрана версія TLS

Вибраний cipher suite

server_random

Підтвердження розширень

Certificate

Сервер

Сертифікат сервера (X.509), або ланцюжок сертифікатів

ServerKeyExchange

Сервер

Лише для таких cipher suites:

DHE (Diffie-Hellman Ephemeral)

ECDHE (Elliptic Curve DHE)

SRP, PSK, ECDH_anon тощо (рідше)

Не використовується при RSA

При DH:

p - просте число (модуль)

g - генератор (база)

Ys - відкритий ключ сервера (g^a mod p), де a - секретний ключ сервера

При ECDHE:

curve_params - інформація про використану криву (наприклад, secp256r1)

public_key - публічний еліптичний ключ сервера

Цифровий підпис

CertificateRequest

Сервер

Тільки при встановленні mTLS

Запит на сертифікат клієнта

ServerHelloDone

Сервер

Порожнє повідомлення → сигнал про завершення фази сервера

Certificate

Клієнт

Тільки при встановленні mTLS

Якщо був запит - клієнт надсилає свій сертифікат серверу

ClientKeyExchange

Клієнт

При RSA:

pre-master secret — 48 байтів випадкових даних, зашифрованих публічним ключем сервера, отриманим із Certificate (аналогія shared_secret)

pre-master secret потім використовується обома сторонами разом з client_random і server_random, щоб обчислити master_secret

при DHE:

Yc - відкритий ключ клієнта (g^b mod p), де p (модуль) і g (генератор, база) - отримані від сервера, а b - секретний ключ клієнта

Спільний ключ (shared_secret) обчислюється обома сторонами локально:

Сервер: (Yc)^a mod p

Клієнт: (Ys)^b mod p

При ECDHE:

Замість p і g використовується еліптична крива (curve_params)

Параметри (крива, публічний ключ сервера) надсилаються у ServerKeyExchange

Клієнт генерує і надсилає свою точку на еліптичній кривій

Так само, як і при DHE, спільний ключ (shared_secret) обчислюється обома сторонами локально

CertificateVerify

Клієнт

Тільки при встановленні mTLS

Хеш усіх попередніх handshake-повідомлень, підписаний приватним ключем клієнта - підтвердження володіння приватним ключем. Сервер перевіряє підпис публічним ключем клієнта

ChangeCipherSpec

Клієнт

Один байт 0x01 - перехід до шифрування. Надсилається після обчислення master_secret (виводиться з shared_secret і рандомів)

Finished

Клієнт

Перше повідомлення клієнта розміром 12 байт, зашифроване симетричним ключем. Використовує PRF (Pseudo-Random Function на базі HMAC) для генерування verify_data на основі

master_secret

Рядка “client finished”

хешу усіх попередніх handshake-повідомлень

Сервер розшифровує verify_data, генерує свою версію і звіряє з отриманою

ChangeCipherSpec

Сервер

Один байт 0x01 - перехід до шифрування. Надсилається після обчислення master_secret (виводиться з shared_secret і рандомів)

Finished

Сервер

Перше повідомлення сервера розміром 12 байт, зашифроване симетричним ключем. Використовує PRF (Pseudo-Random Function на базі HMAC) для генерування verify_data на основі

master_secret

Рядка “server finished”

хешу усіх попередніх handshake-повідомлень

Клієнт розшифровує verify_data, генерує свою версію і звіряє з отриманою

There are no rows in this table

⁠

Важливі важливості

Описаний протокол рукостискання валідний для TLS 1.2. У TLS 1.3 він дещо спрощений.

Протокол рукостискання не є request-response в розумінні HTTP. Він працює на рівні TCP - ініціюється клієнтом.

pre-master secret у випадку RSA за своїм призначенням ідентичний shared_secret у випадку DHE / ECDHE і слугує для генерації master_secret

master_secret - це не ключ шифрування повідомлень. Він використовується для обрахунку key_block

🗨️ Протокол запису

На цьому етапі клієнт і сервер мають key_block і можуть повноцінно обмінюватися повідомленнями (записами), забезпечуючи автентичність, цілісність та секретність даних. Протокол запису (TLS Record Protocol) відповідає за упакування, шифрування, автентифікацію та передачу даних між клієнтом і сервером. Саме завдяки йому TLS забезпечує конфіденційність, цілісність і надійність зв’язку поверх транспортного рівня (TCP).

Що таке key_block?

key_block - це доволі великий масив байтів, який містить необхідинй набір ключів, що використовуються в TLS. Він включає:

client_write_MAC_key - для підписання повідомлень клієнтом (цілісність, автентичність) - не використовується при AEAD, бо це уже вбудовано у шифрування

server_write_MAC_key - для підписання повідомлень сервером (цілісність, автентичність) - не використовується при AEAD, бо це уже вбудовано у шифрування

client_write_key - для шифрування даних клієнтом

server_write_key - для шифрування даних сервером

client_write_IV - ініціалізаційний вектор клієнта. Використовується при шифруванні для того, аби шифровані блоки були різними навіть при однако вому тексті

server_write_IV - ініціалізаційний вектор сервера. Використовується при шифруванні. Використовується при шифруванні для того, аби шифровані блоки були різними навіть при однаковому тексті

У CBC-режимі (Cipher Block Chaining) client_write_IV та server_write_IV беруться з key_block тільки для шифрування першого запису. У наступних записах IV зазвичай береться з останнього зашифрованого блоку попереднього повідомлення (CBC chaining). для AEAD (Authenticated Encryption with Associated Data) - інша схема

Режими шифрування CBC vs. AEAD

У процесі розвитку протоколу TLS було використано кілька різних підходів до забезпечення конфіденційності та цілісності даних. Одним із ключових моментів цієї еволюції стало поступове відмовлення від режиму шифрування CBC (Cipher Block Chaining) на користь сучасних AEAD (Authenticated Encryption with Associated Data) алгоритмів. Ці дві концепції мають принципові відмінності як з точки зору безпеки, так і з погляду реалізації.

🔐 CBC: класичний підхід до шифрування

CBC (Cipher Block Chaining) – це режим блочного шифрування, в якому кожен блок відкритого тексту XOR-иться з попереднім блоком зашифрованого тексту перед шифруванням. Перший блок шифрується із застосуванням ініціалізаційного вектора (IV), який повинен бути унікальним і непередбачуваним.

Щоб гарантувати цілісність повідомлення, CBC у TLS зазвичай поєднувався з HMAC. Це означає, що для кожного повідомлення спочатку обчислювався MAC (Message Authentication Code), який потім додавався до plaintext і лише після цього відбувалося шифрування.

Такий підхід, відомий як MAC-then-Encrypt, виявився вразливим до низки атак, зокрема:

BEAST-атака, яка використовувала повторюваність IV у TLS 1.0

Padding oracle атаки, що виникали через неправильну обробку вирівнювання (padding)

Крім того, окреме використання HMAC і шифрування ускладнювало реалізацію та підвищувало ризик помилок.

🔐 AEAD: сучасний стандарт безпечного шифрування

На противагу цьому, AEAD (Authenticated Encryption with Associated Data) - це підхід, який поєднує шифрування і перевірку цілісності в єдиному криптографічному примітиві. Алгоритми AEAD, такі як AES-GCM або ChaCha20-Poly1305, одночасно забезпечують:

шифрування даних (confidentiality)

автентичність і цілісність (integrity)

AEAD приймає як вхід:

сам plaintext

симетричний ключ

nonce/IV, що використовується лише один раз

необов’язкові AAD (Associated Authenticated Data) - наприклад, TLS-заголовки

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

Завдяки цьому AEAD:

не потребує окремого HMAC

усуває цілі класи атак

є більш ефективним і простим для реалізації

використовується в TLS 1.3 виключно (CBC там взагалі заборонено)

Критерій

CBC

AEAD

Тип шифрування

Блочне шифрування + окремий MAC (MAC-then-Encrypt)

Інтегроване шифрування + MAC (Encrypt-then-MAC)

Перевірка цілісності

Через HMAC

Вбудований тег (authentication tag)

Береться з key_block або генерується

Формується як nonce

Захист від підміни

Залежить від правильності MAC-then-Encrypt

Автоматичний, на рівні алгоритму

Схильність до атак

Висока (BEAST, Padding Oracle)

Низька

TLS 1.3

❌ не використовується

✅ обов’язковий

Простота реалізації

Складніша

Простіша

Приклади алгоритмів

AES-CBC + HMAC

AES-GCM, ChaCha20-Poly1305

There are no rows in this table

⁠

Структура запису

Поле

Розмір (байт)

Опис

Content Type

Тип вмісту (наприклад, handshake, application data тощо)

Protocol Version

Версія TLS (наприклад, 0x0303 для TLS 1.2)

Length

Довжина зашифрованого вмісту

Fragment

до 16384

Зашифрований фрагмент (може містити MAC або AEAD tag)

There are no rows in this table

⁠

Загальна схема

⁠

Клієнт формує запис

Наприклад, HTTP-запит → подається на TLS

Протокол запису його фрагментує (якщо потрібно)

Додає тег автентичності (або MAC)

Шифрує вміст

Формує заголовок

Надсилає по TCP

Сервер отримує запис

Читає заголовок

Визначає довжину й розшифровує вміст

Перевіряє автентичність (tag або HMAC)

Передає розшифровані дані вище (наприклад, у HTTPS)

🕵️ Вразливості

Протокол TLS (Transport Layer Security) відіграє критичну роль у захисті мережевого трафіку, але його реалізація в різних версіях та режимах шифрування зазнавала низки атак. Більшість цих атак стосуються TLS 1.0 - 1.2, і стали головним рушієм до появи TLS 1.3.

🦁 BEAST (Browser Exploit Against SSL/TLS)

Тип: CBC-атака Рік: 2011 Уразливі версії: TLS 1.0 Мета: Витягти конфіденційні дані (наприклад, cookies)

🔍 Суть:

CBC у TLS 1.0 використовує IV = останній блок попереднього запису

Нападник підсовує жертві JavaScript-код, який створює багато запитів

Підбираючи вміст блоку й аналізуючи шифротекст, можна вгадати значення байт за байтом

🛠 Виправлення:

У TLS 1.1+ кожен запис має новий випадковий IV

У TLS 1.2 рекомендовано AEAD-алгоритми

Браузери додали 1/n-1 спліт (розбивають перший блок на дрібні частини, щоб ускладнити атаку)

📐 Padding Oracle Attack

Тип: Атака на CBC + padding Рік: 2002 (принцип), 2010–2014 (застосування до TLS) Уразливі версії: TLS 1.0–1.2 (з CBC) Мета: Розшифрувати повідомлення без ключа

🔍 Суть:

У CBC шифруванні кожне повідомлення доповнюється padding’ом до повного блоку

Якщо сервер повертає різні помилки для "неправильного padding" і "неправильного MAC", нападник може байт за байтом відгадувати значення

🛠 Виправлення:

Уніфіковане повідомлення про помилку (не розрізняють padding/MAC помилку)

Постійний час обробки (constant-time перевірка MAC)

Перехід на AEAD: там padding не використовується, або він частина автентифікації

🍀 Lucky13

Тип: Timing-атака на CBC + MAC Рік: 2013 Уразливі версії: TLS 1.2 з CBC Мета: Витягти plaintext через точний аналіз часу обробки

🔍 Суть:

Навіть якщо помилки уніфіковані, час обробки padding та MAC трохи різниться

Нападник вимірює ці мікрорізниці - і отримує бітову інформацію

🛠 Виправлення:

Всі перевірки - у constant time

В TLS 1.3 CBC взагалі видалено, як клас

У TLS 1.2 - використовувати лише AEAD-алгоритми (AES-GCM, ChaCha20)

🔓 CRIME (Compression Ratio Info-leak Made Easy)

Тип: Атака на стиснення + шифрування Рік: 2012 Уразливі версії: TLS з включеним compression Мета: Витягти секрети (наприклад, session cookie)

🔍 Суть:

Якщо TLS-level compression включено, і одна частина повідомлення відома (атака з браузера), нападник може бачити зміну довжини стисненого зашифрованого тексту

Це дозволяє відновити частину невідомих даних за допомогою проб і помилок

🛠 Виправлення:

Compression заборонено у TLS 1.3

TLS 1.2: рекомендується вимкнути TLS compression

Браузери давно вимкнули TLS-level compression (не плутати з HTTP compression - вона на вищому рівні)

🔐 BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext)

Тип: Атака на HTTP-level compression Рік: 2013 Не залежить від версії TLS Мета: Витягти секрети з HTTPS-відповідей

🔍 Суть:

Якщо сервер використовує Content-Encoding: gzip на HTTPS-сторінці з секретами (наприклад, CSRF-токени), і частина відповіді контролюється користувачем (наприклад, GET-параметр), можна відновити частину вмісту

🛠 Виправлення:

Не використовувати компресію разом із чутливими даними

Додавати випадкові символи в контекст (noise)

TLS тут не винен, але може бути каналом витоку

⬇️ Downgrade атаки (включно з POODLE)

Тип: Downgrade + CBC атака Рік: 2014 Мета: Змусити сторони перейти на стару, вразливу версію TLS/SSL

🔍 Суть:

Нападник змушує клієнта/сервер перейти на SSL 3.0 (через відключення TLS)

У SSL 3.0 CBC реалізовано так, що padding легко зламати (аналог Padding Oracle)

Атака можлива навіть при підтримці TLS, якщо неправильно обробляються negotiation errors

🛠 Виправлення:

Вимкнення SSL 3.0 повністю (більшість браузерів це зробили)

Впровадження TLS_FALLBACK_SCSV, щоб клієнт повідомляв, що не бажає переходити на нижчу версію

У TLS 1.3: всі старі версії заборонені

🧊 Logjam (атака на слабкі DH групи)

Тип: Криптоаналітична атака на обмін ключами Рік: 2015 Уразливі: TLS з експортними або малими групами DH (512–1024 біт) Мета: Обчислити shared secret → розшифрувати трафік

🔍 Суть:

Деякі сервери підтримують "експортні" параметри (512-біт)

Нападник вказує клієнту, що такі параметри підтримуються

Потім зламує DH-обчислення - і розшифровує весь трафік

🛠 Виправлення:

Заборонити експортні шифри (EXPORT)

Використовувати мінімум 2048-бітні групи DH

TLS 1.3: використовує лише безпечні обрані групи

🚀 TLS 1.3: сучасний стандарт безпеки

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

🔧 Основні зміни

1️⃣ Спрощений Handshake

Замість двох раундів – один. Менше повідомлень → швидше встановлення з’єднання

Більшість параметрів узгоджуються одразу в ClientHello

Сервер відповідає своїми параметрами, і вже після другого повідомлення можна переходити до шифрування

Підтримка 0-RTT (zero round trip time) для повторних з’єднань - передача даних ще до завершення рукостискання (із обмеженнями)

2️⃣ Лише сучасні алгоритми

Видалено всі небезпечні або застарілі алгоритми:

RSA key exchange ❌

CBC ❌

SHA-1 ❌

MD5 ❌

RC4 ❌

TLS 1.3 підтримує тільки AEAD-алгоритми (AES-GCM, ChaCha20-Poly1305) та PFS-сумісні обміни ключами (ECDHE).

3️⃣ Обов’язкова Forward Secrecy (PFS)

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

4️⃣ Захист від Downgrade-атак

TLS 1.3 вбудовано механізм виявлення спроб примусового зниження версії (downgrade protection). Якщо клієнт підтримує TLS 1.3, але змушений перейти на 1.2, він побачить маркер, який сигналізує про можливу атаку.

5️⃣ Більше немає "negotiation hell"

У TLS 1.2 можна було узгодити багато комбінацій алгоритмів (cipher suites), часто з небезпечними опціями. У TLS 1.3:

Кількість cipher suites скорочена

Всі вони використовують AEAD + SHA-2

Сервер вибирає лише з безпечного, стандартизованого списку

6️⃣ Менший час на з'єднання

Завдяки меншій кількості кроків TLS 1.3 працює до 30% швидше, ніж TLS 1.2. Особливо помітно це у мобільних застосунках і сервісах з великою кількістю мікроз'єднань (наприклад, HTTP/2, gRPC).

💪 Best Practices

TLS сам по собі - потужний протокол. Але навіть найкраща технологія може бути небезпечною, якщо її неправильно налаштувати. Нижче – набір перевірених практик, які допоможуть вам гарантувати безпеку та надійність TLS-з’єднань у ваших проектах.

✅ Вимикайте застарілі версії TLS

Повністю відключіть TLS 1.0 і 1.1 – вони мають критичні вразливості

Увімкніть тільки TLS 1.2 і TLS 1.3, надаючи пріоритет 1.3

✅ Обирайте лише сучасні cipher suites

TLS 1.3 вже має обмежений безпечний набір – нічого міняти не потрібно.

Для TLS 1.2:

Використовуйте лише AEAD-алгоритми: AES-GCM, ChaCha20-Poly1305

Відключіть CBC, RC4, 3DES, MD5, SHA-1

✅ Використовуйте перевірені сертифікати

Тільки X.509 сертифікати від надійних CA (Certificate Authority)

Мінімальна довжина RSA-ключа – 2048 біт, краще – ECC-сертифікати (наприклад, secp256r1)

Уникайте самопідписаних сертифікатів у продакшн-середовищах

Автоматизуйте оновлення сертифікатів – Let's Encrypt + Certbot / win-acme / ACME protocol

✅ Перевіряйте валідність сертифікатів

Увімкніть перевірку ланцюжка довіри і перевірку відкликання сертифіката (CRL / OCSP).

HttpClientHandler handler = new HttpClientHandler {

ServerCertificateCustomValidationCallback = (message, cert, chain, errors) => {

return errors == SslPolicyErrors.None;

}

};

(або використовуйте SslStream з власним RemoteCertificateValidationCallback для fine-tuning)

✅ Вимикайте TLS Compression

TLS-level compression – це CRIME-вразливість

У TLS 1.3 її немає взагалі

Якщо використовуєте TLS 1.2 – вимкніть компресію, вона більше шкодить, ніж допомагає

✅ Захищайте від downgrade-атак

Увімкніть підтримку TLS_FALLBACK_SCSV

В TLS 1.3 це вбудовано автоматично

Усі клієнти мають сигналізувати про "максимально підтримувану версію"

✅ Мінімізуйте поверхню атаки

Вимкніть підтримку невикористовуваних cipher suites, протоколів і розширень

Якщо не використовуєте mTLS - не запитуйте client certificate

Якщо TLS термінує API Gateway – не залишайте трафік "plaintext" усередині (використовуйте внутрішній TLS)

✅ Використовуйте HSTS (HTTP Strict Transport Security)

Це захищає від downgrade до HTTP та атак типу SSL stripping.

У HTTP-відповіді встановіть заголовок:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Можна додати свій домен до списку preload:

https://hstspreload.org/⁠

⁠

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

Уникайте кастомної реалізації TLS – це надзвичайно складно і небезпечно.

В .NET використовуйте HttpClient, SocketsHttpHandler, SslStream, Kestrel – вони вже мають підтримку TLS 1.3.

✅ Регулярно тестуйте свою конфігурацію

Скористайтеся сервісами перевірки TLS-конфігурацій:

⁠

SSL Labs⁠

⁠

Hardenize⁠

⁠

Mozilla TLS Guidelines⁠

⁠

🧩 Висновки

У наш час, коли більшість сервісів і додатків працюють у мережі, захист переданих даних стає не просто бажаним, а необхідним. Від звичайного веббраузера до складної інфраструктури мікросервісів - всюди, де є трафік, має бути TLS.

🔐 TLS - це основа довіри в інтернеті. Саме він гарантує, що інформація не буде перехоплена, змінена або підроблена. Протокол став універсальним інструментом захисту, як для публічних, так і для внутрішніх систем.

🚫 Старі версії протоколу (TLS 1.0, 1.1) вже не відповідають сучасним вимогам безпеки і мають бути повністю відключені. Вони не здатні захистити від актуальних загроз.

🛠️ TLS 1.2 - надійний, але вимогливий. Для безпечного використання його потрібно ретельно налаштувати: уникати застарілих алгоритмів, використовувати AEAD-шифрування, слідкувати за валідністю сертифікатів.

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

⚙️ Але навіть найкращий протокол потребує правильного застосування. Безпека TLS - це не тільки про вибір версії, але й про:

оновлення сертифікатів,

вимкнення компресії,

захист від downgrade-атак,

перевірку налаштувань через спеціальні сервіси.

📌 Висновок простий: TLS - це надійна основа для захисту даних. Але саме від розробника залежить, наскільки добре ця основа реалізована. Обирайте TLS 1.3, впроваджуйте найкращі практики - і ви отримаєте міцний фундамент для безпечної цифрової взаємодії.