Пошук уроків, статей та іншого контенту
Дізнайтеся, як TLS захищає дані під час передавання, працюють сертифікати та встановлюється захищене з’єднання.
TLS (Transport Layer Security) — це криптографічний протокол, який захищає дані під час передавання мережею.
TLS забезпечує:
конфіденційність — сторонні не можуть прочитати передані дані;
цілісність — дані не можна непомітно змінити під час передавання;
автентифікацію сервера — клієнт може перевірити, що підключився саме до потрібного сервера.
Найпоширеніший приклад використання TLS — HTTPS. HTTPS — це HTTP, переданий через захищене TLS-з’єднання.
HTTP + TLS = HTTPSTLS працює не лише з HTTP. Його також використовують інші протоколи, наприклад для захищених поштових з’єднань і підключень до баз даних.
Без TLS дані передаються у відкритому вигляді. Наприклад, під час входу на сайт мережа може побачити:
login=olena&password=my-passwordЯкщо зловмисник контролює Wi-Fi, маршрутизатор або іншу ділянку мережі, він може:
прочитати логін і пароль;
змінити дані запиту;
підмінити відповідь сервера;
перенаправити користувача на інший сервер.
TLS перетворює дані на зашифрований набір байтів, який не має практичного сенсу без ключів шифрування.
Перед передаванням даних клієнт і сервер виконують TLS handshake — рукостискання.
Спрощений порядок для TLS 1.3 такий:
Клієнт надсилає ClientHello
підтримувані версії TLS;
доступні криптографічні алгоритми;
параметри для обміну ключами.
Сервер надсилає ServerHello
обрану версію TLS;
обрані алгоритми;
свій сертифікат;
параметри обміну ключами.
Клієнт перевіряє сертифікат сервера
чи дійсний термін сертифіката;
чи відповідає ім’я сервера сертифікату;
чи підписаний він довіреним центром сертифікації;
чи не порушена структура ланцюжка сертифікатів.
Клієнт і сервер обчислюють спільні ключі Вони не передають готовий секретний ключ мережею. Натомість обмінюються відкритими параметрами й незалежно обчислюють однаковий спільний секрет.
Сторони перевіряють завершення handshake Повідомлення Finished підтверджує, що обидві сторони мають однакові параметри з’єднання.
Передаються зашифровані дані Після handshake HTTP-запити й відповіді шифруються симетричними ключами сесії.
Під час кожного нового з’єднання зазвичай створюються нові ключі сесії. Тому компрометація одного з’єднання не повинна автоматично розкривати всі інші з’єднання.
TLS-сертифікат — це цифровий документ, який пов’язує:
ім’я сервера, наприклад example.com;
відкритий ключ сервера;
термін дії;
інформацію про видавця;
цифровий підпис центру сертифікації.
Сертифікат містить відкритий ключ, але не містить приватного ключа сервера.
Сервер має пару ключів:
відкритий ключ можна безпечно поширювати;
приватний ключ повинен залишатися тільки на сервері.
Приватний ключ використовується сервером для доведення своєї ідентичності під час handshake. Якщо приватний ключ викрадуть, зловмисник може видати себе за сервер.
Клієнт не може просто довіряти будь-якому сертифікату, який надіслав сервер. Інакше зловмисник міг би створити власний сертифікат для чужого домену.
Тому існують центри сертифікації — Certificate Authorities, або CA.
Спрощений ланцюжок виглядає так:
Кореневий сертифікат CA
↓
Проміжний сертифікат CA
↓
Сертифікат example.comОпераційна система або браузер має список довірених кореневих сертифікатів. Клієнт перевіряє підписи в ланцюжку від сертифіката сервера до довіреного кореневого сертифіката.
Якщо ланцюжок не можна перевірити, клієнт показує помилку сертифіката.
Під час підключення клієнт перевіряє щонайменше:
Сертифікат має бути виданий для того домену, до якого виконується підключення.
Сертифікат для api.example.com не повинен автоматично вважатися дійсним для other.example.com.
Сертифікат має бути чинним. Сертифікати з минулим або ще не настанулим терміном дії відхиляються.
Підпис має вести до довіреного кореневого сертифіката.
Клієнт перевіряє, що сертифікат не був змінений після підписання.
Якщо будь-яка важлива перевірка не проходить, безпечний клієнт зазвичай припиняє з’єднання.
Після встановлення з’єднання TLS використовує симетричне шифрування для основного обміну даними.
Симетричне шифрування швидше за операції з парою відкритого та приватного ключів, тому його зручно використовувати для великих обсягів даних.
У результаті:
асиметрична криптографія допомагає встановити довіру й узгодити секрет;
симетрична криптографія захищає подальший обмін даними.
TLS також додає перевірку автентичності повідомлень. Якщо хтось змінить зашифрований пакет, отримувач виявить це й не прийме пошкоджені дані як правильні.
Node.js за замовчуванням перевіряє TLS-сертифікат сервера під час HTTPS-запиту.
const https = require('node:https');
const request = https.request(
{
hostname: 'example.com',
port: 443,
path: '/',
method: 'GET'
},
(response) => {
let body = '';
response.setEncoding('utf8');
response.on('data', (chunk) => {
body += chunk;
});
response.on('end', () => {
console.log('Статус:', response.statusCode);
console.log('Перші 200 символів відповіді:');
console.log(body.slice(0, 200));
});
}
);
request.on('socket', (socket) => {
socket.on('secureConnect', () => {
console.log('Версія TLS:', socket.getProtocol());
console.log('Шифр:', socket.getCipher().name);
});
});
request.on('error', (error) => {
console.error('Помилка HTTPS-запиту:', error.message);
});
request.end();Запустити приклад можна командою:
node https-request.jsПід час виконання програма:
підключиться до example.com через порт 443;
встановить TLS-з’єднання;
перевірить сертифікат сервера;
надішле HTTPS-запит;
виведе версію TLS і використаний шифр.
Якщо сертифікат не пройде перевірку, запит завершиться помилкою.
Коли браузер відкриває адресу на кшталт:
https://example.comвін:
встановлює TCP-з’єднання;
виконує TLS handshake;
перевіряє сертифікат;
передає HTTP-запит через захищений канал.
Значок замка в адресному рядку означає, що браузер успішно встановив захищене з’єднання з сервером і перевірив його сертифікат.
Однак TLS не гарантує, що сам сайт чесний або що його застосунок не має вразливостей. TLS підтверджує захищене з’єднання з певним доменом, але не правильність усієї бізнес-логіки сайту.
TLS захищає:
вміст запитів і відповідей під час передавання;
паролі, токени та інші дані від перехоплення;
дані від непомітної зміни в мережі;
клієнта від підключення до сервера з недійсним сертифікатом.
TLS не захищає від:
шкідливого коду на самому сервері;
зламаного комп’ютера користувача;
викрадених токенів із браузера або журналів;
помилок у серверній авторизації;
неправильного зберігання даних після їх отримання сервером.
TLS також не приховує всю мережеву інформацію. Наприклад, певні дані про підключення, IP-адресу або обсяг трафіку можуть залишатися видимими для мережевої інфраструктури.
Передавання паролів або токенів через звичайний HTTP дозволяє перехопити їх у мережі.
Для конфіденційних даних слід використовувати HTTPS.
У деяких бібліотеках можна вимкнути перевірку сертифіката, наприклад параметром на кшталт rejectUnauthorized: false.
Це небезпечно: клієнт перестає перевіряти, з яким сервером він встановив з’єднання. Такий підхід може зробити з’єднання вразливим до атаки посередника.
Вимкнення перевірки не є виправленням проблеми із сертифікатом. Потрібно виправити конфігурацію сертифіката, ланцюжок довіри або ім’я хоста.
SSL — застарілий попередник TLS. Сучасні системи мають використовувати актуальні версії TLS, а не SSL.
HTTPS часто називають «SSL-з’єднанням» у побуті, але технічно сучасний HTTPS використовує TLS.
Сам факт наявності сертифіката ще не означає, що він правильний. Важливо перевіряти:
доменне ім’я;
термін дії;
ланцюжок довіри;
відповідність сертифіката серверу.
TLS захищає дані під час передавання мережею.
HTTPS — це HTTP поверх TLS.
TLS забезпечує конфіденційність, цілісність і автентифікацію сервера.
Сертифікат пов’язує домен із відкритим ключем сервера.
Довіра до сертифіката будується через центри сертифікації та ланцюжок сертифікатів.
Під час handshake сторони узгоджують параметри й створюють ключі сесії.
Після handshake дані шифруються швидким симетричним шифром.
Не слід вимикати перевірку TLS-сертифікатів у робочому коді.
TLS захищає канал передавання, але не замінює безпеку самого застосунку.