Что реально стоит за так называемыми «сертификатами безопасности» Минцифры: техническое досье, риски и проверка тезисов
Этап 1. Доступ к файлам и сбор улик
Первое препятствие — на официальной странице сертификаты нельзя скачать прямой ссылкой: кнопка запускает минифицированный скрипт и скрывает конечный адрес. Чтобы понять, что именно отдается пользователю, был написан короткий пользовательский скрипт, перехватывающий событие клика и логирующий URL. Анализ минифицированного JavaScript показал встроенные прямые пути к архивам с сертификатами. После распаковки получаем набор корневых и промежуточных сертификатов, рассортированных по семействам алгоритмов.
Этап 2. Деобфускация и первичная инвентаризация
Минифицированный код представлял собой одну строку с вызовами функций и строковыми литералами. Быстрая развертка через форматирование и поиск по фрагментам имен переменных позволила выделить места, где формируются URL. Дальше — обычная рутина: скачать архивы, распаковать, проверить структуры директорий и именование файлов, убедиться, что набор покрывает как минимум две криптографические ветки — на базе RSA и на базе отечественных ГОСТ-алгоритмов.
Этап 3. Разведопрос сертификатов
Интересующие поля каждого файла: Subject (на чье имя выдан), Issuer (кем подписан), сроки действия, а также X509v3 Extensions — это сердце полномочий сертификата. Через стандартные средства командной строки выводим все расширения: Basic Constraints, Key Usage, Extended Key Usage, Subject Alternative Name, Authority Information Access, CRL Distribution Points и пр. Ключевое: Basic Constraints указывает, что сертификаты являются CA и могут выпускать подчиненные сертификаты; Key Usage включает ключевые операции для подписания промежуточных и серверных сертификатов; Extended Key Usage допускает Server Authentication. Промежуточные — корректно подписаны корнем; цепочки собираются.
Этап 4. Структура инфраструктуры и промежуточные выводы
Имеем две полноценные PKI-иерархии: одна на RSA, другая — на ГОСТ. Обе технически валидны, снабжены нужными расширениями и пригодны для выпуска сертификатов практически для любого доменного имени. То есть это не «узкоспециализированные» сертификаты, ограниченные одним доменом либо организацией — это доверенные корни, которые, попав в системное хранилище, становятся верховным авторитетом для браузера и ОС. Любой TLS-сеанс, для которого выдан подчиненный сертификат от этой иерархии, будет принят как нормальный и безопасный.
Что это означает на практике
- Устанавливая такой корень в системное хранилище, пользователь безоговорочно доверяет владельцу УЦ: он может легитимно выпускать поддельные (с точки зрения адресата) серверные сертификаты для любых сайтов.
- Если трафик проходит через инфраструктуру, контролируемую владельцем такого УЦ или доверенной ему стороной, расшифровка HTTPS становится тривиальной: браузер не выдаст предупреждений, цепочка будет валидной, иконка замка — «зеленой».
- Типовая защита браузеров, когда подмененный сертификат вызывает ошибку соединения, здесь не сработает: подмена станет «легальной» из-за доверенного корня.
- На промежуточном узле можно прочитать все: логины, пароли, токены, содержимое личных переписок, финансовые данные, файлы, передаваемые по HTTPS.
Почему HSTS, pinning и «современный веб» не спасают
- HSTS защищает от даунгрейда на HTTP и некоторых видов подмены, но не от валидной цепочки до нового доверенного корня.
- Традиционный HPKP давно де-факто не используется браузерами из-за рисков неремонтируемых блокировок; его заменила идея прозрачности сертификатов и механизмов мониторинга.
- Certificate Transparency помогает отслеживать выдачу сертификатов публичными УЦ, но если корень невключен в общедоступные реестры либо действует в локальной модели, мониторинг затруднен. Пользователь не видит отклонений — цепочка легитимна.
Где и как хранится доверие
- Windows использует системное хранилище корней; большинство браузеров доверяют ему, за исключением некоторых, у которых есть собственное хранилище.
- На macOS и iOS доверие централизовано через Keychain; изменение статуса корня влияет на все приложения.
- На Android все зависит от версии: пользовательские корни могут помечаться как недоверенные для приложений, но браузеры часто продолжают их принимать; корпоративные профили MDM добавляют системные корни.
- На Linux доверие задается набором пакетов и каталогов системных CA; браузеры могут иметь собственную копию доверенных корней либо использовать NSS/OS-хранилища.
ГОСТ против международных алгоритмов: вопрос доверия не только к УЦ, но и к криптографии
С RSA, ECDSA и AES все относительно прозрачно: алгоритмы десятилетиями подвергались публичному криптоанализу, имплементации проходят независимые аудиты. В случае ГОСТ-алгоритмов экспертиза более локальна, спецификации и реализации исторически оценивались ограниченным кругом организаций. Это не означает автоматическую уязвимость, но расширяет поверхность неопределенности: пользователю приходится доверять не только владельцу УЦ, но и устойчивости применяемых схем, качеству генераторов случайных чисел, корректности библиотек и маршрутам сертификации.
Чем опасна централизованная точка доверия
- Единственная организация получает техническую возможность быть «внутри» любого зашифрованного канала пользователей, которые добавили ее корень.
- Любая компрометация приватного ключа корневого или промежуточного УЦ масштабируется катастрофически: отзывать и переустанавливать корни сложно, а пользователи часто этого не делают.
- Надежность CRL и OCSP критична. Но даже идеальный отзыв не спасает постфактум: весь ранее перехваченный и записанный трафик, если использована статическая эпhemerality или скомпрометирован сервер, может быть расшифрован.
Сравнение с корпоративными TLS‑шлюзами
Во многих компаниях практикуют перехват TLS на прокси для DLP/IDS/антивируса. Ключевое отличие — прозрачность и ограничение области действия: пользователи информированы, политика закреплена документально, корень распространяется только внутри периметра, цели строго регламентированы, ведется аудит. В публичном масштабе, когда установка сертификата предлагается широким слоям пользователей, такие организационные компенсаторы либо отсутствуют, либо пользователь о них не знает, а значит — риск и асимметрия информационной власти растут.
Разбор официальных тезисов
Тезис 1: «Без наших сертификатов вы не защищены»
Техническая реальность: HTTPS сам по себе обеспечивает конфиденциальность и целостность между клиентом и сервером, если в цепочке используются публично доверенные УЦ. Дополнительный корневой сертификат от третьей стороны не улучшает защиту пользователя, а лишь расширяет круг акторов, способных расшифровывать трафик. Иными словами, уровень защиты без «дополнительного корня» не ниже, а зачастую выше с точки зрения приватности.
Тезис 2: «Механизм работы идентичен зарубежным»
Частично верно на уровне механики X.509: любой доверенный корень технически способен выпускать подчиненные сертификаты. Но экосистема публичных УЦ ограничена жесткими базовыми требованиями, аудитами, прозрачностью выдачи (журналы CT), правилами отзывов, независимым надзором со стороны вендоров ОС и браузеров. Без сопоставимых процедур подотчетности и открытого мониторинга утверждение про «идентичность» некорректно по сути: одинаковая форма не означает равный уровень гарантий.
Тезис 3: «Используйте определенный браузер, если другие ругаются»
Если один браузер предупреждает о проблеме с цепочкой, а другой молчит — это индикатор различий в политиках доверия и хранилищах корней. Рекомендация просто сменить браузер фактически предлагает игнорировать сигнал безопасности. Корректный путь — понять причину предупреждения и устранить ее, а не подавлять.
Какие угрозы становятся возможными
- Непрозрачный MitM для любых сайтов, включая почту, мессенджеры в вебе, интернет-банкинг и корпоративные панели.
- Подмена загрузок программ и обновлений, если обновление проверяет только TLS-цепочку без дополнительной подписи.
- Точечная модификация контента на лету: внедрение скриптов, скрытая телеметрия, изменение результатов поиска.
- Пост- и предиктивная деанонимизация пользователей за счет корреляции расшифрованных сеансов.
Как понять, что ваш трафик перехватывается «законно»
- Откройте информацию о сертификате конкретного сайта в браузере и посмотрите Issuer. Если это не привычный международный УЦ, а имя, связанное с установленным локальным корнем — соединение терминируется посредником.
- Сравните отпечатки сертификатов одного и того же сайта с разных сетей/устройств. Разные отпечатки при коротком интервале времени — тревожный признак.
- Проверьте системное хранилище доверенных корней: появление новых записей без вашего ведома — повод для расследования.
Как снизить риски, если установка уже произведена
- Извлеките сертификат из доверенных корней для конечных пользователей, оставив его, при необходимости, только в выделенной виртуальной машине или отдельном профиле.
- Разделите рабочие и приватные задачи: для финансов и личной переписки используйте среду, где дополнительные корни не задействованы.
- Включите двуфакторную аутентификацию во всех сервисах, чтобы кража пароля не приводила к взлому.
- Предпочитайте приложения и обновления с дополнительной криптоподписью на уровне пакетов, а не только TLS.
- Настройте мониторинг цепочек сертификатов и алертинг на нестандартных Issuer для критичных доменов.
Юридико-организационный аспект
Наличие технической возможности перехвата — не тождественно фактическому перехвату. Но отсутствие прозрачных регламентов применения, независимого аудита и публичных отчетов повышает недоверие. В здравой модели должны существовать: четкие основания использования, узкая сфера действия, журналы событий, внешняя проверка, обязательные уведомления, механизмы отзыва и ответственность за злоупотребления. Без этих элементов пользователь не может соразмерно оценить риск.
Почему массовое доверие корню — решение с долгосрочными последствиями
Удалить сертификат из миллионов устройств трудно; многие пользователи даже не знают, что он установлен. Любая будущая утечка ключей, организационная реформа, смена подрядчиков или компрометация инфраструктуры приведут к лавинообразным рискам. Чем шире периметр доверия, тем дороже ошибка.
Что делать разработчикам и администраторам
- Для внутренних ресурсов используйте частные УЦ, ограниченные контурами, и не смешивайте их с пользовательскими окружениями.
- Подписывайте артефакты независимыми схемами (например, подпись пакетов и двоичных файлов), чтобы целостность не зависела от одного TLS.
- Для мобильных приложений внедряйте привязку сертификатов или ключей на уровне приложения, учитывая механизмы обновления и ротации.
- Используйте журналирование и аттестацию TLS-концентраторов, если перехват неизбежен в корпоративной среде.
Итоги
Технический анализ показал: перед нами полноценные корневые УЦ (RSA и ГОСТ), способные выпускать сертификаты для любых доменов. Их установка в систему означает передачу права незаметного расшифрования всего вашего HTTPS-трафика владельцу инфраструктуры или любому, кто получит доступ к ее ключам. Заявления о «необходимости для защиты» не подтверждаются криптографической реальностью: стандартный HTTPS без дополнительных корней уже обеспечивает требуемую безопасность соединений. Установка же «добавочного доверия» увеличивает поверхность риска, перекладывая баланс контроля с пользователя на внешнего субъекта.
Вывод простой: доверие к корневому сертификату — это не галочка в инструкции, а стратегическое решение уровня «кому я позволяю читать мой трафик при идеальных условиях для него». Примите его осознанно, с пониманием технических механизмов, организационных гарантий и последствий на годы вперед.
