Правильная настройка 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 — это контроль, который можно точно измерить, поэтому измеряйте его по расписанию и оповещайте о регрессии.