TLS / SSL

Почему 'SSL' до сих пор используют, хотя это устарело

SSL расшифровывается как Secure Sockets Layer, а TLS как Transport Layer Security.

SSL, оригинальный протокол, имеет известные уязвимости и формально устарел уже много лет. TLS является его современной заменой, но термин "SSL" по привычке сохраняется в повседневном использовании, названиях сертификатов и продуктов.

Что реально нужно проверять, а не только устанавливать

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

Версии TLS, шифры и настройки сертификата разобраны здесь: руководство по безопасности nginx.

Проверка работающего сервера из командной строки

Что сервер действительно предъявляет клиентам, можно посмотреть командой openssl s_client. Подставьте вместо example.com свой домен и запускайте её с другой машины:

openssl s_client -connect example.com:443 -servername example.com -brief </dev/null
openssl s_client -connect example.com:443 -servername example.com -showcerts -verify_return_error </dev/null
nmap --script ssl-enum-ciphers -p 443 example.com

Параметры описаны в руководстве по s_client. -servername задаёт имя SNI, что важно, когда один IP-адрес обслуживает несколько сертификатов. -brief выводит краткую сводку, включая согласованный протокол, а -showcerts показывает все сертификаты, которые отправляет сервер, так что можно убедиться в наличии промежуточного сертификата. -verify_return_error прерывает рукопожатие при проблеме проверки, а не игнорирует её.

Чтобы убедиться, что старые версии протокола отклоняются, не полагайтесь на принудительный -tls1_1 со своей машины: современный клиент OpenSSL может сам отказаться от этой версии, и неудача ничего не докажет о сервере. Скрипт ssl-enum-ciphers перебирает наборы шифров и перечисляет то, что сервер действительно принимает. Это интрузивный скрипт, поэтому запускайте его только против собственных серверов. RFC 8996 прямо указывает, что TLS 1.0 и 1.1 использовать нельзя.

Продление, срок действия и забытый reload

Проблемы с сертификатами обычно эксплуатационные, а не криптографические: продление тихо не удалось или удалось, но веб-сервер продолжает отдавать старый файл. Составные части есть в документации Certbot. certbot certificates показывает установленные сертификаты, certbot renew --dry-run проверяет продление на тестовом сервере Let's Encrypt, ничего не сохраняя, а deploy hook запускается только после успешного продления:

sudo certbot certificates
sudo certbot renew --dry-run
sudo certbot renew --deploy-hook "systemctl reload nginx"

echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null \
  | openssl x509 -noout -enddate -checkend 1209600

nginx читает сертификаты при загрузке конфигурации, а reload запускает новые рабочие процессы с новой конфигурацией, как описано в документации по управлению nginx. Hook надёжно обеспечивает этот шаг. Последняя команда печатает дату окончания срока, а по руководству по x509 ключ -checkend завершается с ненулевым кодом, если сертификат истекает в течение заданного числа секунд (1209600 это 14 дней), так что на него можно повесить оповещение из cron. Более короткие сроки жизни делают такой мониторинг важнее, см. 45-дневные сертификаты Let's Encrypt и руководство по безопасности nginx.

Связанные термины: nginx, Security headers, WAF, ssl_protocols, HSTS (строгая транспортная безопасность HTTP).

В новостях: Let's Encrypt постепенно отказывается от 90-дневных сертификатов в пользу 45-дневных и 6-дневных, и это изменение способно сломать автоматизацию продления, рассчитанную на фиксированный интервал.