TLS Handshake: Почему правильная настройка — основа вашей безопасности

Когда вы вводите адрес сайта в браузер, начинается невидимая работа. Браузер и сервер обмениваются данными, чтобы создать защищённый канал. Это TLS handshake. Он длится доли секунды, но решает, насколько безопасна вся дальнейшая связь.

В NameOcean мы уверены: разработчики и админы должны разбираться в таких вещах. Это не только повышает навыки. Неправильная настройка TLS открывает дверь хакерам и приводит к проблемам с compliance. А это время, деньги и репутация.

Как проходит TLS handshake?

Клиент начинает: отправляет серверу список поддерживаемых протоколов, cipher suites и своих возможностей. Сервер выбирает вариант, присылает сертификат для подтверждения личности.

В TLS 1.3 всё улаживается за один round trip. В TLS 1.2 нужно два. Разница небольшая, но в эпоху скорости TLS 1.3 выигрывает.

Handshake генерирует ephemeral keys — временные ключи для сессии. Они шифруют трафик и удаляются после. Это forward secrecy. Даже если приватный ключ сервера взломают позже, старые сессии останутся недоступны.

Проблема версий: TLS 1.2 — минимум, TLS 1.3 — идеал

Многие серверы всё ещё тянут TLS 1.0 и 1.1. Эти версии устарели, их сломали атаки вроде BEAST и POODLE. Браузеры их отвергли, PCI DSS, HIPAA и SOC 2 запрещают.

Legacy-системы тормозят обновления. Если вы принимаете старые версии — рискуете и провалите аудит.

Рекомендация: TLS 1.2 с сильными cipher suites как база. TLS 1.3 — лучшее. Там убрали слабые опции, минимизировали ошибки.

Cipher Suites: Выбираем надёжное шифрование

После выбора версии определяют cipher suite — набор алгоритмов для шифрования.

В TLS 1.3 выбор фиксирован и безопасен. Не о чем думать.

Для TLS 1.2 смотрите:

• Key Exchange: ECDHE для forward secrecy. RSA без неё.
• Encryption: AES-GCM или ChaCha20. Избегайте CBC, RC4, DES, 3DES.
• Hashing: SHA-256 или SHA-384.

Пример для Nginx:

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
ssl_prefer_server_ciphers on;

В Apache меняйте SSLProtocol и SSLCipherSuite. Главное — конкретность и современность.

Certificate Chains: Частая ошибка

Сайт работает в Chrome, но ломается в старых приложениях? Проблема в цепочке сертификатов.

Сертификат — это цепь от вашего leaf до root CA. Если сервер шлёт только leaf, браузеры достанут остальное. Старые клиенты — нет.

Решение: скачайте intermediates от CA и настройте сервер на полную цепь. Пара строк в конфиге — и готово. В продакшене без этого никуда.

TLS для compliance и доверия

Compliance — не помеха, а минимум. Если TLS 1.0 всё ещё открыт, ждите штрафов и потери доверия.

Forward secrecy, сильные cipher suites, свежие версии — обязательны.

Как часто проверять TLS?

После каждого изменения и раз в месяц. Обновления сервера, ротация сертификатов, правки конфига — всё может сбить настройки.

Автоматизируйте проверки. Не ждите инцидента.

TLS — только начало

Хороший TLS — фундамент. Добавьте HSTS, CSP, X-Frame-Options. Полная защита включает auth, API, hardening.

Регулярный аудит всего стека — ключ к безопасности сайта или API.

Итог

TLS handshake работает незаметно, как и должна инфраструктура. Разберитесь в нём, обновляйте, проверяйте регулярно. Так пользователи в безопасности, а аудиторы спокойны.

В NameOcean мы создали инструменты для анализа и мониторинга TLS. Безопасность должна быть простой.