Что скрывается за «сертификатами безопасности» от Минцифры?
- вторник, 18 ноября 2025 г. в 00:00:11
Здравствуйте, уважаемые хабровчане.
Я решил провести собственное небольшое расследование о так называемых «сертификатах безопасности» от Минцифры. Цель — собрать полное техническое досье и разобраться, почему их установка может нести потенциальные риски для безопасности данных.
(Оригинал без терпения, все скрипты и файлы, упомянутые в статье, доступны в этом GitHub‑репозитории).
Первая же задача оказалась нетривиальной: на официальной странице нельзя просто скопировать ссылку на скачивание сертификата. Соответствующий пункт в контекстном меню отсутствует.

Чтобы получить прямую ссылку, я написал простой скрипт для Tampermonkey, который перехватывает событие клика и логирует URL запроса.
Скрипт доступен в репозитории: ./scripts/getlink.user.js
Скрипт показал, что кнопка не ведет на файл, а вызывает функцию из минифицированного JavaScript‑файла:

Ссылка вела на https://gu-st.ru/landings-st/main.4978f1b2316e002d.js.
Содержимое JS‑файла было ожидаемо обфусцировано и представляло собой одну строку кода.

После недолгого анализа кода удалось найти искомое — прямые ссылки на архивы с сертификатами:
https://gu-st.ru/content/lending/linux\_russian\_trusted\_root\_ca\_pem.zip
https://gu-st.ru/content/lending/russian\_trusted\_sub\_ca\_pem.zip
Примечание: Эти ссылки могут стать неактуальными со временем. Для автоматизации поиска можно использовать скрипт на Go (./scripts/deob.go). Впрочем, все необходимые файлы уже сохранены в репозитории в папке ./certs.
Скачиваем файлы с помощью wget:
# Скачиваем корневые сертификаты
wget "https://gu-st.ru/content/lending/linux\\_russian\\_trusted\\_root\\_ca\\_pem.zip"
# Скачиваем выпускающие (промежуточные) сертификаты
wget "https://gu-st.ru/content/lending/russian\\_trusted\\_sub\\_ca\\_pem.zip"

Файлы успешно скачаны. Распаковываем архивы:
unzip "*.zip"
Улики собраны. Переходим к их изучению.
Дисклеймер: Далее следует технический анализ с использованием консольных утилит.
Начнем с ключевого «фигуранта» — корневого сертификата russian_trusted_root_ca_pem.crt.
Нас интересуют три основных аспекта:
Subject — кому выдан сертификат.
Issuer — кем он подписан.
X509v3 extensions — какими полномочиями он обладает.
Для анализа воспользуемся стандартной утилитой openssl.
# Анализируем корневой RSA сертификат
openssl x509 -in russian_trusted_root_ca_pem.crt -text -noout
# Анализируем корневой ГОСТ сертификат
openssl x509 -in russian_trusted_root_ca_gost_2025_pem.crt -text -noout
# Анализируем промежуточный RSA сертификат
openssl x509 -in russian_trusted_sub_ca_pem.crt -text -noout
Вывод команды достаточно объемен, особенно для тех, кто не работает с криптографией на ежедневной основе:

Полные результаты анализа на момент написания статьи сохранены в ре��озитории:
Анализ показал, что мы имеем дело с двумя полноценными иерархиями PKI (на базе RSA и ГОСТ). Обе являются технически корректными Удостоверяющими Центрами (CA) с полномочиями выпускать сертификаты для любых доменных имен.
Установка данных корневых сертификатов в системное хранилище означает полное и безоговорочное доверие их владельцу. Это технически позволяет владельцу инфраструктуры выполнять атаку «человек посередине» (MitM), при которой браузер пользователя не покажет никаких предупреждений.
Итак, мы изучили сертификаты. Теперь главный вопрос: каковы реальные возможности владельца такого сертификата?
Если коротко: возможность легитимно дешифровать HTTPS‑трафик пользователя. Весь. С любого устройства, где установлен данный сертификат.
Обычно HTTPS защищает данные между вами и сайтом, и интернет‑провайдер видит лишь зашифрованный поток. С установленным корневым сертификатом эта защита может быть скомпрометирована.
В обычной ситуации при попытке перехвата трафика браузер выведет предупреждение CONNECTION_NOT_PRIVATE. Это его штатная работа — защищать пользователя от поддельных сертификатов.
С установленным корневым сертификатом Минцифры ситуация меняется. Злоумышленнику, контролирующему канал связи (например, провайдеру), даже не нужно прибегать к таким техникам, как ARP‑spoofing. Он уже находится «посередине». Сертификат лишь дает ему ключ для расшифровки трафика.
Для пользователя все выглядит штатно. Но на промежуточном узле весь трафик может быть прочитан: логины, пароли, переписки, финансовая информация.
С RSA‑сертификатами вопрос доверия сводится к доверию владельцу УЦ. С ГОСТ‑сертификатами добавляется еще один уровень — доверие самой криптографии.
Международные алгоритмы (RSA, AES) прошли десятилетия публичного аудита и криптоанализа со стороны тысяч независимых исследователей по всему миру.
Отечественные криптографические стандарты не могут похвастаться таким же уровнем открытости и независимого международного анализа.
Мы не можем утверждать о наличии или отсутствии бэкдоров в ГОСТ, но этот фактор стоит учитывать при оценке рисков.
Давайте разберем официальные тезисы с сайта Госуслуг и сопоставим их с тем, что мы выяснили.

Цитата: «Без сертификатов ваши личные данные недостаточно защищены, поэтому при попытке зайти на сайт появится предупреждение о небезопасности ресурса».
Реальность: Это утверждение, мягко говоря, лукавство, рассчитанное на технически неподкованного пользователя.
Почему это не так:
Любая современная ОС (Windows, macOS, Linux) поставляется с обширным набором доверенных корневых сертификатов от десятков мировых УЦ (DigiCert, Let's Encrypt и так далее), которые прошли строгий аудит.
Эти УЦ независимы, их деятельность прозрачна, и они не были скомпрометированы выдачей сертификатов для спецслужб.
Аналогия: это как если бы управляющая компания вашего дома требовала дубликат ключей от квартиры под предлогом защиты от воров, утверждая, что ваш собственный надежный замок «недостаточно защищает».

Цитата: «Установка сертификатов безопасна... Механизм их работы идентичен сертификатам, выпускаемым зарубежными центрами сертификации».
Реальность: Здесь мы видим сразу два спорных утверждения.
Про «безопасность»: Безопасность зависит от доверия владельцу корневого сертификата. Техническая возможность перехвата трафика, как мы показали выше, заложена в самой архитектуре PKI.
Про «идентичный механизм»: Механизм не идентичен. Как мы выяснили, используется две параллельные инфраструктуры: одна на общепринятом RSA, а вторая — на российском ГОСТе. Алгоритмы и стандарты в них разные.

Цитата: «В браузерах Opera, FireFox... сайты всё равно могут открываться с ошибкой. Чтобы сохранить безопасный доступ... используйте <Яндекс Браузер>.»
Реальность: Это, пожалуй, самый интересный момент. Попытка выдать штатную защитную реакцию браузера за ошибку.
Почему Firefox ведет себя иначе:
Firefox — один из немногих браузеров, использующих собственное, независимое хранилище корневых сертификатов. Он не доверяет слепо системному хранилищу, куда пользователь (или вредоносное ПО) мог добавить что угодно. Он доверяет только своему списку, курируемому Mozilla Foundation.
То, что Firefox предупреждает об опасности, — это не ошибка. Это корректная работа системы безопасности. Браузер сообщает: «Этот удостоверяющий центр мне неизвестен, и я не могу ему доверять».
Яндекс.Браузер, в свою очередь, поставляет эти сертификаты Минцифры «из коробки», поэтому и не показывает предупреждений, что по моему странно.
Угроза MitM‑атаки при установке этих сертификатов — это не гипотетическая страшилка, а техническая реальность, заложенная в саму архитектуру этой системы.
Моей задачей было собрать технические факты и показать, как эта система работает на самом деле, без маркетинговой риторики. Верить ли после этого официальным заявлениям и устанавливать ли данные сертификаты — личный выбор каждого.
RED: Комментаторы "все УЦ одинаково опасны" кому ты доверишь то что зашел на запрещеный (запрещен он только в нашей стране) ютуб? иностранному УЦ или нашему?
Моя работа здесь закончена. Ваша — сделать собственные выводы на основе представленных фактов.