Как отключить устаревшие протоколы TLS при настройке HTTPS в соответствии с требованиями?

При настройке HTTPS в соответствии с требованиями безопасности обычно отключают устаревшие версии TLS — TLS 1.0, TLS 1.1 и более ранние протоколы SSL, оставляя TLS 1.2 и включая TLS 1.3, если сервер его поддерживает. Однако соответствие требованиям также зависит от применимых базовых требований безопасности, наборов шифров, сертификатов и фактической области действия настроек. Оценивать его только по версии протокола нельзя.

Перед началом работ выясните, где именно завершается TLS-соединение браузера. Если сайт использует CDN, WAF или балансировщик нагрузки, изменение настроек только на исходном сервере может не помешать публичной точке входа по-прежнему принимать устаревшие протоколы.

Определите все точки входа HTTPS, которые нужно изменить

Веб-сайты для внешней торговли, трансграничные интернет-магазины и целевые страницы рекламных кампаний часто используют цепочку доступа «посетитель — CDN/WAF — балансировщик нагрузки — исходный сервер». Для каждого отдельного TLS-соединения на этом пути задаются собственные параметры протокола. Если промежуточное устройство только передает трафик, настройки определяет компонент на стороне сервера, который фактически завершает TLS-соединение.

Рекомендуется составить перечень доменов и портов прослушивания, а не ограничиваться проверкой количества серверов:

• Публичные точки входа: основной домен, поддомен www, многоязычные сайты, интернет-магазин, API и целевые страницы рекламных кампаний.
• Соединения с исходным сервером: HTTPS-соединения между CDN и балансировщиком нагрузки, а также между обратным прокси-сервером и сервером приложения.
• Дополнительные точки входа: адреса исходного сервера с прямым доступом, резервные домены, административные точки входа и другие HTTPS-порты.

Параметр CDN «минимальная версия TLS» обычно управляет соединением с посетителем. Протокол соединения с исходным сервером настраивается отдельно. Если для этого соединения по-прежнему используется HTTP, успешный результат публичной проверки не позволяет считать всю цепочку зашифрованной.

Укажите разрешенные протоколы в настройках

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

Пример настройки Nginx

Укажите в соответствующем контексте конфигурации:

ssl_protocols TLSv1.2 TLSv1.3;

Если для всех сайтов применяется единая политика, настройки можно централизованно задать на уровне http. Проверьте, не переопределяются ли они в отдельных блоках server. Если на одном адресе и порту размещено несколько виртуальных HTTPS-хостов, проверьте также виртуальный хост по умолчанию: конфигурация сервера по умолчанию может влиять на согласование протокола, поэтому недостаточно изменить только блок конфигурации целевого домена.

После сохранения сначала проверьте синтаксис, затем перезагрузите службу:

nginx -t
nginx -s reload

Перезагружайте службу только после успешной проверки синтаксиса. В контейнерных, кластерных и управляемых средах обновляйте конфигурацию с помощью соответствующего механизма развертывания. Убедитесь, что на всех экземплярах используется одинаковая конфигурация, чтобы часть запросов не попадала на узлы со старыми настройками.

Настройка Apache и управляемых платформ

В Apache протоколы можно ограничить с помощью директивы SSLProtocol. Например, в среде, поддерживающей соответствующие версии:

SSLProtocol -all +TLSv1.2 +TLSv1.3

Также проверьте глобальные настройки, конфигурации виртуальных хостов и их наследование. При использовании CDN, облачного балансировщика нагрузки или SaaS-платформы для создания сайтов установите минимальную версию в панели управления того сервиса, который фактически обрабатывает TLS, и отдельно проверьте соединения с посетителями и с исходным сервером.

В сценариях использования комплексных платформ для создания сайтов и маркетинга, таких как 易营宝, страницы сайта, маркетинговые домены, CDN и исходный сервер могут обслуживаться разными сторонами. До начала работ определите, кто отвечает за настройку каждой точки входа и как ее проверять. Нельзя считать, что «платформа установила сертификат» означает, что «устаревшие протоколы отключены на всех точках входа».

Проверка должна подтвердить и отказ старых, и работу новых версий

Если сайт открывается в браузере, это подтверждает лишь успешное согласование какого-либо протокола, но не отключение старых версий. Для одного и того же домена выполните рукопожатие с указанием каждой версии:

openssl s_client -connect example.com:443 -servername example.com -tls1
openssl s_client -connect example.com:443 -servername example.com -tls1_1
openssl s_client -connect example.com:443 -servername example.com -tls1_2
openssl s_client -connect example.com:443 -servername example.com -tls1_3

Замените пример домена на фактический. Ожидаемый результат: рукопожатия TLS 1.0 и TLS 1.1 не завершаются успешно, а TLS 1.2 работает. Если планируется поддержка TLS 1.3, проверьте и его успешное подключение. Параметр -servername передает SNI, чтобы запрос не попал на неверный виртуальный хост.

Ошибка при проверке старого протокола не обязательно означает, что сервер отказал в соединении. Локальная версия OpenSSL может уже запрещать старые протоколы или не иметь подходящих старых наборов шифров. Если клиент завершает работу еще до отправки сообщения рукопожатия, такой результат не доказывает, что сервер отключил протокол. Учитывайте текст ошибки и перепроверьте результат с помощью инструмента сканирования TLS, способного выполнять соответствующую проверку.

Публичный домен и исходный сервер следует проверять отдельно. При прямом подключении к исходному серверу можно заменить в -connect домен на IP-адрес исходного сервера, указав домен через -servername. Также проверьте IPv4, IPv6, резервные точки входа и разные узлы развертывания. Сохраните время проверки, целевой адрес и результат согласования протокола для приемки и последующего устранения неполадок.

Совместимость необходимо проверять на всем рабочем пути

Старые операционные системы, встроенные устройства и давно не обновлявшиеся клиенты API могут потерять возможность подключения после изменения настроек. До развертывания выявите зависимости по журналам подключений, спискам вызывающих систем и результатам бизнес-тестирования. В первую очередь проверьте отправку запросов, перенаправления на оплату, обратные вызовы заказов, интерфейсы маркетинговых данных и задачи синхронизации со сторонними системами.

Проблемы совместимости в первую очередь следует решать обновлением клиентского ПО, среды выполнения или компонентов интерфейса. Если необходим переходный период, можно рассмотреть отдельную изолированную точку входа, ограничив область доступа и установив срок ее отключения. Не открывайте старые протоколы на всем основном сайте ради одного устаревшего клиента. Во время поэтапного развертывания отслеживайте ошибки рукопожатия, сбои обратных вызовов и результаты работы критически важных форм. То, что страница открывается, еще не означает, что процессы продаж или привлечения клиентов работают корректно.

Отключение устаревших версий TLS — не единственная задача по обеспечению HTTPS. Для TLS 1.2 также нужно проверить наборы шифров. Цепочку сертификатов, соответствие сертификата домену, сроки его действия и смешанный контент необходимо проверять отдельно. Перенаправление с HTTP и HSTS выполняют собственные функции и не заменяют ограничение версий протокола. При сдаче работ сохраните перечень точек входа, действующую конфигурацию и записи о проверках. При добавлении маркетинговых доменов или переносе CDN проверяйте настройки по той же базовой политике безопасности.