Коли користувач відкриває сайт через HTTPS, браузер і сервер узгоджують параметри захищеного з’єднання. Сервер підтверджує свою справжність цифровим сертифікатом, після чого сторони формують сеансові ключі й починають зашифрований обмін HTTP-запитами та відповідями. Перехоплений трафік без цих ключів практично неможливо прочитати або непомітно змінити.
У повсякденному вжитку цей процес досі називають SSL-шифруванням, а цифровий сертифікат – SSL сертифікатом. Насправді сучасні сайти використовують TLS. SSL був його попередником і більше не вважається безпечним протоколом.
Чим відрізняються SSL, TLS і HTTPS
SSL, або Secure Sockets Layer, був раннім протоколом захисту мережевих з’єднань. Усі його версії застаріли й не повинні використовуватися сучасними сайтами. Назви «SSL сертифікат» і «SSL-шифрування» залишилися поширеними переважно через звичку.
TLS, або Transport Layer Security, – актуальний протокол, який створює захищений канал між клієнтом і сервером. Під час TLS handshake сторони обирають версію протоколу й алгоритми, перевіряють сервер та формують ключі. Сьогодні використовують передусім TLS 1.2 і TLS 1.3.
HTTPS – це передавання звичайного HTTP-трафіку всередині TLS-з’єднання. HTTP визначає, як браузер і сервер обмінюються запитами та відповідями, сертифікат допомагає перевірити сервер, а TLS захищає сам канал зв’язку.
Яку роль виконує SSL сертифікат
SSL сертифікат – це цифровий документ із даними про домен, відкритим ключем, строком чинності, відомостями про видавця та його цифровим підписом. Він не шифрує весь трафік самостійно. Його головне завдання – допомогти браузеру перевірити, що відкритий ключ справді належить серверу потрібного домену.
Рівень перевірки залежить від типу сертифіката. DV-сертифікат підтверджує контроль над доменом, але не юридичну ідентичність власника. Під час випуску OV-сертифіката додатково перевіряється організація. Шифрування в обох випадках повноцінне, різниця полягає саме в обсязі перевірених даних.
Відкритий ключ міститься в сертифікаті, а відповідний закритий ключ зберігається на сервері. Сервер доводить, що володіє цією ключовою парою, а цифровий підпис центру сертифікації підтверджує справжність сертифіката.
Браузери та операційні системи мають списки довірених кореневих сертифікатів. Сертифікат сайту пов’язується з ними через один або кілька проміжних сертифікатів. Якщо частини цього ланцюжка немає, сайт може показувати помилку навіть за чинного сертифіката домену.
Як відбувається TLS handshake між браузером і сервером
TLS handshake проходить до основного обміну даними. У TLS 1.2 і TLS 1.3 окремі деталі різняться, але загальна послідовність залишається подібною.
- Браузер надсилає параметри з’єднання. У повідомленні ClientHello передаються підтримувані версії TLS, криптографічні параметри та службові дані. Паролі, вміст форм або готовий сеансовий ключ на цьому етапі не надсилаються.
- Сервер обирає параметри й надсилає сертифікат. У відповіді ServerHello він визначає версію протоколу й алгоритми, передає ланцюжок сертифікатів і дані для узгодження ключів. Якщо сумісних параметрів немає, з’єднання переривається.
- Браузер перевіряє сертифікат. Він звіряє домен, строк чинності, цифровий підпис і ланцюжок довіри. За можливості також перевіряється статус відкликання. Критична помилка призводить до попередження про небезпечне з’єднання.
- Сторони формують спільний секрет. Браузер і сервер обмінюються криптографічними даними та окремо обчислюють однаковий спільний секрет, з якого створюються сеансові ключі. У типовому TLS 1.3 браузер не надсилає серверу готовий секретний ключ, просто зашифрований відкритим RSA-ключем.
- Починається зашифрований обмін. Після завершення handshake сторони переходять до швидкого симетричного шифрування HTTP-запитів і відповідей. Сеансові ключі пов’язані з конкретним з’єднанням, а не зі строком дії сертифіката.
Чому TLS використовує різні типи шифрування
| Підхід | Де використовується | Яку задачу вирішує | Чому не використовується самостійно |
| Асиметрична криптографія | Автентифікація та узгодження ключів | Працює з відкритим і закритим ключами, допомагає перевірити сервер | Потребує більше обчислень |
| Симетрична криптографія | Основний обмін даними після handshake | Швидко шифрує трафік і контролює його цілісність | Сторонам спочатку потрібно безпечно отримати спільні ключі |
Відкритий ключ можна передавати, а закритий має залишатися у власника. Асиметрична криптографія допомагає серверу підтвердити володіння ключем і взяти участь в узгодженні спільного секрету. Для постійного передавання великого обсягу даних вона потребувала б забагато ресурсів.
Після handshake узгодженими сеансовими ключами захищаються сторінки, HTTP-заголовки, cookies, форми та відповіді API. Симетричне шифрування працює значно швидше й також дозволяє виявити зміну даних під час передавання.
Які дані захищає HTTPS
HTTPS захищає логіни, паролі, платіжні й контактні дані, вміст форм, cookies, HTTP-заголовки, шлях сторінки, параметри запиту та відповідь сервера. У мережі можуть залишатися видимими IP-адреси, час і приблизний обсяг обміну, а іноді й домен. Сам вміст запиту при цьому залишається зашифрованим.
Водночас HTTPS не усуває вразливості сайту, зараження пристрою, фішинг або витік із бази даних після злому сервера. Він захищає інформацію під час передавання, але не замінює оновлення програмного забезпечення, контроль доступу, резервні копії та інші заходи безпеки.
TLS-шифрування забезпечує три основні властивості захищеного з’єднання:
- Конфіденційність. Перехоплений трафік виглядає як зашифрований потік. Без потрібних ключів із нього не можна просто прочитати пароль, повідомлення або відповідь сервера.
- Цілісність. TLS дозволяє виявити зміну даних. Якщо хтось спробує підмінити реквізити або додати код у сторінку під час передавання, криптографічна перевірка не пройде.
- Автентифікація. Браузер перевіряє, що сертифікат відповідає потрібному домену та пов’язаний із довіреним центром сертифікації. Це знижує ризик підключення до сервера, який видає себе за справжній сайт.
Чи можна перехопити дані, захищені HTTPS
Мережевий трафік можна записати, але за коректного налаштування TLS 1.2 або TLS 1.3 прочитати його без ключів практично неможливо. Власник звичайної публічної Wi-Fi-мережі не отримує через це доступ до паролів, вмісту форм або відкритих сторінок.
Реальні ризики частіше пов’язані з простроченим чи неправильно встановленим сертифікатом, застарілими протоколами, компрометацією сервера, фішингом, шкідливим програмним забезпеченням та ігноруванням попереджень браузера.
На керованих корпоративних пристроях трафік іноді перевіряється через спеціально встановлений довірений сертифікат. У такому випадку система компанії свідомо виступає проміжною ланкою для цього пристрою.
Як перевірити, чи захищене з’єднання із сайтом
Адреса сайту має починатися з https://. Біля неї браузер дозволяє відкрити відомості про з’єднання та сертифікат. Самого значка замка недостатньо: фішинговий сайт також може мати чинний сертифікат для власного домену.
Уважно перевірте адресу. У ній не повинно бути зайвих слів, замінених літер або незвичного доменного закінчення. У даних сертифіката можна побачити домени, для яких він виданий, строк чинності та центр сертифікації.
Після критичного попередження браузера не вводьте пароль, платіжні або особисті дані. Спочатку перевірте адресу, дату й час на пристрої. Власнику сайту потрібно виправити сертифікат або конфігурацію сервера, а не радити користувачам обходити попередження.
Типові проблеми SSL/TLS на сайті
Найчастіше проблеми із захищеним з’єднанням пов’язані не з самим принципом TLS, а з неправильним встановленням або несвоєчасним оновленням сертифіката.
- Прострочений або недійсний сертифікат. Після завершення строку чинності браузери показують попередження, а застосунки й API можуть відмовитися підключатися. Сертифікат потрібно оновити й перевірити, що сервер використовує новий файл.
- Неповний ланцюжок сертифікатів. Без потрібного проміжного сертифіката сайт може відкриватися на одних пристроях і не працювати на інших. На сервері встановлюють повний ланцюжок від центру сертифікації.
- Невідповідність домену. Сертифікат повинен охоплювати точне ім’я сайту, зокрема потрібні варіанти з www, без нього та піддомени.
- Змішаний контент. Якщо HTTPS-сторінка завантажує зображення, скрипти або стилі через HTTP, браузер може заблокувати їх. Потрібно оновити внутрішні URL, шаблони, записи в базі та зовнішні підключення.
- Застарілі протоколи й алгоритми. SSL, TLS 1.0, TLS 1.1 і слабкі алгоритми слід вимкнути. Сервер налаштовують на TLS 1.2 і TLS 1.3 з урахуванням версії програмного забезпечення та необхідної сумісності.
Для яких сайтів потрібен SSL сертифікат
HTTPS потрібен не лише інтернет-магазинам. Навіть звичайна форма зворотного зв’язку передає ім’я, email, номер телефону або текст повідомлення. TLS також захищає саму сторінку від зміни під час доставки користувачеві.
SSL сертифікат потрібен корпоративним сайтам, блогам, особистим кабінетам, форумам, API, адміністративним панелям, вебсервісам і лендингам. HTTP доцільно залишити лише для автоматичного перенаправлення на HTTPS.
Як обрати SSL сертифікат для сайту
Вибір залежить від кількості доменів і піддоменів, рівня перевірки та структури проєкту. Вища ціна не означає автоматично сильніше шифрування.
Сертифікат для одного домену підходить для одного основного сайту. Перед замовленням потрібно перевірити, чи охоплює він адреси з www і без нього. DV підтверджує контроль над доменом, а OV додатково містить перевірені дані організації.
Wildcard-сертифікат зручний, якщо сайт має багато піддоменів одного рівня, наприклад кабінет, пошту й розділ підтримки. Така маска зазвичай не охоплює вкладені піддомени наступного рівня.
Мультидоменний SAN-сертифікат дозволяє захистити кілька різних доменів і піддоменів одним документом. На сторінці SSL сертифікатів RX-NAME можна порівняти доступні варіанти та обрати сертифікат відповідно до структури сайту.
Поширені запитання про SSL/TLS-шифрування
Чи може власник Wi-Fi бачити дані, передані через HTTPS?
Він може бачити факт з’єднання, IP-адреси, час і приблизний обсяг трафіку. Пароль, вміст форми та сторінки за нормального HTTPS залишаються зашифрованими.
Чи шифрує SSL усі дані на сайті?
TLS шифрує інформацію під час передавання між клієнтом і сервером. Дані в базі, файлах, журналах або резервних копіях потребують окремого захисту.
Чим TLS 1.3 відрізняється від попередніх версій?
TLS 1.3 прибрав застарілі механізми, спростив набір алгоритмів і скоротив процес встановлення нового з’єднання. Для сумісності багато серверів паралельно підтримують TLS 1.2.
Чи впливає SSL сертифікат на швидкість сайту?
Handshake і шифрування потребують ресурсів, але на сучасних системах ці витрати зазвичай невеликі. TLS 1.3 і повторне використання сесій додатково зменшують затримку.
Що станеться після завершення терміну дії сертифіката?
Браузери покажуть попередження, а деякі клієнти взагалі відмовляться підключатися. Сертифікат потрібно оновити до завершення строку його чинності.
Чи достатньо HTTPS для повного захисту сайту?
Ні. Потрібні також оновлення CMS і модулів, надійні паролі, контроль доступу, резервні копії, захист сервера та моніторинг.
Висновок
Під час HTTPS-з’єднання браузер і сервер узгоджують параметри TLS, перевіряють сертифікат і формують ключі. Після handshake HTTP-запити та відповіді передаються із застосуванням швидкого симетричного шифрування.
TLS забезпечує конфіденційність, цілісність даних та автентифікацію сервера, але захищає саме канал зв’язку. Він має бути частиною комплексної безпеки сайту.
Перевірте, чи всі сторінки відкриваються через HTTPS без попереджень. Якщо сертифіката немає, строк його дії завершується або він не охоплює потрібні домени, перегляньте SSL сертифікати RX-NAME та оберіть варіант для структури свого проєкту.