Правильне налаштування HTTPS/TLS у 2026 році

Правильний TLS — це вже давно не «наявність замочка». У 2026 році захищене розгортання HTTPS означає видалення застарілих версій протоколу, прив'язку до сучасних наборів шифрів із forward secrecy та поєднання транспортного рівня з HTTP-заголовками, які зупиняють атаки downgrade і mixed-content. Цей посібник спирається на рекомендації Mozilla Server Side TLS та NIST SP 800-52 Rev. 2 і написаний так, щоб його можна було вставити прямо в задачу з хардингу.

Вимкніть TLS 1.0 і 1.1 — та більшість баласту TLS 1.2

TLS 1.0 і 1.1 офіційно визнані застарілими в RFC 8996 з 2021 року. Вони спираються на конструкції MD5/SHA-1 у PRF і допускають набори шифрів (RC4, CBC з неявними IV), вразливі до BEAST, POODLE (CVE-2014-3566) та Lucky 13. PCI DSS забороняє їх уже багато років, а всі основні браузери прибрали підтримку у 2020 році. Не залишилося аргументу про сумісність, вартого цього ризику: клієнт, що не підтримує TLS 1.2, не підтримує й сучасну веб-криптографію взагалі.

Вашою базою має бути TLS 1.2 як мінімум і TLS 1.3 як бажаний. NIST SP 800-52r2 вимагає підтримки TLS 1.2 і рекомендує TLS 1.3. Профіль «Intermediate» від Mozilla націлений саме на цю пару; профіль «Modern» — лише TLS 1.3 і доречний, коли ви контролюєте базу клієнтів (внутрішні API, мобільні застосунки).

Надавайте перевагу TLS 1.3

TLS 1.3 (RFC 8446) — не дрібна ревізія, він видаляє цілий клас небезпечних опцій. Статичний обмін ключами RSA зник, тому forward secrecy є обов'язковим. Прибрано renegotiation, стиснення (що закриває CRIME) та застарілі набори CBC. Рукостискання займає один раунд (1-RTT), з опціональним 0-RTT для відновлення, і здебільшого зашифроване. Дозволені набори AEAD — це фактично TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384 і TLS_CHACHA20_POLY1305_SHA256. Якщо робити щось одне — увімкнення TLS 1.3 дає найбільший приріст безпеки.

Forward secrecy і вибір шифрів

У TLS 1.2 потрібно явно обрати ефемерний обмін ключами: надавайте перевагу ECDHE (крива X25519 або secp256r1) з AES-GCM чи ChaCha20-Poly1305. Вимкніть статичний RSA, за можливості всі набори CBC і все з RC4, 3DES або експортними параметрами. Forward secrecy гарантує, що майбутня компрометація приватного ключа сервера не дозволить розшифрувати вчорашній перехоплений трафік — пряма протидія супротивникам типу «harvest now, decrypt later».

• Сертифікати: ключі ECDSA P-256 менші й швидші за RSA-2048; віддавайте обидва, якщо потрібна широка сумісність.
• Розмір ключа: мінімум RSA 2048 біт, ECDSA 256 біт, згідно з NIST 800-52r2.
• Криві: пропонуйте спершу X25519, потім secp256r1.

HSTS і preloading

HTTP Strict Transport Security (RFC 6797) наказує браузерам з'єднуватися лише через HTTPS, зриваючи MITM-атаки SSL-stripping, наприклад за допомогою sslstrip. Продакшн-заголовок виглядає так:

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

Використовуйте дворічний max-age. Додавайте includeSubDomains лише коли впевнені, що кожен субдомен віддає HTTPS, бо це абсолютно. Токен preload разом із поданням на hstspreload.org вшиває домен у вбудований список HSTS браузера, захищаючи навіть найперший візит. Preload практично постійний і повільно скасовується, тож вважайте його дверима в один бік і спершу все протестуйте.

OCSP stapling

Традиційна перевірка відкликання сертифікатів розкриває CA відвідувані сайти й додає затримку. OCSP stapling (розширення TLS Certificate Status Request) змушує сервер отримати й закешувати підписану CA, позначену часом OCSP-відповідь і додати її до рукостискання. Клієнт отримує свіжий доказ відкликання без додаткового з'єднання. Увімкніть його (ssl_stapling on у nginx) і поєднайте з OCSP Must-Staple на сертифікаті, якщо ваш CA це підтримує — тоді відсутність staple стає жорсткою помилкою, закриваючи прогалину soft-fail, через яку класичний OCSP був майже марним.

Усуньте mixed content

Сторінка HTTPS, що завантажує скрипт, стиль або iframe через HTTP, — це активний mixed content; браузери його блокують, і правильно, бо він повертає саме той ризик ін'єкції, який усував HTTPS. Пасивний mixed content (зображення, медіа) блокується або авто-підвищується. Виправте в джерелі, а потім примусьте:

• Content-Security-Policy: upgrade-insecure-requests автоматично переписує URL підресурсів із http:// на https://.
• Додайте block-all-mixed-content як жорсткий запобіжник для того, що не можна підвищити.

Заголовки, що завершують захист

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

• Content-Security-Policy — основний захист від XSS (OWASP A03:2021 – Injection). Почніть із політики report-only, потім примусьте політику скриптів на основі nonce/hash.
• X-Content-Type-Options: nosniff — зупиняє вгадування MIME-типу.
• Referrer-Policy: strict-origin-when-cross-origin — запобігає витоку повних URL між сайтами.
• Cross-Origin-Opener-Policy і Cross-Origin-Resource-Policy — ізолюють контекст перегляду й пом'якшують побічні канали класу Spectre.
• Встановіть прапорці Secure і HttpOnly плюс SameSite на кожній сесійній cookie.

Зверніть увагу, що X-Frame-Options сьогодні замінений директивою frame-ancestors з CSP для захисту від clickjacking; під час міграції надсилайте обидва.

Перевіряйте, а не припускайте

Конфігурація дрейфує. Перевіряйте кожну зміну в SSL Labs Server Test (цільтеся в A+), Mozilla Observatory та testssl.sh у CI. Підтверджуйте мінімальну версію протоколу через nmap --script ssl-enum-ciphers. Зіставляйте результати з OWASP ASVS V9 (Комунікації), щоб докази потрапляли в аудиторський слід. TLS — це контроль, який можна точно виміряти, тож вимірюйте його за розкладом і сповіщайте про регресію.