Что скрывается за «сертификатами безопасности» от Минцифры? — актуализация 2026

Что скрывается за «сертификатами безопасности» от Минцифры?

Архивное переиздание с актуализацией. Оригинал опубликован на Habr (≈2026), автор — неизвестен. оригинал доступен на Habr по состоянию на ноябрь 2026. Ниже — редакция ноября 2026: что работает сейчас, что изменилось и как правильно повторить рецепт сегодня. Полный текст оригинала — в конце, без купюр.

TL;DR — версия 2026

VLESS+REALITY (Xray) в 2026 — главный рекомендованный способ: маскировка под TLS к чужому крупному сайту, активное зондирование не проходит, домен и сертификат не нужны.

Оригинал попал в первую волну статей о VLESS+Reality — и с тех пор подход не просто выжил, а стал стандартом: фактическим стандартом антицензурного туннелирования в 2026 стал VLESS + REALITY (Xray-core): он маскируется под обычный HTTPS-трафик к крупному сайту и не требует собственного домена и сертификата; по данным РКН, за 2025 год в России заблокировано 258 VPN-сервисов, и почти все выжившие сервисы сидят именно на Xray. Что изменилось с публикации: пару-тройку версий Xray-ядра, новые клиенты, панели 3x-ui/Marzban с автонастройкой Reality, и — увы — статья о том, как это ставить, стала легальной мишенью (российские сайты и сами хабр-авторы начали массово удалять статьи о VPN (статьи отдают HTTP 451 «удалена по юридическим причинам») — именно поэтому появляются проекты-архивы вроде этого).

Статус оригинала

• URL: https://habr.com/ru/articles/966896/
• Статус на Habr: ЖИВА
• Картинки: 9/9 сохранено локально

Клиенты и панели 2026

• клиенты: v2rayN (Windows), NekoBox/NekoRay, Hiddify (кросс), v2rayNG (Android), Streisand/Shadowrocket (iOS — ставить быстро, Apple вычищает их из стора волнами);
• панели: 3x-ui (мульти-протокол, лимиты трафика, подписки) и Marzban — обе ставятся docker-compose и закрывают тему «у меня 5 друзей»;
• подписка: ссылка vless://... превращается в QR/URL, Hiddify сам обновляет;
• проверка блокировок вокруг вашего сервера: blockcheck от ValdikSS.

Почему REALITY до сих пор непробиваем

REALITY «крадёт» рукопожатие у настоящего TLS-сайта: ваш сервер, не имея сертификата, отдаёт клиенту handshake реального target-сайта (dest), а внутри договаривается о ключах. Со стороны (DPI, активный probe) это обычный HTTPS к популярному ресурсу. Ответить probe-ом «не тем» сервер не может — нечем отличить. В 2025–2026 у операторов блокировок остаётся один приём: резать «подозрительные» IP целиком. Лечится CDN-фронтом или сменой IP.

Минимальный сервер 2026

Актуальный Xray-core (ветка 2x/25.x) — ставится официальным скриптом; ключевые поля:

"inbounds": [{
  "listen": "0.0.0.0",
  "port": 443,
  "protocol": "vless",
  "settings": {
    "clients": [{ "id": "<uuid>", "flow": "xtls-rprx-vision" }],
    "decryption": "none"
  },
  "streamSettings": {
    "security": "reality",
    "realitySettings": {
      "dest": "www.microsoft.com:443",
      "serverNames": ["www.microsoft.com"],
      "shortId": "",
      "privateKey": "<x25519>"
    }
  }
}]

Выбор dest: крупный зарубежный сайт с TLS 1.3 + H2, НЕ ваш CDN, не российский, не «за Cloudflare» (цикл). Проверка: openssl s_client -connect dest:443 с сервера должна отдавать нужный SNI.

Иллюстрации из оригинала

Что изменилось с ≈2026 года

• uTLS-фingerprint клиента теперь критичен (chrome/firefox из коробки)
• flow xtls-rprx-vision — норма; старые flow без vision уязвимы к детекту
• XHTTP-транспорт добавился как альтернатива ws/gRPC за CDN
• 3x-ui заменил большинство «костыльных» bash-панелей из статей 2023 года
• iOS-клиенты требуют зарубежный Apple ID чаще, чем в 2024

Чек-лист 2026

• dest — живой крупный сайт с TLS1.3, доступный С ВАШЕГО сервера
• shortId непустой
• uTLS fingerprint клиента совпадает с типичным браузером
• сервер не «светится» сканерами (закрыть 80/8080-заглушки)
• fallback на реальный сайт, если probe придёт без правильного SNI

Вердикт

Оригинальная статья была верной — просто Xray с тех пор обновился, панели стали удобнее, а сама тема — юридически горячей. Конфиг выше — минимальная «сегодня-работает»-версия; вся методология оригинала (x25519-ключи, SNI-подбор, проверка blockcheck) неизменна.

---

ОРИГИНАЛ СТАТЬИ (без изменений)

**2 часть статьи (обязательно к прочтению) **

Привет хабр

Я решил провести собственное небольшое расследование о так называемых «сертификатах безопасности» от Минцифры. Цель - собрать техническое досье и разобраться, почему их установка может нести потенциальные риски для безопасности данных.

Добыча улик

Первая же задача оказалась нетривиальной: на официальной странице нельзя просто скопировать ссылку на скачивание сертификата. Соответствующий пункт в контекстном меню отсутствует.

Сайт Госуслуг с кнопками скачивания

Чтобы получить прямую ссылку, я написал простой скрипт для Tampermonkey, который перехватывает событие клика и логирует URL запроса.

Скрипт доступен в репозитории: ./scripts/getlink.user.js

Скрипт показал, что кнопка не ведет на файл, а вызывает функцию из минифицированного JavaScript‑файла:

Консоль с выводом скрипта

Ссылка вела на https://gu-st.ru/landings-st/main.4978f1b2316e002d.js.

Деобфускация

Содержимое 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"

Терминал с выводом wget

Файлы успешно скачаны. Распаковываем архивы:

unzip "*.zip"

Терминал с выводом unzip

Улики собраны. Переходим к их изучению.

Анализ сертификатов

Начнем с ключевого «фигуранта» — корневого сертификата 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

Вывод команды достаточно объемен, особенно для тех, кто не работает с криптографией на ежедневной основе:

Вывод команды openssl

Полные результаты анализа на момент написания статьи сохранены в репозитории:

/certs/interrogation/root_rsa.txt

/certs/interrogation/sub_rsa.txt

.. и остальные.

Промежуточные выводы и структура

Анализ показал, что мы имеем дело с двумя полноценными иерархиями PKI (на базе RSA и ГОСТ). Обе являются технически корректными Удостоверяющими Центрами (CA) с полномочиями выпускать сертификаты для любых доменных имен.

Установка данных корневых сертификатов в системное хранилище означает полное и безоговорочное доверие их владельцу. Это технически позволяет владельцу инфраструктуры выполнять атаку «человек посередине» (MitM), при которой браузер пользователя не покажет никаких предупреждений.

Что становится возможным?

Итак, мы изучили сертификаты. Теперь главный вопрос: каковы реальные возможности владельца такого сертификата?

Если коротко: возможность легитимно дешифровать HTTPS‑трафик пользователя. Весь. С любого устройства, где установлен данный сертификат.

Обычно HTTPS защищает данные между вами и сайтом, и интернет‑провайдер видит лишь зашифрованный поток. С установленным корневым сертификатом эта защита может быть скомпрометирована.

MitM-атака как легализованная функция

В обычной ситуации при попытке перехвата трафика браузер выведет предупреждение CONNECTION_NOT_PRIVATE. Это его штатная работа — защищать пользователя от поддельных сертификатов.

С установленным корневым сертификатом Минцифры ситуация меняется. Злоумышленнику, контролирующему канал связи (например, провайдеру), даже не нужно прибегать к таким техникам, как ARP‑spoofing. Он уже находится «посередине». Сертификат лишь дает ему ключ для расшифровки трафика.

Для пользователя все выглядит штатно. Но на промежуточном узле весь трафик может быть прочитан: логины, пароли, переписки, финансовая информация.

Отдельный вопрос: криптография ГОСТ

С RSA‑сертификатами вопрос доверия сводится к доверию владельцу УЦ. С ГОСТ‑сертификатами добавляется еще один уровень — доверие самой криптографии.

Международные алгоритмы (RSA, AES) прошли десятилетия публичного аудита и криптоанализа со стороны тысяч независимых исследователей по всему миру.

Отечественные криптографические стандарты не могут похвастаться таким же уровнем открытости и независимого международного анализа.

Мы не можем утверждать о наличии или отсутствии бэкдоров в ГОСТ, но этот фактор стоит учитывать при оценке рисков.

Сравниваем официальные тезисы с технической реальностью

Давайте разберем официальные тезисы с сайта Госуслуг и сопоставим их с тем, что мы выяснили.

1. Тезис: “Без наших сертификатов вы не защищены”

Цитата: «Без сертификатов ваши личные данные недостаточно защищены, поэтому при попытке зайти на сайт появится предупреждение о небезопасности ресурса».

Реальность: Это утверждение, мягко говоря, лукавство, рассчитанное на технически неподкованного пользователя.

Почему это не так:

Любая современная ОС (Windows, macOS, Linux) поставляется с обширным набором доверенных корневых сертификатов от десятков мировых УЦ (DigiCert, Let’s Encrypt и так далее), которые прошли строгий аудит.

Эти УЦ независимы, их деятельность прозрачна, и они не были скомпрометированы выдачей сертификатов для спецслужб.

Аналогия: это как если бы управляющая компания вашего дома требовала дубликат ключей от квартиры под предлогом защиты от воров, утверждая, что ваш собственный надежный замок «недостаточно защищает».

2. Тезис: “Механизм работы идентичен зарубежным”

Цитата: «Установка сертификатов безопасна… Механизм их работы идентичен сертификатам, выпускаемым зарубежными центрами сертификации».

Реальность: Здесь мы видим сразу два спорных утверждения.

Про «безопасность»: Безопасность зависит от доверия владельцу корневого сертификата. Техническая возможность перехвата трафика, как мы показали выше, заложена в самой архитектуре PKI.

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

3. Тезис: “Используйте Яндекс.Браузер, если другие выдают ошибку”

Цитата: «В браузерах Opera, FireFox… сайты всё равно могут открываться с ошибкой. Чтобы сохранить безопасный доступ… используйте <Яндекс Браузер>.»

Реальность: Это, пожалуй, самый интересный момент. Попытка выдать штатную защитную реакцию браузера за ошибку.

Почему Firefox ведет себя иначе:

Firefox — один из немногих браузеров, использующих собственное, независимое хранилище корневых сертификатов. Он не доверяет слепо системному хранилищу, куда пользователь (или вредоносное ПО) мог добавить что угодно. Он доверяет только своему списку, курируемому Mozilla Foundation.

То, что Firefox предупреждает об опасности, — это не ошибка. Это корректная работа системы безопасности. Браузер сообщает: «Этот удостоверяющий центр мне неизвестен, и я не могу ему доверять».

Яндекс.Браузер, в свою очередь, поставляет эти сертификаты Минцифры «из коробки», поэтому и не показывает предупреждений, что по моему странно.

Итоги статьи

Угроза MitM‑атаки при установке этих сертификатов - это не страшилка.

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

Удачи, делайте собственные выводы на основе представленных фактов.

UPD: Вот недавно ТГ канал создал, там способы ускорения и обходы белых списков всякие будут, кто хочет может подписатся t.me/openlibrecommunity Поддержать нас донатом

РУБЛИ. СБП, КАРТА: pay.cloudtips.ru/p/28c476e5

КРИПТА. TON, USDT: UQD_Qc2cxLGe1P4wANi46cKdEvvzyJRrJTYPvGX2KAZDnsDh

КРИПТА, TRC 20, USDT: TYQqdACH5PrScvsMowSyS8JjaaF5wvFf5Q

КРИПТА, BTC: bc1qvw0ts0jk5e5dfj9fdez76j9ck95lqz04fpf02a