SSLLabs Server Test как инструмент аудита: ни одного клиентского сервера ниже B

После апрельского Heartbleed и волны перевыпуска сертификатов наступил момент, когда можно было поднять голову и посмотреть на TLS-конфигурацию в целом - не только «закрыт ли Heartbleed», а вообще «как у нас дела с SSL». Мы решили прогнать все публичные эндпоинты клиентов через Qualys SSL Server Test и зафиксировать картину. Спойлер: картина была так себе.

Инструмент и методология

Qualys SSL Labs - бесплатный веб-сервис, который сканирует публичный HTTPS-хост и выставляет оценку от A до F. Он проверяет поддерживаемые протоколы, cipher suite, цепочку сертификатов, наличие forward secrecy, HSTS, OCSP stapling и несколько десятков других параметров. Результат - не просто буква, а подробный отчёт, где видно, что именно потянуло оценку вниз.

CIS Benchmarks для веб-серверов - другой ориентир: там конкретные директивы для nginx, Apache, IIS с объяснением, почему то или иное значение считается безопасным. Эти два инструмента хорошо дополняют друг друга: SSLLabs показывает снаружи как клиент, CIS Benchmarks говорит что настраивать внутри.

Мы провели аудит по всем клиентам с публичными HTTPS-эндпоинтами. Правило одно: ни одного сервера ниже B. Perfect Forward Secrecy - обязателен.

Что обнаружилось

Результаты разбились на несколько характерных паттернов.

Оценка C и ниже из-за SSLv3. Сюрприза нет - об этом мы писали ещё в мае. Но одно дело писать, другое - смотреть на красную плашку в отчёте SSLLabs у клиентского сервера. Несколько хостов, которые считались «обновлёнными после Heartbleed», SSLv3 так и не отключили. Патч поставили, сервис перезапустили, а в конфиге SSLv3 остался.

Отсутствие Forward Secrecy. Это самый частый повод для оценки B вместо A. Если cipher suite не включает ECDHE или DHE - сессионные ключи не уникальны для каждого соединения, и записанный трафик можно расшифровать позже, если приватный ключ когда-нибудь окажется в чужих руках. После Heartbleed эта угроза перестала быть абстрактной.

Слабые DH-параметры. Несколько серверов падали в оценке именно здесь: DHE включён, но с параметрами 1024 бит. SSLLabs это видит и снижает. Починка простая - сгенерировать 2048-битный dhparam.pem и прописать в конфиг, но об этом нужно знать заранее.

Отсутствие HSTS. Само по себе не снижает оценку ниже A, но SSLLabs его фиксирует отдельно. Без HSTS браузер при первом соединении идёт по HTTP и только потом редиректится на HTTPS - окно для downgrade-атаки. С HSTS - браузер знает, что этот домен только HTTPS, и не делает незащищённый запрос вообще.

RC4 в cipher suite. Встречалось реже, но встречалось. RC4 - это шифр, у которого известные структурные слабости, и SSLLabs за него снижает. Убирается одной строчкой в конфиге, но нужно знать, что убирать.

Как устроена проверка по клиентам

Методически мы делаем это так:

• Инвентаризация - собираем список всех публичных доменов и субдоменов клиента. Это важный шаг: часто оказывается, что кроме основного сайта есть staging, admin-панель, API-домен, почтовый шлюз с веб-интерфейсом - и всё это публично.
• Прогон через SSLLabs - каждый домен отдельно, сохраняем результаты. У SSLLabs есть API, так что можно автоматизировать для большого числа хостов.
• Приоритизация - серверы с C и ниже идут в работу в первую очередь, B - смотрим что тянет вниз и чиним, A- и A - документируем и закрываем.
• Повторная проверка - после изменений конфига SSLLabs кэширует результаты, принудительная проверка через &startNew=on в URL.

Конфигурационный минимум

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

ssl_protocols TLSv1.2;
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK;
ssl_prefer_server_ciphers on;
ssl_dhparam /etc/nginx/ssl/dhparam.pem;

add_header Strict-Transport-Security "max-age=31536000" always;

ssl_stapling on;
ssl_stapling_verify on;

Без ssl_dhparam DHE-шифры работают на дефолтных параметрах, и SSLLabs это видит. Файл генерируется один раз: openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048 - занимает несколько минут.

Про IIS

Отдельный разговор - клиенты на Windows Server с IIS. Там настройка TLS делается не через конфиг веб-сервера, а через реестр (или через утилиту IIS Crypto, которая делает то же самое с нормальным GUI). CIS Benchmark для Windows Server конкретно описывает, какие ключи реестра должны быть выставлены. IIS по умолчанию до сих пор разрешает SSLv3 - это нужно отключать руками.

Где мы сейчас

По состоянию на сегодня: все клиентские серверы, которые мы успели пройти, - минимум B, большинство A или A-. Несколько хостов ещё в очереди - там согласование с клиентом по поводу возможного влияния на совместимость со старыми клиентами.

Forward Secrecy везде, где разрешают протоколы. HSTS - там, где нет смешанного HTTP/HTTPS-контента. OCSP Stapling - где настроена цепочка CA.

Это не финальное состояние - SSLLabs периодически обновляет критерии оценки по мере появления новых данных о слабостях. Так что периодически гонять проверку заново - имеет смысл.