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

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

Проще говоря, сегодня правильно настроенный браузер должен отказываться устанавливать защищенное соединение с этим сервером, чтобы не вводить своего пользователя в заблуждения относительно уровня его «защищенности», но SSL Server Test от Qualys видит лишь «отдельные недостатки», а по версии ImmuniWeb SSL Security Test, до идеала не хватает лишь поддержки TLS 1.3. Все дело в их методиках оценки.

SSL Server Test от Qualys оценивает результаты сканирования по собственной методике – SSL Server Rating Guide, последние изменения в которую, судя по журналу изменений, вносились еще в начале 2020 года. Нельзя сказать, что из-за этого методика стала сегодня неактуальной: она была такой изначально из-за стандартов, на которые опирается.

Во-первых, это безымянные, но очевидно антикварные «требования FIPS» восьмилетней давности, во-вторых – NIST SP 800-57 Part 3 в редакции 2009 года, которая была признана устаревшей еще в 2015 году, и наконец – PCI DSS в редакции 3.«побойтесь Диффи – Хеллмана».1 (с тех пор вышло уже 3,5 новых редакции).

Как итог – тест Qualys хоть и помечает шифронабор TLS_RSA_WITH_AES_128_CBC_SHA как слабый, присваивает поддерживающему его веб-серверу высший (по своей методике) рейтинг надежности. Более того, такой рейтинг получает веб-сервер, не поддерживающий вообще ни одного устойчивого (AEAD) шифронабора. (На правах рекламы: наша методика не позволяет получить подобному веб-серверу рейтинг выше В).

И наконец, SSL Server Test не проверяет поддержку веб-сервером расширения Extended Master Secret, без которого TLS-соединение с сервером уязвимо к атаке трехстороннего рукопожатия.

На этом фоне выигрышно смотрится ImmuniWeb SSL Security Test, который полагается на устаревшую, но все же не ископаемую редакцию PCI DSS – 3.2.1, HIPAA (принятый в 1996 году, но не устанавливающий собственных требований к настройкам TLS) и NIST SP 800-52 (в неизвестной редакции, но предположим, что в актуальной – второй).

Увы, выигрышно этот сканер только смотрится, так как помечает шифронабор TLS_RSA_WITH_AES_128_CBC_SHA как «хорошая конфигурация» и также присваивает поддерживающему его веб-серверу рейтинг А+.

Для тех, кто давно не интересовался ~~новостями~~ баянами криптографии: 3 из 4 используемых в данном шифронаборе криптографических алгоритма ~~сегодня~~ уже не первый год признаны слабыми, недостаточно надежными или просто «дырявыми»: RSA (для согласования ключей), CBC и SHA (не путать с SHA256 и SHA384).

Напомню, что мы рассматриваем ситуацию по состоянию на 2023 год в той вселенной, где в 2005 году АНБ опубликовало Suite B Cryptography, а в 2009 году Инженерный совет Интернета – RFC 5430 Suite B Profile for Transport Layer Security, которые уже тогда требовали от уважающих ~~себя~~ своих посетителей веб-серверов поддержки TLS 1.2 с AEAD шифронаборами, и которые, в свою очередь, уже не первый год как заменены более актуальными (читай – строгими) стандартами.

Разумеется, этими двумя сканерами «рынок» не ограничивается, но… но Mozilla Observatory и Online Domain Tools не умеют обрабатывать «двуногие» TLS-сертификаты и потому считают сертификаты Let's Encrypt недействительными. Internet.nl и Wormly показывают лишь основные настройки сервера (а бес, как известно, кроется в деталях). Имеющий репутацию придиры (в хорошем смысле) Hardenize не видит большой проблемы в поддержке все того же шифронабора TLS_RSA_WITH_AES_128_CBC_SHA (возможно потому, что сам его поддерживает). При этом Hardenize отмечает проблемы нашего подопытного сервера с упреждающей секретностью (forward secrecy) но не объясняет, в чем они заключаются.

С импортозамещением в рассматриваемой области тоже не задалось. «Открытый сервис аудита безопасности и корректности настроек интернет‑узлов» от ТЦИ пребывает в перманентном состоянии «беты» (хотя по возможностям и не уступает некоторым готовым продуктам), а «Бесплатная онлайн проверка TLS/SSL сервера и сайта» на самом деле лишь «обертка» к небезызвестному testssl.sh, да и то регулярно глючит или вовсе не работает.

Кто виноват?

Стандарты, а вернее их отсутствие. Ни один из вышеупомянутых стандартов не является стандартом безопасности веб-сервера. HIPAA устанавливает общие требования к обработке медицинской информации, в т.ч. в «бумажной» форме, и не говорит ничего конкретного про настройку веб-серверов. PCI DSS – стандарт безопасности данных для индустрии платежных карт, который устанавливает нормы в т.ч. для банкоматов, выпущенных в прошлом веке, которые никто не станет менять, пока они не рассыплются в пыль, а ~~стрелять себе в ногу~~ объявлять их небезопасными разработчики стандарта не готовы из ~~чистого и бескорыстного гуманизма~~ объяснимого желания не быть посланными подальше со стандартом, который никто не может соблюсти.

И даже NIST SP 800-52 даже в последней на сегодня редакции 2 – это стандарт не для веб-серверов, тем более публичных, а для вообще всех правительственных информационных систем США, который распространяется как на новенькие планшеты, так и мейнфреймы, на которых еще при Рейгане моделировали ядерную войну с СССР, и которые имеют все шансы доработать до ее начала. Вся эта инфраструктура должна как-то (хотя бы относительно) безопасно коммуницировать между собой, например, защищая соединение шифронабором TLS_DH_RSA_WITH_AES_128_CBC_SHA, который NIST SP 800-52r2 считает нормальным для 2023 года с учетом вышесказанного.

Не удивительно, что NIST SP 800-52r2 «разрешает» и использование шифронабора TLS_RSA_WITH_AES_128_CBC_SHA, однако с оговоркой, что это нежелательно и допустимо лишь в тех случаях, когда выбора нет. В случае защищенного соединения «публичный веб-сервер – браузер» выбор есть давно, однако Qualys и ImmuniWeb при разработке своих методик пропустили оговорку NIST мимо ушей.

Что делать?

1. Смотреть не на рейтинг, присвоенный веб-серверу TLS-сканером, а на «сырые» результаты сканирования. Поддержка только AEAD шифронаборов на публичном веб-сервере – это правильно, даже если его итоговый рейтинг низкий (что, несомненно, сигнализирует о каких-то других недостатках).

2. Проверять свой сервер несколькими TLS-сканерами, поскольку ни один (известный мне) публичный сканер не показывает картину полностью. Наиболее полные данные по настройкам TLS веб-сервера показывает уже упомянутый testssl.sh, но его придется поднимать на локальной машине (Kali Linux в помощь).

3. Для проведения дополнительных проверок безопасности соединения веб-сервера с его посетителями стоит обратить внимание и на такие онлайн-тесты:

Есть дополнения к этому списку? Делитесь в комментариях. Лично я был бы раз узнать о веб-сервисах или запускаемых с локального ПК под Windows утилитах, которые позволяют проверить наличие поддержки Encrypted Client Hello (ECH) на веб-сервере и Subresource Integrity (SRI) на сайте.

Домашнее задание для пытливых умов

Сможете понять, почему явно лучше настроенный веб-сервер самой Qualys получает более низкий бал, чем откровенно дырявый infobridge.com.tw? Я это иначе как кривизной методики (или интерпретатора результатов сканирования) объяснить не могу.

Не все TLS-сканеры одинаково полезны