Как государство пыталось в HTTPS, но не осилило25.06.2021 14:17

В этом году мы начали использовать в рамках проекта «Монитор госсайтов» новую методику оценки реализации поддержки на веб-сайтах госорганов протокола HTTPS, каждый критерий которой был формализован и описан. Впервые мы опробовали ее при исследовании сайтов госуслуг, а теперь применили в ежегодном исследовании сайтов государственных органов Российской Федерации. Критерии разбиты на пять групп:

Минимальные (Группа Г): несоответствие хотя бы одному из них означает, что сайт не может считаться поддерживающим защищенное соединение. Критерия в этой группе всего два: веб-сервер должен отвечать кодом состояния HTTP 200 или 301 при обращении к нему с идентификатором протокола HTTPS по 443 порту, и должен передавать клиенту действительный TLS-сертификат.

Если с соответствием первому критерию все оказалось просто — либо да, либо нет, то со вторым включилась «троичная логика» — да/нет/может быть. «Может быть» тут означает, что если к сайту обращаются по одному имени хоста, то «да», а если добавить в адрес поддомен www, то упс, забыли про такой вариант при заказе сертификата «нет», или наоборот. На этом засыпались сайты Минобороны (к настоящему времени сертификат уже досрочно перевыпущен) и ФСИН, а на сайте Ростехнадзора оказался просто недействительный сертификат (от другого хоста).

Таким образом, 4% исследованных сайтов не осилили базовые нормы ГТО HTTPS, а 22% сайтов даже не притворялись, что поддерживают его. При этом 15% исследованных сайтов принадлежат федеральным органам исполнительной власти (ФОИВ), которые поддерживать HTTPS обязаны.

Базовые (Группа В): несоответствие хотя бы одному из них означает, что сайт только формально поддерживает защищенное соединение, которое фактически может оказаться незащищенным. В этой группе уже шесть критериев, объединенных лозунгом »2021 год на дворе»: требуется отсутствие на веб-сервере серьезных уязвимостей с идентификатором CVE, отключение TLS-компрессии, поддержка де-факто стандартных расширений TLS и т.д.

Все сайты справились только с двумя критериями — параметрами TLS-сертификата и отключенной TLS-компрессией. Из дневника наблюдений за госсайтами: 100% используют TLS-сертификат, подписанный по алгоритму RSA, и ни один по ECDSA.

Минфин, Росреестр и Росстандарт не слышали про расширение Fallback SCSV. В МИД, Росреестре, Росалкогольрегулировании, Росстандарте и Центробанке не знают, что в 2021 году пересогласование бывает только безопасным. Минэкономразвития, Росреестр, Росздравнадзор, Роснедра и ФСС не знают, какой сегодня год — их сайты светят в Интернет незакрытыми уязвимостями чуть не десятилетней давности.

Сайты Минэкономразвития и Росздравнадзора предлагают посетителям с NCSA Mosaic под Windows 1.0 использовать шифронабор RSA_WITH_RC4_128_MD5 при соединении по протоколу TLS версии 1.2. Роснедра, видимо, считают, что OpenSSL Padding Oracle — это что-то про открытость информации, а не «дыру» на веб-сервере. ФСС и Росреестр, похоже, не догадываются, что »2014» в CVE-2014–3566 (POODLE) — год обнаружения и описания уязвимости, а ПО надо хотя бы иногда обновлять (Росреестр, судя по идентификатору веб-сервера, сидит на сборке Apache от 2010 года).

Почти половина (47%) администраторов госсайтов не слышала про расширение Extended Master Secret, которое получило статус RFC еще в далеком (для остальных 53%) 2015 году.

Итого, еще 52% исследованных госсайтов не смогли перешагнуть даже достаточно скромные рамки группы Г.

Рекомендуемые (Группа Б): соответствие каждому из них требуется для того, чтобы считать поддержку защищенного соединения удовлетворительной. Здесь семь критериев и тоже ничего сверхъестественного: поддержка только HTTPS, TLS 1.2 и выше, AEAD шифронаборов, устойчивые параметры протокола DH и т.п.

Все справились только с поддержкой TLS 1.2 и стандартных эллиптических кривых. 12% не справились с требованиями к параметрам DH («упреждающая секретность»), 15% не нашли в себе сил отказаться от поддержки HTTP, 37% не поддерживают AEAD шифронаборы, 36% не смогли задать им приоритет перед слабыми шифронаборами и у 15% возникла та же проблема при задании приоритета стандартных эллиптических кривых перед какими-нибудь sect283k1 или sect409r1 (кому вообще Росстандарт предлагает для согласования эти кривые?)

На этом этапе из гонки выбыли еще 15% госсайтов.

Дополнительные (Группа А): соответствие им позволит обеспечить дополнительную надежность защищенного соединения. Критерии в основном несложные: правильно передается цепочка TLS-сертификатов, поддерживается Certificate Transparency, CRL/OCSP, HSTS и не поддерживаются устаревшие версии TLS, не-AEAD шифронаборы, нестандартные эллиптические кривые. Вопрос пары команд в консоли, а сертификат без CT или OCSP сегодня еще пойди получи.

Так никто и не получил «непрозрачный» сертификат — центры сертификации свое дело знают, но когда дело дошло до поработать ручками самим и поправить конфиги веб-серверов…

35% госсайтов оказались не в состоянии передать правильную цепочку TLS-сертификатов — включают в нее «якорь», не передают промежуточные сертификаты и т.д. 69% не осилили заголовок HSTS — вообще не передают его, передают неправильный или неполный. Особенно обидно должно быть Минсельхозу — если бы не это, его сайт стал бы единственным попавшим в группу А.

18% сайтов наряду со стандартными эллиптическими кривыми готовы предложить своим посетителям экзотику, например, brainpoolP512r1 или sect283k1. Уважаемые разработчики nginx, отключите, пожалуйста, все кривые по умолчанию, а то госсектор сам не может разобраться, чем secp256r1 отличается от brainpoolP256r1 или secp256k1, и на всякий случай оставляет их все (для тех, кто не погружен в тему — это разные кривые, у которых лишь название похожее).

57% сайтов поддерживают не-AEAD шифронаборы (хотя, как мы показали ранее, сегодня в этом нет практического смысла, как и в поддержке TLS версий ниже 1.2, не говоря уже об SSL). Впрочем, тут следует оговориться, что мы рассматриваем как соответствие критерию поддержку только определенных шифронаборов, которые реально используются сегодня, так что поддержка какого-нибудь ECDHE_ECDSA_WITH_CAMELLIA_256_GCM_SHA384 нашим критериям не соответствует, т.к. это AEAD, но никем реально не поддерживается.

47% сайтов не могут расстаться с TLS 1.0 и 1.1 (а Росреестр и ФСС — с SSL), даже несмотря на то, что IETF наконец закопал признал их устаревшими, а производители всех популярных браузеров еще раньше отказались от их поддержки.

Увы, с критериями группы А не справился уже никто и лишь 6 (7%) сайтов смогли оказаться в группе Б, давайте поздравим победителей: Минсельхоз, МВД, МЧС, Росархив, Минобрнауки и Росимущество.

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

Ни один сайт не поддерживает CAA и только безопасные эллиптические кривые. Впрочем, последнему критерию соответствуют лишь Curve25519 и Curve448, обе они поддерживаются только современными версиями браузеров, поэтому выполнять этот критерий в настоящее время не рекомендуется из соображений доступности сайта.

10% сайтов поддерживают DNSSEC, 6% — OCSP stapling, но ни один из них не требует «сшивания» TLS-сертификата с ответом УЦ о его статусе (OCSP must staple). 5% поддерживают TLS версии 1.3, но никто не поддерживает Encrypted ClientHello (ECH). И лишь сайты Минтранса и Росстата передают своим посетителям HTTP-заголовок Content Security Policy с директивой upgrade-insecure-requests.

Итого, сайты 22% государственных органов Российской Федерации не поддерживают HTTPS, хотя 15% обязаны поддерживать, поскольку являются сайтами ФОИВ. Еще 56% притворяются, что поддерживают HTTPS, но делают это лишь формально. То есть, приемлемый уровень защиты соединения своим посетителям обеспечивают менее четверти сайтов, через которые распространяется информация о деятельности государственных органов, подаются документы в эти органы, передаются персональные данные и прочая чувствительная информация.

Я все еще скептически смотрю на возможность построения аналога Великого китайского файрвола этими людьми, а вы?