Сертификаты Минцифры: почему "доверие по умолчанию" может стать проблемой
То, чего многие скорее опасались, чем ждали, уже стало реальностью: заметная часть российских сайтов и онлайн‑сервисов начала переезжать на сертификаты Минцифры. Для пользователей это вылилось в очень приземлённые симптомы - привычные страницы внезапно перестают открываться по HTTPS, браузер показывает предупреждения о невозможности проверить подлинность ресурса, а некоторые приложения, которые годами работали "как часы", начинают сбоить.
Причины у компаний разные, но итог один. У кого‑то не получилось продлить прежний сертификат, у кого‑то сертификат отозвали, а где‑то выпуск новых стал фактически недоступен или слишком сложен. Поскольку HTTPS давно превратился в де‑факто стандарт, любая "дырка" в цепочке доверия мгновенно бьёт по доступности сервиса и по бизнесу. На этом фоне и появляется массовый переход на сертификаты Минцифры для бизнеса - как способ вернуть работоспособность, пусть и ценой изменения модели доверия.
Как выглядит выбор пользователя на практике
Если упростить картину до бытового уровня, вариантов обычно три:
1) добавить корневые и промежуточные сертификаты Минцифры в систему - и "всё снова работает" в привычных браузерах;
2) установить Яндекс.Браузер, где нужные сертификаты уже встроены - и "всё снова работает" без ручных действий;
3) ничего не делать - и остаться без части сервисов.
Каждый вариант неприятный по‑своему. Отказаться от сервисов - грустно и часто невозможно. Пересаживаться на отдельный браузер, который имеет широкий доступ к системе и пользовательским данным, тоже не всем комфортно. А режим "два браузера на все случаи жизни" быстро превращается в хроническое неудобство: где‑то открывать личные кабинеты, где‑то платежи, где‑то рабочие панели - и постоянно помнить, в каком именно окружении это делать.
Наиболее "логичным" кажется решение "просто поставить корневой сертификат": тогда остаётся привычный браузер, а сайты с новым выпуском начинают открываться. Но именно здесь возникает главный вопрос - кому именно вы расширяете доверие на своём устройстве.
Где начинается недоверие: цепочка, которая делает MITM реалистичным
Опасность не в том, что конкретный сайт "плохой". Опасность в том, что добавление нового корневого центра сертификации меняет правила игры для всего TLS‑трафика на устройстве. Сценарий, который в тексте описывается почти как конструктор, выглядит так:
- Минцифры подписывает сертификат для условной структуры вроде "ФГУП мониторинга и защиты интернета", причём в сертификате указано CA:true - то есть это удостоверяющий центр, который может выпускать другие сертификаты.
- Далее появляется оборудование и софт для фильтрации и перехвата соединений: комплекс, который умеет завершать TLS‑сессии на своих серверах (терминация), читать содержимое и затем устанавливать новое TLS‑соединение "дальше".
- Для подмены сертификатов на лету используются полномочия того самого CA‑сертификата.
- А поскольку корневой сертификат Минцифры уже добавлен в доверенные на компьютере/телефоне, браузер воспринимает сгенерированные "поддельные, но правильно подписанные" сертификаты как настоящие.
На выходе получается классическая атака man‑in‑the‑middle: третья сторона может незаметно прочитать ваши сессии, включая токены, идентификаторы, куки, данные аутентификации и всё, что проходит внутри TLS.
Модель угрозы: зачем это вообще нужно третьей стороне
Чтобы понять, почему точка боли именно здесь, полезно разложить мотивацию по шагам.
- Третья сторона хочет получить доступ к данным.
- Она действует в российской юрисдикции и, если нужно, может запросить сведения у российских компаний - с высокой вероятностью эти данные будут предоставлены.
- При этом доступ к данным у компаний вне российской юрисдикции ограничен или как минимум сложнее.
- Пользователи, понимая это, условно делят данные на те, которые "не жалко" держать в российском контуре, и те, которые предпочли бы оставлять за его пределами.
- Тогда логичный ход - поставить оборудование на линии связи между пользователем и зарубежными ресурсами и вмешиваться в трафик так, чтобы пользователь без специальных проверок ничего не заметил.
- После такого вмешательства можно получить аутентификационные артефакты (токены, сессионные идентификаторы и т. п.) и использовать их для доступа к данным уже на стороне внешних сервисов.
Ключевой момент: для доступа к данным внутри российской юрисдикции "сложный перехват TLS" часто вообще не обязателен - достаточно правовых и административных механизмов. А вот для тихого доступа к данным "снаружи" незаметное вмешательство в TLS‑сессии становится принципиально важным. Именно поэтому критическая точка - возможность перехвата без предупреждений браузера.
Что меняется для компаний: удобство, цена и ответственность
Для бизнеса переход на новые сертификаты выглядит как прагматичная мера: вернуть HTTPS и перестать терять пользователей. На практике же возникает целый пласт организационных вопросов: кто отвечает за выпуск, как устроена ротация, как контролировать доверенную цепочку, что делать с мобильными приложениями и старыми клиентами.
Компании, которые планируют купить сертификат минцифры для сайта, часто упираются не столько в сам факт получения, сколько в дальнейшую эксплуатацию: регламенты, аудит, контроль конфигурации, журналирование, своевременная замена. И даже если стоимость сертификата минцифры на бумаге выглядит приемлемо, итоговый бюджет обычно формируется вокруг внедрения и сопровождения - особенно если инфраструктура распределённая или высоконагруженная.
Технически же "галочка" в виде HTTPS - это только верхушка. Куда важнее корректная настройка сертификата минцифры на сервере: цепочки промежуточных сертификатов, совместимость с клиентами, жёсткие параметры TLS, HSTS, и аккуратная работа с прокси/балансировщиками. Ошибка в одном звене - и пользователи снова видят предупреждения или сталкиваются с отказом соединения.
Новые абзацы: как снизить риски пользователю и администратору
Пользователю, который не хочет расширять доверие "на всю систему", стоит хотя бы осознавать разницу между установкой сертификата в ОС и использованием отдельного браузера/профиля. Установка в систему влияет на все приложения, которые используют системное хранилище доверенных CA, - то есть потенциально на почту, мессенджеры, корпоративные клиенты, инструменты разработчика. Это гораздо шире, чем "чтобы открылся один сайт".
Компромиссный подход - разделение контуров: отдельное устройство для "российского контура" и отдельное для работы с чувствительными данными вне него, либо хотя бы разные профили/браузеры с минимальным пересечением учётных записей. Да, неудобно, но это честная цена за попытку удержать границы доверия.
Администраторам полезно заранее продумать коммуникацию с пользователями. Если вы планируете установку сертификата минцифры на сайт, подготовьте понятные инструкции: что изменится, какие браузеры и ОС поддерживаются, как выглядят предупреждения и что пользователь должен (и не должен) делать. Чем меньше паники и "советов из чатов", тем ниже шанс, что люди начнут бездумно добавлять любые сертификаты, которые им пришлют.
Наконец, стоит помнить: доверие к корневому сертификату - это не про один домен, а про потенциальную возможность выпуска сертификатов "для чего угодно" в рамках доверенной цепочки. Поэтому любое решение, связанное с добавлением нового CA, - это всегда управленческий выбор и изменение модели угрозы, а не просто "починка HTTPS". Более развёрнуто эти риски и логика их появления обсуждаются в материале про сертификаты Минцифры и доверие к ним - там хорошо видно, почему точка уязвимости находится именно в незаметном вмешательстве в TLS.
В сухом остатке проблема не в том, что "всё сломалось", а в том, что "починилось" ценой расширения доверия. И если для части сервисов это действительно единственный способ восстановить доступность, то пользователю и бизнесу важно хотя бы понимать, на какие последствия они соглашаются - и где именно появляется окно для перехвата, которое раньше закрывалось глобальной инфраструктурой публичных удостоверяющих центров.