Що таке протокол HTTPS і як він працює

HTTPS (HyperText Transfer Protocol Secure) — це зашифрована версія HTTP, яка поєднує стандартний протокол передачі даних у вебі з TLS (Transport Layer Security) для створення автентифікованого зашифрованого каналу між браузером клієнта та вебсервером. Кожен байт даних, переданих через HTTPS, криптографічно захищений, тобто ні пасивні підслуховувачі, ні активні зловмисники типу «людина посередині» не можуть прочитати або непомітно змінити корисне навантаження під час передачі.

На практиці: коли браузер підключається до https://example.com, він спочатку завершує TLS-рукостискання, яке автентифікує ідентичність сервера за допомогою підписаного сертифіката, узгоджує набір шифрів і виводить симетричні сесійні ключі — і все це до того, як буде передано хоча б один байт даних застосунку. Лише після успішного завершення рукостискання HTTP-запит передається по мережі в повністю зашифрованому вигляді.

HTTP проти HTTPS: пряме порівняння

TLS-рукостискання детально

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

TLS 1.2 рукостискання (застаріле)

1. ClientHello — Браузер надсилає підтримувані набори шифрів, версію TLS та випадковий одноразовий номер (client_random).
2. ServerHello — Сервер вибирає набір шифрів і надсилає власний одноразовий номер (server_random).
3. Certificate — Сервер передає свій ланцюжок сертифікатів X.509 для перевірки браузером у сховищі довірених CA.
4. ServerKeyExchange — Для ефемерного Diffie-Hellman (ECDHE) сервер надсилає свої параметри DH, підписані приватним ключем.
5. ClientKeyExchange — Браузер генерує попередній головний секрет, шифрує його публічним ключем сервера (RSA) або обчислює спільний секрет DH (ECDHE) і надсилає його.
6. ChangeCipherSpec / Finished — Обидві сторони виводять сесійні ключі з client_random, server_random та попереднього головного секрету, після чого підтверджують це повідомленням Finished.

Загальна кількість циклів передачі даних до початку обміну: 2 RTT.

TLS 1.3 рукостискання (поточний стандарт)

TLS 1.3, стандартизований у RFC 8446, усуває кілька застарілих механізмів і значно зменшує затримку:

1. ClientHello — Браузер одразу включає свій ключовий обмін (публічне значення ECDHE) разом із підтримуваними наборами шифрів. Обмін ключами RSA не дозволяється.
2. ServerHello + EncryptedExtensions + Certificate + CertificateVerify + Finished — Сервер відповідає одним пакетом, вже шифруючи розширення та свій сертифікат за допомогою виведеного ключа рукостискання.
3. Client Finished — Браузер перевіряє сертифікат сервера і надсилає своє повідомлення Finished. Дані застосунку можуть передаватися одразу після цього.

Загальна кількість циклів передачі даних до початку обміну: 1 RTT. При відновленні 0-RTT (сесійні квитки) повторні відвідувачі можуть надсилати дані вже з першим пакетом — хоча це вносить міркування щодо атак повторного відтворення, які потребують ретельної обробки на стороні сервера.

Ключові покращення TLS 1.3 порівняно з 1.2:

• Видалено обмін ключами RSA (відсутній ризик для прямої секретності)
• Видалено MD5, SHA-1, RC4, DES, 3DES
• Обов’язкова пряма секретність через ECDHE
• Зашифрована передача сертифіката (зменшує витік метаданих)
• Швидше рукостискання помітно скорочує час завантаження сторінки на з’єднаннях з високою затримкою

Типи сертифікатів і що вони насправді захищають

Не всі SSL/TLS-сертифікати є рівнозначними. Вибір неправильного типу — поширена операційна помилка.

Перевірка домену (DV)

Видається протягом кількох хвилин автоматизованими системами (наприклад, Let’s Encrypt). Підтверджує, що власник сертифіката контролює DNS домену або вебсервер. Забезпечує повне шифрування, але жодної перевірки ідентичності організації, що стоїть за доменом. Підходить для блогів, особистих проєктів та внутрішніх інструментів.

Перевірка організації (OV)

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

Розширена перевірка (EV)

Найсуворіший процес перевірки. Історично відображав зелений адресний рядок із назвою компанії в браузерах; сучасні браузери зменшили цю візуальну відмінність, але EV-сертифікати все одно містять перевірену інформацію про юридичну особу в самому сертифікаті. Підходить для фінансових установ та електронної комерції з високою цінністю.

Wildcard-сертифікати

Один сертифікат охоплює домен і всі його піддомени першого рівня (*.example.com). Важливе застереження: wildcard не охоплює піддомени другого рівня (*.sub.example.com потребує окремого wildcard). Компрометація приватного ключа wildcard одночасно розкриває всі піддомени — значний радіус ураження.

Багатодоменні сертифікати (SAN)

Subject Alternative Names (SAN) дозволяють одному сертифікату охоплювати кілька різних доменів (example.com, example.net, shop.example.org). Ідеально підходить для хостингових середовищ, що керують кількома ресурсами з одного сервера.

Чому HTTPS є обов’язковим у 2025 році

Шифрування конфіденційних даних

Без TLS кожен пакет між користувачем і вашим сервером проходить через потенційно ворожу мережеву інфраструктуру — публічні точки доступу Wi-Fi, прозорі проксі-сервери провайдерів та маршрути, захоплені через BGP-hijacking. Облікові дані, сесійні токени, платіжні дані та дані форм — усе це відкритий текст, який легко перехопити за допомогою таких інструментів, як Wireshark. HTTPS повністю усуває цю поверхню атаки.

Автентифікована ідентичність сервера

Ланцюжок довіри сертифікатів запобігає атакам підміни DNS та ARP-отруєння, які могли б непомітно перенаправити користувачів на шахрайський сервер. Коли браузер перевіряє сертифікат, він підтверджує три речі: сертифікат підписаний CA зі сховища довірених, доменне ім’я відповідає полям CN або SAN сертифіката, а сертифікат не прострочений і не відкликаний (перевіряється через OCSP або CRL).

Цілісність даних через AEAD-шифри

Сучасні набори шифрів TLS використовують автентифіковане шифрування з асоційованими даними (AEAD) — зокрема AES-256-GCM або ChaCha20-Poly1305. Вони забезпечують як конфіденційність, так і цілісність в одній операції. Будь-яка спроба зміни бітів або ін’єкції під час передачі призводить до збою перевірки MAC, і з’єднання негайно розривається. Це запобігає атакам ін’єкції контенту, коли провайдери або зловмисні посередники вставляють рекламу, скрипти відстеження або шкідливе програмне забезпечення у HTTP-відповіді.

SEO та сигнали ранжування

Google підтвердив HTTPS як сигнал ранжування у 2014 році і поступово збільшував його вагу. Окрім прямого фактора ранжування, попередження Chrome «Не захищено» на HTTP-сторінках помітно збільшує показник відмов — поведінковий сигнал, який опосередковано знижує позиції. HTTP/2 і HTTP/3 (QUIC), що забезпечують значне покращення продуктивності, потребують TLS у всіх основних реалізаціях браузерів. Швидші сторінки ранжуються краще; HTTPS є передумовою.

HSTS та попереднє завантаження

HTTP Strict Transport Security (заголовок Strict-Transport-Security) інструктує браузери відхиляти всі HTTP-з’єднання з доменом протягом зазначеного періоду max-age, навіть до того, як відбудеться перенаправлення. Подання вашого домену до списку попереднього завантаження HSTS жорстко кодує цю поведінку в бінарні файли браузера, повністю усуваючи вразливість вікна першого відвідування.

Впровадження HTTPS: покрокове керівництво виробничого рівня

Крок 1: Отримайте SSL/TLS-сертифікат

Let’s Encrypt (безкоштовний, автоматизований) є стандартним вибором для більшості розгортань. Certbot — це еталонний ACME-клієнт:

sudo apt update && sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d example.com -d www.example.com

Для Apache:

sudo apt install certbot python3-certbot-apache -y
sudo certbot --apache -d example.com -d www.example.com

Certbot автоматично змінює конфігурацію вашого віртуального хоста та налаштовує завдання cron або таймер systemd для поновлення. Сертифікати Let’s Encrypt закінчуються через 90 днів; автоматичне поновлення запускається кожні 60 днів за замовчуванням.

Щоб перевірити поновлення без внесення змін:

sudo certbot renew --dry-run

Для виробничих середовищ, що потребують сертифікатів OV або EV, придбайте їх у комерційного CA (DigiCert, Sectigo, GlobalSign) і дотримуйтесь їхнього процесу ручного видачі. Сторінка SSL-сертифікатів AlexHost містить доступні варіанти, включаючи як DV, так і комерційні сертифікати.

Крок 2: Встановіть і налаштуйте сертифікат на вашому вебсервері

Приклад Nginx (/etc/nginx/sites-available/example.com):

server {
    listen 443 ssl http2;
    server_name example.com www.example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
    ssl_prefer_server_ciphers off;
    ssl_session_cache shared:SSL:10m;
    ssl_session_timeout 1d;
    ssl_session_tickets off;

    add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always;
    add_header X-Frame-Options DENY;
    add_header X-Content-Type-Options nosniff;

    root /var/www/example.com;
    index index.php index.html;
}

Приклад Apache (/etc/apache2/sites-available/example.com-ssl.conf):

<VirtualHost *:443>
    ServerName example.com
    ServerAlias www.example.com
    DocumentRoot /var/www/example.com

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/example.com/cert.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/example.com/privkey.pem
    SSLCertificateChainFile /etc/letsencrypt/live/example.com/chain.pem

    SSLProtocol -all +TLSv1.2 +TLSv1.3
    SSLCipherSuite HIGH:!aNULL:!MD5
    SSLHonorCipherOrder off

    Header always set Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"
</VirtualHost>

Крок 3: Примусово використовуйте HTTPS з постійним перенаправленням 301

Nginx — додайте окремий блок сервера:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Apache — у .htaccess або HTTP-віртуальному хості:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]

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

Крок 4: Усуньте змішаний контент

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

Виявлення: Відкрийте Chrome DevTools (F12), перейдіть на вкладку Console і шукайте попередження Mixed Content. Або скористайтеся інструментом SSL Labs Mixed Content Checker або why-no-padlock.com.

Стратегії вирішення:

• Оновіть жорстко закодовані URL http:// у базі даних вашої CMS за допомогою інструменту пошуку та заміни (наприклад, wp-cli search-replace 'http://example.com' 'https://example.com' для WordPress)
• Встановіть заголовок Content-Security-Policy: upgrade-insecure-requests як тимчасовий захід, поки ви виправляєте джерела
• Перевірте сторонні вбудовування — якщо постачальник не підтримує HTTPS, замініть або видаліть вбудовування

Крок 5: Перевірте вашу конфігурацію

# Test certificate chain and expiry
openssl s_client -connect example.com:443 -servername example.com < /dev/null

# Check TLS protocol versions and cipher suites
nmap --script ssl-enum-ciphers -p 443 example.com

Для комплексного зовнішнього аудиту надішліть ваш домен на SSL Labs Server Test. Рейтинг A+ вимагає:

• Лише TLS 1.2 і 1.3 (TLS 1.0 і 1.1 вимкнені)
• Відсутність слабких наборів шифрів (RC4, 3DES, експортні шифри)
• Заголовок HSTS з max-age >= 180 днів
• Відсутність проблем із ланцюжком сертифікатів (включені проміжні сертифікати)
• Увімкнено OCSP stapling

Поширені помилки та граничні випадки

Неповний ланцюжок сертифікатів — найчастіша виробнича проблема. Якщо ви встановлюєте лише кінцевий сертифікат без проміжного CA-сертифіката, більшість настільних браузерів все одно відновлять ланцюжок (вони кешують проміжні), але мобільні браузери, API-клієнти та curl зазнають збою з SSL_ERROR_RX_RECORD_TOO_LONG або unable to get local issuer certificate. Завжди використовуйте fullchain.pem (Let’s Encrypt) або об’єднуйте кінцевий + проміжний для інших CA.

OCSP stapling зменшує затримку рукостискання та покращує конфіденційність, оскільки сервер кешує та обслуговує відповідь OCSP, замість того щоб вимагати від браузера звернення до OCSP-відповідача CA. Без stapling кожне TLS-рукостискання ініціює сторонній HTTP-запит, додаючи 50–200 мс затримки на холодних з’єднаннях. Увімкніть його в Nginx за допомогою ssl_stapling on; ssl_stapling_verify on;.

Безпека приватного ключа часто ігнорується. Файл приватного ключа повинен належати root, бути доступним для читання лише процесом вебсервера та зберігатися з правами chmod 600. Ніколи не додавайте приватні ключі до системи контролю версій. На спільній інфраструктурі використовуйте апаратні модулі безпеки (HSM) або системи управління секретами (HashiCorp Vault, AWS Secrets Manager) для зберігання ключів.

Відкликання wildcard-сертифіката має непропорційно великий вплив. Якщо приватний ключ wildcard скомпрометований і сертифікат відкликано, всі піддомени одночасно втрачають HTTPS. Для середовищ з високим рівнем безпеки надавайте перевагу сертифікатам для окремих піддоменів, автоматизованим через ACME DNS-01 challenges.

Завершення TLS на балансувальнику навантаження — поширена архітектура, де TLS розшифровується на межі (балансувальник навантаження, CDN, зворотний проксі), а трафік передається всередині мережі у незашифрованому вигляді. Це прийнятно лише якщо внутрішня мережа повністю довірена та ізольована. Для регульованих середовищ (PCI-DSS, HIPAA) потрібне наскрізне шифрування — повторне шифрування трафіку між балансувальником навантаження та серверами бекенду.

HTTPS на інфраструктурі AlexHost

У середовищі VPS Хостингу у вас є повний root-доступ для встановлення Certbot, безпосереднього налаштування Nginx або Apache та впровадження посилених параметрів TLS, описаних вище. Це рекомендований шлях для виробничих навантажень, що потребують користувацьких наборів шифрів, попереднього завантаження HSTS та OCSP stapling.

Для користувачів Спільного вебхостингу сертифікати Let’s Encrypt зазвичай доступні через панель управління з одноклікним встановленням, що автоматично обробляє видачу та поновлення сертифікатів без SSH-доступу.

Якщо ви керуєте кількома доменами або ведете реселерську діяльність, VPS з cPanel надає графічний інтерфейс для управління SSL на всіх розміщених доменах, включаючи AutoSSL для автоматичного надання Let’s Encrypt.

Для розгортань електронної комерції, що обробляють платіжні дані, поєднання HTTPS з комерційним сертифікатом OV або EV від SSL-сертифікатів забезпечує перевірку ідентичності організації, яку DV-сертифікати не можуть запропонувати — що актуально для аудитів відповідності PCI-DSS.

Якщо ваша інфраструктура включає транзакційну або маркетингову електронну пошту, зверніть увагу, що HTTPS і SMTP/IMAP TLS — це окремі питання. Захист вашої вебприсутності не захищає автоматично вашу поштову інфраструктуру; для цього потрібне окреме налаштування TLS на вашому стеку Email Хостингу.

Матриця рішень і технічний контрольний список

Використовуйте цей контрольний список перед тим, як вважати міграцію на HTTPS завершеною:

Сертифікат

• [ ] Сертифікат виданий довіреним CA (перевірте за допомогою openssl verify)
• [ ] Встановлено повний ланцюжок сертифікатів (кінцевий + проміжні)
• [ ] Сертифікат охоплює всі обслуговувані домени/піддомени (перевірте SAN)
• [ ] Налаштовано моніторинг терміну дії (сповіщення за 30 і 7 днів)
• [ ] Автоматичне поновлення перевірено за допомогою --dry-run

Конфігурація сервера

• [ ] TLS 1.0 і 1.1 явно вимкнені
• [ ] TLS 1.3 увімкнено
• [ ] Видалено слабкі набори шифрів (RC4, 3DES, NULL, EXPORT)
• [ ] OCSP stapling увімкнено та перевірено
• [ ] ssl_session_tickets off (запобігає проблемам ротації ключів сесійних квитків)

Рівень застосунку

• [ ] Усі внутрішні посилання використовують відносні URL або https://
• [ ] Відсутні попередження про змішаний контент у консолі браузера
• [ ] Встановлено заголовок Content-Security-Policy: upgrade-insecure-requests
• [ ] Перенаправлення 301 з HTTP на HTTPS для всіх імен хостів

Заголовки безпеки

• [ ] Заголовок Strict-Transport-Security з max-age >= 31536000
• [ ] Додано директиву includeSubDomains (після перевірки, що всі піддомени підтримують HTTPS)
• [ ] Домен поданий до списку попереднього завантаження HSTS (необов’язково, але рекомендовано)

Перевірка

• [ ] SSL Labs Server Test повертає A або A+
• [ ] openssl s_client підтверджує правильний ланцюжок сертифікатів
• [ ] Підтверджено активність cron/таймера systemd для поновлення

Часті запитання

Чи захищає HTTPS від усіх типів кібератак?

Ні. HTTPS шифрує транспортний рівень і автентифікує сервер, але не захищає від вразливостей на рівні застосунку (SQL-ін’єкція, XSS, CSRF), скомпрометованого серверного коду або атак, спрямованих на пристрій автентифікованого користувача. Фішинговий сайт може отримати дійсний DV-сертифікат і відображати значок замка — HTTPS підтверджує, що з’єднання зашифроване, а не те, що сайт є надійним.

Який вплив на продуктивність має увімкнення HTTPS?

З TLS 1.3 і HTTP/2 накладні витрати є незначними на сучасному обладнанні. TLS-рукостискання додає один додатковий цикл передачі при першому з’єднанні (нуль при відновленні з сесійними квитками або 0-RTT). Апаратне прискорення AES-NI, доступне практично на всіх серверних CPU з 2010 року, обробляє симетричне шифрування на лінійній швидкості. На практиці HTTPS-сайти часто завантажуються швидше, ніж їхні HTTP-аналоги, оскільки мультиплексування HTTP/2 і стиснення заголовків — які потребують TLS у браузерах — переважують вартість рукостискання.

Що відбувається, коли SSL/TLS-сертифікат закінчується?

Браузери негайно відображають попередження на весь екран, що блокує доступ до сайту. API-клієнти та мобільні застосунки зазвичай зазнають збою з жорсткою помилкою, а не попередженням. Пошукові роботи можуть продовжувати індексувати сайт, але позначатимуть помилку сертифіката. Автоматичне поновлення через Certbot або ACME запобігає закінченню терміну дії; критична операційна вимога — переконатися, що завдання cron або таймер systemd для поновлення запущені та налаштовані сповіщення про поновлення.

У чому різниця між TLS і SSL?

SSL (Secure Sockets Layer) — це попередній протокол, версії 2.0 і 3.0 якого зараз застаріли та заборонені RFC 7568 через критичні вразливості (POODLE, DROWN). TLS (Transport Layer Security) — це наступник, причому TLS 1.2 (RFC 5246) і TLS 1.3 (RFC 8446) є єдиними версіями, що вважаються безпечними. Термін «SSL-сертифікат» зберігається в розмовній мові, але фактичний протокол, що використовується на будь-якому сучасному сервері, — це TLS. Налаштування сервера для дозволу SSLv3 є неправильною конфігурацією, а не функцією сумісності.

Чи можу я використовувати HTTPS на домені, яким я не володію?

Ні. Центри сертифікації перевіряють контроль над доменом перед видачею. Протокол ACME (що використовується Let’s Encrypt) вимагає від вас або розмістити певний файл за відомим HTTP-шляхом (HTTP-01 challenge), або створити певний DNS TXT-запис (DNS-01 challenge), щоб довести контроль. Без проходження одного з цих викликів жоден сертифікат не буде виданий для домену, яким ви не керуєте.