HTTPS і TLS: як працює захищене з'єднання та навіщо потрібні цифрові сертифікати

1. Від HTTP до HTTPS: навіщо потрібен захист

У попередній статті ми розглянули HTTP — протокол, за допомогою якого браузер і сервер обмінюються запитами та відповідями.

Ми з'ясували, що браузер може отримувати HTML-документи, CSS-файли, зображення, передавати дані форм і взаємодіяти із сервером через HTTP-запити.

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

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

Ти підключився до публічної мережі Wi-Fi у кафе й відкрив сайт, на якому потрібно авторизуватися. Браузер надсилає серверу логін і пароль.

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

Для перехоплення потрібні відповідні технічні можливості. Проте сам HTTP не забезпечує необхідного захисту від таких загроз.

HTTPS — це HTTP, який працює через захищене з'єднання, створене за допомогою протоколу TLS.

Його завдання — захистити обмін даними між клієнтом і сервером.

Якщо коротко:

• HTTP визначає правила обміну повідомленнями.

• TLS захищає передавання цих повідомлень.

• HTTPS поєднує HTTP із захистом TLS.

Тобто HTTPS не замінює HTTP, а додає до нього механізм безпеки.

2. Що саме захищає HTTPS

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

1. Конфіденційність.

2. Цілісність.

3. Автентифікацію.

Розглянемо кожну окремо.

2.1. Конфіденційність (Confidentiality)

Конфіденційність означає, що стороння особа не повинна мати можливості прочитати передані дані, навіть якщо їй вдалося перехопити мережевий трафік.

Для цього використовується шифрування.

Наприклад, браузер надсилає серверу:

login: dmytro

password: my-secret-password

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

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

Важливо: шифрування захищає дані під час передавання. Воно не приховує автоматично всю інформацію про мережеве з'єднання.

Наприклад, IP-адреса сервера та деякі характеристики з'єднання можуть залишатися видимими.

2.2. Цілісність (Integrity)

Цілісність означає, що дані не повинні непомітно змінюватися під час передавання.

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

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

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

2.3. Автентифікація (Authentication)

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

У контексті звичайного відвідування вебсайту браузер має перевірити, що він з'єднується із сервером, який справді має право представляти потрібний домен.

Наприклад, ти вводиш адресу:

https://example.com

Браузер повинен перевірити, що сервер має дійсний цифровий сертифікат для example.com і може підтвердити володіння відповідним приватним ключем.

Це допомагає захиститися від ситуації, коли зловмисник намагається видати свій сервер за справжній сайт.

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

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

3. Що таке TLS і чому раніше говорили про SSL

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

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

Можливо, ти вже зустрічав іншу назву — SSL (Secure Sockets Layer).

• SSL — попередник TLS. Історично він використовувався для захисту мережевих з'єднань, але його версії застаріли та більше не повинні застосовуватися.

• TLS розвивався як наступник SSL і став сучасним стандартом захищеного передавання даних.

Сьогодні можна зустріти такі назви:

• SSL-сертифікат;

• SSL-підключення;

• SSL/TLS;

• TLS-сертифікат.

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

Тому, коли хостинг-провайдер пропонує «безкоштовний SSL-сертифікат», зазвичай ідеться про сертифікат, який використовується для HTTPS-з'єднання через TLS.

3.1. Які версії TLS існують

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

Основні версії:

TLS 1.3 визначений у стандарті RFC 9846. Він удосконалює встановлення з'єднання, криптографічні механізми та захист переданих даних.

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

4. Що таке шифрування і як воно працює

Щоб зрозуміти принцип HTTPS, потрібно познайомитися з поняттям шифрування.

Шифрування (Encryption) — це перетворення інформації у форму, яку неможливо прочитати без відповідного ключа.

Зворотний процес називається розшифруванням (Decryption).

Привіт, сервер!

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

Отримувач, який має відповідний ключ, може відновити початкове повідомлення.

У криптографії існують два основні підходи до шифрування:

• симетричне;

• асиметричне.

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

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

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

У криптографії принцип схожий:

1. Відправник шифрує повідомлення секретним ключем.

2. Передає зашифровані дані.

3. Отримувач використовує той самий ключ для розшифрування.

Перевага симетричного шифрування — висока швидкість. Воно добре підходить для захисту великих обсягів інформації.

Один із сучасних прикладів алгоритму — AES (Advanced Encryption Standard).

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

Саме тут потрібні механізми асиметричної криптографії та узгодження ключів.

4.2. Асиметричне шифрування і пара ключів

Асиметрична криптографія використовує пару математично пов'язаних ключів:

• відкритий ключ (Public Key);

• приватний ключ (Private Key).

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

Тобто шифрування та цифровий підпис мають різні завдання:

• Шифрування допомагає приховати зміст інформації від сторонніх осіб.

• Цифровий підпис дає змогу перевірити автентичність підписаних даних та їхню цілісність.

Відкритий ключ можна передавати іншим людям. Приватний ключ повинен залишатися в секреті у власника.

У спрощеній моделі шифрування:

• дані, зашифровані відкритим ключем, можна розшифрувати відповідним приватним ключем;

• приватний ключ також може використовуватися для створення цифрового підпису, який перевіряється відкритим ключем.

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

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

Однак важливо не плутати дві різні операції:

• шифрування забезпечує конфіденційність;

• цифровий підпис дає змогу перевірити походження та цілісність підписаних даних.

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

4.3. Як TLS поєднує обидва підходи

Може виникнути запитання: чому не використовувати лише асиметричне шифрування?

Тому TLS використовує комбінований підхід:

1. За допомогою криптографічних механізмів сторони встановлюють спільний секрет.

2. На його основі отримують симетричні ключі для захисту передавання даних.

3. Подальший обмін HTTP-повідомленнями захищається швидким симетричним шифруванням.

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

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

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

5. Цифровий сертифікат: як браузер розуміє, кому довіряти

Ми вже з'ясували, що для захищеного з'єднання важливо перевірити справжність сервера.

Адже зловмисник теж може створити власну пару ключів і надіслати браузеру свій відкритий ключ.

Для розв'язання цієї проблеми використовуються цифрові сертифікати (Digital Certificates).

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

У контексті HTTPS сертифікат пов'язує відкритий ключ із доменним ім'ям.

Наприклад, сертифікат може містити інформацію про те, що певний відкритий ключ використовується для домену:

example.com

Завдяки цьому браузер може перевірити, чи має сервер право представляти цей домен.

5.1. Що містить цифровий сертифікат

Сертифікати вебсайтів зазвичай використовують формат X.509.

Серед основних відомостей сертифіката:

• доменні імена, для яких він виданий;

• відкритий ключ;

• інформація про видавця сертифіката;

• строк дії;

• серійний номер;

• призначення та обмеження використання;

• цифровий підпис центру сертифікації.

Наприклад, спрощене представлення:

• Сертифікат:

• Домен: example.com

• Видавець: Example Certificate Authority

• Дійсний від: 01.01.2026

• Дійсний до: 01.04.2026

• Відкритий ключ: ...

• Цифровий підпис: ...

Це лише ілюстрація. Реальний сертифікат має стандартизовану структуру та містить більше технічної інформації.

5.2. Хто видає сертифікати

Сертифікати для вебсайтів зазвичай видають спеціальні організації — центри сертифікації (Certificate Authorities, CA).

Приклади центрів сертифікації:

• Let's Encrypt;

• DigiCert;

• GlobalSign;

• Sectigo.

Браузери та операційні системи мають набори довірених кореневих сертифікатів. Завдяки цьому вони можуть перевіряти сертифікати, видані організаціями, яким довіряють.

5.3. Як браузер перевіряє сертифікат

Коли браузер отримує сертифікат сервера, він перевіряє кілька важливих речей:

1. Чи виданий сертифікат для домену, до якого звертається користувач?

2. Чи не закінчився строк його дії?

3. Чи не був сертифікат відкликаний?

4. Чи можна перевірити цифровий підпис видавця?

5. Чи веде ланцюжок сертифікатів до довіреного кореневого центру сертифікації?

6. Чи відповідає сертифікат вимогам і правилам перевірки браузера?

Перевірка відкликання залежить від браузера, його політики та доступних механізмів отримання інформації. 

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

6. Ланцюжок довіри: Root CA, Intermediate CA і сертифікат сайту

Щоб краще зрозуміти перевірку сертифікатів, потрібно познайомитися з поняттям ланцюжка довіри (Certificate Chain).

Він має перевірити, хто його підписав і чи можна довіряти цьому підпису.

У реальній інфраструктурі сертифікати часто організовані в ієрархічну структуру.

Вона може виглядати так:

Root CA

   |

   v

Intermediate CA

   |

   v

Сертифікат сайту example.com

Розглянемо кожен рівень.

6.1. Root CA — кореневий центр сертифікації

Root CA — це кореневий центр сертифікації, довіра до якого встановлюється через довірені сховища браузера або операційної системи.

Самопідписаний означає, що сертифікат підписаний власним приватним ключем відповідного центру.

Але сам факт самопідпису не робить сертифікат довіреним. Довіра виникає тому, що кореневий сертифікат уже включений до довіреного сховища.

6.2. Intermediate CA — проміжний центр сертифікації

Проміжний центр сертифікації розташований між кореневим центром і кінцевим сертифікатом сайту.

Він отримує право видавати сертифікати завдяки сертифікату, підписаному вищим рівнем довіри.

Це зменшує ризики для кореневого ключа.

6.3. Сертифікат сайту

Це кінцевий сертифікат, який використовується сервером для підтвердження своєї ідентичності.

Наприклад:

example.com

Його підписує проміжний центр сертифікації.

Браузер перевіряє підпис проміжного сертифіката, потім переходить до кореневого сертифіката та перевіряє, чи є він довіреним.

Саме так працює механізм ланцюжка довіри.

7. Як відбувається встановлення HTTPS-з'єднання: TLS Handshake

Тепер ми знаємо, що для HTTPS потрібні:

• HTTP;

• TLS;

• криптографічні алгоритми;

• цифровий сертифікат;

• механізм перевірки довіри;

• узгоджені ключі для шифрування.

Але як усе це працює разом?

Коли браузер відкриває сайт через HTTPS, перед передаванням звичайних HTTP-повідомлень відбувається спеціальний процес — TLS Handshake (рукостискання TLS).

Його завдання:

1. Узгодити параметри захищеного з'єднання.

2. Домовитися про криптографічні механізми.

3. Перевірити автентичність сервера.

4. Встановити спільні секретні ключі.

Розглянемо спрощену послідовність для повного TLS 1.3 handshake із сертифікатною автентифікацією сервера.

7.1. Крок 1. Браузер надсилає ClientHello

Коли браузер хоче встановити захищене з'єднання, він надсилає серверу повідомлення ClientHello.

У ньому міститься інформація про можливості клієнта:

• підтримувані версії TLS;

• доступні криптографічні алгоритми;

• параметри узгодження ключів;

• додаткові розширення.

Серед іншого браузер повідомляє, які варіанти захищеного з'єднання він підтримує.

7.2. Крок 2. Сервер відповідає ServerHello

Сервер отримує повідомлення та вибирає сумісні параметри.

Потім надсилає ServerHello.

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

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

Тому наступні повідомлення TLS 1.3, зокрема параметри сервера та сертифікат, передаються вже в зашифрованому вигляді.

7.3. Крок 3. Сервер надсилає сертифікат

Перед передаванням сертифіката сервер надсилає ще одне повідомлення — EncryptedExtensions.

У ньому містяться додаткові параметри з'єднання, які сервер погодив із клієнтом на основі запропонованих можливостей.

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

Браузер перевіряє:

• чи відповідає сертифікат потрібному домену;

• чи не закінчився строк дії;

• чи можна перевірити його підпис;

• чи веде ланцюжок до довіреного кореневого сертифіката;

• чи немає інших проблем із сертифікатом.

7.4. Крок 4. Сервер підтверджує володіння приватним ключем

Самого сертифіката недостатньо.

Тому сервер повинен криптографічно довести, що він володіє відповідним приватним ключем.

У TLS 1.3 для цього, коли використовується сертифікатна автентифікація, застосовується повідомлення CertificateVerify.

Сервер створює цифровий підпис із використанням приватного ключа. Браузер перевіряє цей підпис за допомогою відкритого ключа із сертифіката.

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

Якщо перевірка успішна, це підтверджує, що сервер має відповідний приватний ключ і підписав дані поточного рукостискання.

7.5. Крок 5. Сторони підтверджують завершення рукостискання

Після узгодження ключів та перевірки автентичності сторони надсилають повідомлення Finished.

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

Повідомлення Finished містить криптографічне підтвердження, пов'язане з усім попереднім перебігом рукостискання.

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

7.6. Крок 6. Починається обмін HTTP-повідомленнями

Тепер браузер може надсилати звичайні HTTP-запити через встановлене захищене з'єднання.

Наприклад:

GET /account HTTP/1.1

Host: example.com

Але тепер HTTP-повідомлення передаються всередині TLS-захисту.

Тобто сторонній спостерігач не повинен мати можливості прочитати їхній вміст або непомітно змінити його.

7.7. Уся послідовність в одному місці

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

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

Основна ідея така: спочатку браузер і сервер встановлюють захищений канал, а потім використовують його для обміну HTTP-повідомленнями.

8. Що таке атака «людина посередині» (Man-in-the-Middle)

Однією з причин створення HTTPS була необхідність захисту від атак типу Man-in-the-Middle (MITM).

Назва перекладається як «людина посередині».

Суть атаки полягає в тому, що зловмисник намагається розташуватися між двома сторонами зв'язку та втрутитися в їхню взаємодію.

Уявімо звичайне підключення:

Браузер -------- Сервер

Тепер уявімо, що між ними з'являється зловмисник:

Браузер ---- Зловмисник ---- Сервер

Зловмисник може намагатися:

• перехоплювати повідомлення;

• змінювати передані дані;

• підміняти відповіді;

• видавати власний сервер за справжній.

HTTPS протидіє цьому завдяки шифруванню, перевірці цілісності та автентифікації сервера.

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

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

9. Як браузер показує, що з'єднання захищене

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

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

Наприклад:

https://example.com

Однак важливо розуміти, що наявність HTTPS або відповідного індикатора не означає, що сайт гарантовано безпечний у всіх аспектах.

Захищене з'єднання не гарантує:

• чесності власника сайту;

• відсутності шахрайства;

• безпеки завантажуваних файлів;

• відсутності шкідливого коду;

• надійності платіжної системи;

• правильного зберігання паролів на сервері.

Шахрайський сайт також може мати цілком дійсний HTTPS-сертифікат.

Тому HTTPS слід сприймати як необхідний механізм захисту передавання даних, а не як універсальну гарантію безпеки сайту.

10. Які проблеми можуть виникнути з HTTPS

Навіть якщо сайт використовує HTTPS, під час встановлення з'єднання можуть виникати помилки.

Розглянемо найпоширеніші ситуації.

10.1. Сертифікат прострочений

Кожен сертифікат має строк дії.

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

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

10.2. Сертифікат виданий для іншого домену

Уявімо, що ти відкриваєш:

https://example.com

А сервер передає сертифікат, який виданий для:

other-example.com

У такому випадку браузер виявить невідповідність і попередить користувача.

Це може статися через помилку конфігурації сервера або через спробу підміни.

10.3. Сертифікат не довірений

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

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

10.4. Сертифікат відкликаний

Центр сертифікації може відкликати сертифікат до завершення строку його дії.

Причини можуть бути різними:

• приватний ключ скомпрометований;

• сертифікат виданий помилково;

• змінилися обставини, за яких він був виданий.

Конкретні механізми та поведінка залежать від браузера й середовища.

10.5. Неправильна дата на пристрої

Браузер перевіряє строк дії сертифіката.

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

Важливо: якщо браузер показує попередження про сертифікат, не варто автоматично натискати «Продовжити» або ігнорувати його. Спочатку потрібно зрозуміти причину проблеми.

11. Змішаний вміст (Mixed Content)

Є ще одна цікава ситуація.

Уявімо, що основна сторінка відкривається через HTTPS:

https://example.com

Але всередині HTML-документа є зображення, яке завантажується через звичайний HTTP:

<img src="http://example.com/image.jpg" alt="Зображення">

Варто врахувати, що сучасні браузери не завжди просто завантажують такий ресурс через HTTP.

Звичайні зображення, які завантажуються через незахищене з'єднання, браузер може автоматично спробувати отримати через HTTPS. Якщо захищена версія ресурсу недоступна, завантаження може бути заблоковане.

Для інших типів ресурсів, зокрема JavaScript-файлів, браузери зазвичай застосовують суворіші правила та блокують незахищене завантаження.

У такому випадку основна сторінка захищена, але окремий ресурс передається незахищеним з'єднанням.

• Це називається Mixed Content — змішаний вміст.

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

Сучасні браузери блокують багато типів небезпечного змішаного вмісту, а деякі ресурси можуть автоматично переводитися на HTTPS.

Правильний підхід для розробника — завантажувати всі ресурси через захищене з'єднання.

Наприклад:

<img src="https://example.com/image.jpg" alt="Зображення">

Те саме стосується:

• CSS-файлів;

• JavaScript-файлів;

• шрифтів;

• відео;

• зображень;

• інших ресурсів сторінки.

12. Як сайт автоматично переходить із HTTP на HTTPS

Навіть якщо сайт підтримує HTTPS, користувач може ввести адресу без захищеного протоколу:

http://example.com

Щоб не залишати користувача на незахищеній версії сайту, сервер зазвичай налаштовують на перенаправлення.

Наприклад:

HTTP/1.1 301 Moved Permanently

Location: https://example.com/

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

Браузер отримує відповідь і переходить на HTTPS-версію.

Під час першого звернення до сайту через HTTP зловмисник потенційно може втрутитися в початкове перенаправлення.

Для додаткового захисту існує механізм HSTS (HTTP Strict Transport Security).

12.1. Що таке HSTS

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

Сервер може надіслати такий заголовок:

Strict-Transport-Security: max-age=31536000

Однак є важлива особливість: браузер приймає заголовок HSTS лише тоді, коли отримує його через захищене HTTPS-з'єднання.

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

Тому HSTS не захищає автоматично перше звернення до сайту через HTTP. Для цього потрібен додатковий механізм — HSTS Preload, про який поговоримо далі.

Це повідомляє браузеру, що протягом 31 536 000 секунд, тобто одного року, потрібно використовувати HTTPS для відповідного домену.

Після отримання такого заголовка браузер автоматично переводитиме подальші звернення до сайту з HTTP на HTTPS.

12.2. HSTS Preload

• Існує також механізм HSTS Preload.

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

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

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

Власник сайту повинен подати домен на включення до списку та виконати встановлені вимоги. Зокрема, сайт має підтримувати HTTPS, використовувати достатньо тривалий період дії політики HSTS, а також застосовувати директиви includeSubDomains і preload.

HSTS Preload посилює захист, але потребує обережного налаштування: якщо певний піддомен не підтримує HTTPS, користувачі можуть втратити можливість відкрити його через браузер.

13. Як отримати HTTPS-сертифікат для власного сайту

Тепер перейдемо від теорії до практичного питання: якщо ти створиш власний сайт, як зробити так, щоб він працював через HTTPS?

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

Let's Encrypt — це некомерційний центр сертифікації, який автоматизує видачу сертифікатів для HTTPS.

13.1. Як працює отримання сертифіката

Процес можна спростити до кількох кроків:

1. Власник сайту має доменне ім'я.

2. На сервері запускається спеціальна програма — ACME-клієнт.

3. Клієнт звертається до центру сертифікації.

4. Центр сертифікації просить підтвердити контроль над доменом.

5. Власник виконує перевірку.

6. Після успішної перевірки центр сертифікації видає сертифікат.

7. Сертифікат налаштовується на вебсервері.

8. Сервер починає приймати захищені HTTPS-з'єднання.

13.2. Як підтверджується контроль над доменом

Let's Encrypt використовує протокол ACME (Automatic Certificate Management Environment).

Для перевірки контролю над доменом можуть застосовуватися різні методи.

HTTP-01

Клієнт розміщує спеціальний файл за визначеною адресою на сайті.

Центр сертифікації звертається до цієї адреси й перевіряє наявність потрібного вмісту.

DNS-01

Власник домену створює спеціальний DNS-запис із певним значенням.

Центр сертифікації перевіряє, чи існує відповідний запис.

Після успішної перевірки можна отримати сертифікат.

13.3. Чи потрібно самостійно налаштовувати сертифікат

• Не завжди.

Багато сучасних хостинг-провайдерів автоматично забезпечують HTTPS для розміщених сайтів.

У деяких випадках достатньо:

• додати домен до хостингу;

• активувати HTTPS;

• дочекатися випуску сертифіката.

Якщо сайт розміщений на власному сервері, налаштування може потребувати додаткових дій: встановлення ACME-клієнта, налаштування вебсервера, автоматичного оновлення сертифіката та перенаправлення HTTP на HTTPS.

14. Практична робота: перевіряємо HTTPS у браузері

Тепер перевіримо все, що вивчили, на реальному сайті.

Для цього використаємо Google Chrome.

14.1. Перевірка захищеного з'єднання

1. Відкрий сайт, який використовує HTTPS.

2. Подивись на адресу в адресному рядку.

3. Переконайся, що вона починається з https://.

4. Натисни на значок налаштувань або інформації про сайт біля адреси.

5. Знайди розділ, пов'язаний із безпекою з'єднання.

6. Переглянь доступні відомості про сертифікат.

Зверни увагу на те, що інтерфейс браузера може змінюватися залежно від його версії.

14.2. Перегляд сертифіката

У Google Chrome можна відкрити інструменти розробника:

1. Натисни F12.

2. Відкрий меню додаткових інструментів.

3. Обери Privacy and security.

4. Перейди до розділу Security.

5. Знайди інформацію про основний домен.

6. Натисни View certificate, якщо така можливість доступна.

Ти зможеш побачити:

• домен, для якого виданий сертифікат;

• видавця;

• строк дії;

• відкритий ключ;

• інші технічні відомості.

14.3. Що потрібно перевірити

Спробуй відповісти на запитання:

1. Для якого домену виданий сертифікат?

2. Хто його видав?

3. Коли починається строк його дії?

4. Коли він закінчується?

5. Який алгоритм використовується для відкритого ключа?

6. Чи є в ланцюжку сертифікатів проміжний центр сертифікації?

7. Чи показує браузер попередження про проблеми із сертифікатом?

14.4. Перевірка через вкладку Network

Можна також повернутися до інструмента Network, який ми використовували в попередній статті.

1. Відкрий сайт.

2. Натисни F12.

3. Перейди у вкладку Network.

4. Онови сторінку.

5. Вибери запит основного документа.

6. Переглянь його адресу та протокол, якщо відповідна інформація доступна.

Зверни увагу: HTTP і HTTPS використовують ті самі основні методи, заголовки та коди стану. Різниця полягає в тому, що в HTTPS HTTP-повідомлення передаються через захищений TLS-канал.

15. Підсумок: що ми дізналися

У попередній статті ми розглянули HTTP як протокол обміну повідомленнями між браузером і сервером.

Тепер ми з'ясували, що звичайний HTTP не забезпечує шифрування переданих даних, а HTTPS додає захист за допомогою TLS.

Основні поняття:

• HTTPS — HTTP, який працює через захищене TLS-з'єднання.

• TLS — протокол, який забезпечує конфіденційність, цілісність та автентифікацію.

• SSL — застарілий попередник TLS.

• Шифрування — перетворення даних у захищену форму.

• Симетричне шифрування — використання спільного секретного ключа.

• Асиметрична криптографія — використання пари відкритого та приватного ключів.

• Цифровий сертифікат — електронний документ, який пов'язує відкритий ключ із доменом та містить підпис видавця.

• CA — центр сертифікації, який видає та підписує сертифікати.

• Certificate Chain — ланцюжок сертифікатів, який допомагає браузеру перевірити довіру.

• TLS Handshake — процес узгодження параметрів захищеного з'єднання.

• MITM — атака, під час якої зловмисник намагається втрутитися у зв'язок між двома сторонами.

• Mixed Content — ситуація, коли захищена сторінка завантажує ресурси через незахищене HTTP-з'єднання.

• HSTS — механізм, який змушує браузер використовувати HTTPS для певного сайту.

Найважливіше — зрозуміти послідовність:

• Браузер звертається до сайту

• сервер і браузер виконують TLS Handshake

• браузер перевіряє сертифікат

• сторони встановлюють спільні ключі

• починається захищений обмін HTTP-повідомленнями.

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

16. Практичні запитання для самоперевірки

1. Чим HTTPS відрізняється від HTTP?

2. Що таке TLS і для чого він потрібен?

3. Чому SSL вважається застарілим?

4. Які три основні властивості безпеки забезпечує TLS?

5. Що таке конфіденційність?

6. Що таке цілісність даних?

7. Що таке автентифікація сервера?

8. Чим відрізняється симетричне шифрування від асиметричної криптографії?

9. Що таке відкритий і приватний ключі?

10. Для чого потрібен цифровий сертифікат?

11. Яку інформацію містить сертифікат вебсайту?

12. Що таке центр сертифікації (CA)?

13. Чим відрізняються Root CA та Intermediate CA?

14. Що таке ланцюжок довіри?

15. Що відбувається під час TLS Handshake?

16. Для чого сервер надсилає браузеру сертифікат?

17. Як сервер доводить, що володіє відповідним приватним ключем?

18. Що таке атака Man-in-the-Middle?

19. Чому HTTPS не гарантує, що сайт не є шахрайським?

20. Що таке Mixed Content?

21. Для чого використовується HSTS?

22. Як можна отримати безкоштовний HTTPS-сертифікат через Let's Encrypt?

17. Словник основних термінів

HTTPS (Hypertext Transfer Protocol Secure) — захищений спосіб передавання HTTP-повідомлень із використанням TLS.

TLS (Transport Layer Security) — криптографічний протокол для захищеного обміну даними через мережу.

SSL (Secure Sockets Layer) — застарілий попередник TLS.

Encryption (Шифрування) — перетворення даних у форму, яку неможливо прочитати без відповідного ключа.

Decryption (Розшифрування) — відновлення початкових даних із зашифрованого повідомлення.

Symmetric Encryption (Симетричне шифрування) — шифрування та розшифрування за допомогою спільного секретного ключа.

Asymmetric Cryptography (Асиметрична криптографія) — криптографічні механізми, що використовують пару математично пов'язаних відкритого та приватного ключів.

Public Key (Відкритий ключ) — ключ, який можна передавати іншим сторонам і використовувати для криптографічних перевірок або операцій.

Private Key (Приватний ключ) — секретний ключ, який повинен залишатися під контролем його власника.

Digital Certificate (Цифровий сертифікат) — електронний документ, що містить відкритий ключ, інформацію про домен та цифровий підпис видавця.

CA (Certificate Authority) — центр сертифікації, який видає та підписує цифрові сертифікати.

Root CA — кореневий центр сертифікації, якому довіряє браузер або операційна система.

Intermediate CA — проміжний центр сертифікації, який може видавати кінцеві сертифікати.

Certificate Chain — ланцюжок сертифікатів, за допомогою якого перевіряється довіра до сертифіката сайту.

TLS Handshake — процес встановлення захищеного з'єднання між клієнтом і сервером.

Cipher Suite — набір криптографічних алгоритмів і параметрів, які використовуються для захисту з'єднання.

MITM (Man-in-the-Middle) — тип атаки, за якої зловмисник намагається перехопити або змінити обмін даними між двома сторонами.

Mixed Content — змішаний вміст вебсторінки, коли захищена сторінка завантажує ресурси через незахищене з'єднання.

HSTS (HTTP Strict Transport Security) — механізм, який повідомляє браузеру, що сайт потрібно відкривати лише через HTTPS.

Let's Encrypt — некомерційний центр сертифікації, який автоматизує безкоштовну видачу TLS-сертифікатів.

ACME (Automatic Certificate Management Environment) — протокол автоматизованої взаємодії із центрами сертифікації для отримання, оновлення та відкликання сертифікатів.

18. Джерела та матеріали для подальшого вивчення

Для підготовки статті використано технічну документацію MDN Web Docs, стандарти IETF та офіційні матеріали Let's Encrypt і Chrome Developers.

1. MDN Web Docs — Transport Layer Security (TLS). Загальний принцип роботи TLS, його основні властивості, рукостискання, сертифікати та змішаний вміст.
   https://developer.mozilla.org/en-US/docs/Web/Security/Defenses/Transport_Layer_Security

2. RFC 9846 — The Transport Layer Security (TLS) Protocol Version 1.3. Офіційна технічна специфікація TLS 1.3: встановлення з'єднання, обмін ключами, автентифікація та захист даних.
   https://www.rfc-editor.org/rfc/rfc9846

3. Let's Encrypt — How It Works. Пояснення, як центр сертифікації перевіряє контроль над доменом, видає та відкликає сертифікати.
   https://letsencrypt.org/how-it-works/

4. Chrome Developers — Privacy and security panel. Практична інструкція з перевірки HTTPS-з'єднання, сертифікатів і проблем змішаного вмісту в Chrome DevTools.
   https://developer.chrome.com/docs/devtools/security/

5. MDN Web Docs — HTTPS. Додаткове пояснення принципів HTTPS та його ролі в безпеці вебу.
   https://developer.mozilla.org/en-US/docs/Glossary/HTTPS

6. Mozilla SSL Configuration Generator. Інструмент для формування рекомендованих налаштувань TLS для різних вебсерверів.
   https://configurator.tlsref.org/

Для початку рекомендую прочитати перше джерело MDN, а потім переглянути офіційну сторінку Let's Encrypt. RFC 9846 залиш як технічний довідник, до якого можна повертатися в міру поглиблення знань.