Как Яндекс Браузер проверяет сертификаты НУЦ на сайтах российских банков

После недавнего массового отзыва зарубежных TLS-сертификатов возникла странная для обычного пользователя картина. Сайт настоящего российского банка в Chrome или Safari показывает ошибку доверия, а Яндекс Браузер открывает тот же адрес без предупреждений. Со стороны легко решить, что Яндекс просто «отключил проверку сертификатов» или безоговорочно доверяет государственному удостоверяющему центру. Механизм устроен сложнее.

Яндекс Браузер действительно доверяет российскому Национальному удостоверяющему центру, но отдельной цепочкой внутри браузера. При этом обычная проверка TLS никуда не исчезает. Браузер проверяет доменное имя, срок действия, подписи в цепочке и доверенный корень, а для сертификатов НУЦ добавляет проверку Certificate Transparency. На распознанных страницах банков и платёжных систем сверху работает ещё один слой, защищённый режим Нейропротекта.

Что именно браузер проверяет при открытии банка

TLS-сертификат часто называют «сертификатом шифрования», хотя формулировка упрощает реальную схему. Сертификат прежде всего связывает доменное имя с открытым ключом и позволяет браузеру проверить подлинность сервера. Сеансовые ключи современный TLS обычно получает отдельно во время рукопожатия.

Типичная цепочка выглядит примерно так.

сайт банка
     ↓
 сертификат сайта
     ↓
 выпускающий удостоверяющий центр
     ↓
 Russian Trusted Root CA

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

Ошибка ERR_CERT_AUTHORITY_INVALID в другом браузере поэтому сама по себе не доказывает взлом. Код означает, что программа не смогла построить цепочку до доверенного ей удостоверяющего центра. Во время недавних проблем с российскими банками причиной часто становился переход на НУЦ после отзыва сертификатов GlobalSign. Почему подобная ошибка возникает и как отличить проблему с российским корнем от настоящей подмены сайта, я уже разбирал отдельно.

Здесь есть принципиальный нюанс. Поддержка НУЦ в Яндекс Браузере не означает автоматическую установку Russian Trusted Root CA в системное хранилище Windows. Яндекс отдельно подтверждал, что установка и обновление браузера не меняют системный список доверенных сертификатов. Российская цепочка поддерживается внутри самого браузера.

Разница существенная. Если пользователь вручную добавляет новый корень в операционную систему, область доверия может распространиться на другие программы, которые используют системное хранилище. Встроенная поддержка Яндекс Браузера ограничивает дополнительную модель доверия самим браузером. Конкретное поведение других приложений всё равно зависит от операционной системы и их собственной реализации проверки сертификатов.

Отдельно не стоит смешивать сертификаты НУЦ и ГОСТ. Национальный сертификат сайта не означает автоматически, что банковский трафик шифруется российскими криптографическими алгоритмами. Инфраструктура НУЦ предусматривает разные криптографические варианты, а обычные сайты могут работать поверх стандартного TLS. Поддержка ГОСТ в браузере относится к отдельному сценарию и может требовать специального криптографического ПО.

Правовой статус самой системы тоже изменился. НУЦ и его сертификаты получили отдельное закрепление в российском законодательстве, причём часть новых требований вводится поэтапно. Для пользователя браузера юридическая конструкция не отменяет техническую модель PKI. Сервер всё равно должен предъявить сертификат, а браузер должен проверить его по заданным правилам.

Зачем Яндексу Certificate Transparency

Самая интересная часть схемы начинается после вопроса «доверяем ли мы Russian Trusted Root CA». Если просто добавить государственный корень в список доверенных и принимать любой подписанный им сертификат, безопасность целиком зависит от работы удостоверяющего центра.

Яндекс добавил ещё одно условие. Сертификаты НУЦ должны проходить через систему Certificate Transparency, или CT, журнал прозрачности сертификатов. Текущая политика браузера прямо связывает доверие сертификатам НУЦ с публичными CT-журналами.

Работает механизм примерно так. Перед выдачей сертификат или его предварительная версия отправляется в CT-журнал. Журнал возвращает криптографически подписанную метку Signed Certificate Timestamp, SCT. Такая метка подтверждает, что журнал принял сертификат и обязался добавить запись в публичное дерево.

НУЦ
  ↓
 предварительный сертификат
  ↓
 CT-журнал
  ↓
 SCT
  ↓
 сертификат сайта
  ↓
 Яндекс Браузер проверяет SCT

В текущей политике есть конкретное требование, которое легко пропустить. Сейчас Яндекс Браузер доверяет сертификатам, содержащим одну SCT из CT-журнала Яндекса. В документации уже описан более строгий будущий вариант, при котором понадобятся две метки, одна из доверенного списка и одна из журнала Яндекса. Поэтому писать, что сегодняшний браузер обязательно требует две независимые SCT, было бы неправильно.

Сам браузер при такой проверке не обязан обращаться к CT-журналу через интернет и спрашивать «есть ли там сертификат этого банка». SCT содержит подпись журнала, а браузер знает открытый ключ журнала и может проверить подпись локально. Для самой криптографической проверки SCT постоянный запрос к серверу журнала не нужен.

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

Но здесь появляется один из главных мифов вокруг Certificate Transparency. CT не гарантирует, что удостоверяющий центр никогда не выпустит неправильный сертификат. Центр теоретически способен ошибочно или намеренно выпустить сертификат для чужого домена. CT делает выпуск заметным и создаёт криптографический след. Браузер дополнительно может отказаться принимать сертификат без требуемой SCT.

Другими словами, CT превращает потенциально скрытую выдачу сертификата в наблюдаемое событие. Защита сильная, но не магическая.

Есть любопытная техническая деталь. В опубликованном Яндексом патче для Chromium присутствовал замороженный список ранних доменов, для которых оставили исключение из обязательной CT-проверки при первоначальном внедрении российских сертификатов. В самом коде прямо указано, что последующие сертификаты должны содержать SCT. Такой исторический механизм полезен для понимания эволюции системы, но по старому открытому патчу нельзя делать вывод, что текущая сборка браузера полностью повторяет тот же список исключений.

Что меняется именно на банковском сайте

Поддержка НУЦ и защищённый режим Яндекс Браузера решают разные задачи. Первый механизм отвечает на вопрос, можно ли доверять TLS-сертификату. Нейропротект пытается уменьшить риски уже после успешной проверки соединения.

На страницах банков и платёжных систем браузер включает более строгую проверку сертификатов. Если сертификат просрочен, недействителен или не считается доверенным, защищённый режим не запускается.

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

Корпоративный прокси, антивирус или другое защитное ПО может установить собственный корневой центр и организовать две независимые TLS-сессии.

браузер
    ↓
 TLS
    ↓
 прокси или антивирус
    ↓
 TLS
    ↓
 банк

Для операционной системы такой посредник способен выглядеть доверенным, потому что его корневой сертификат заранее добавили в хранилище. На банковской странице Яндекс Браузер относится к подобной ситуации строже и может не включить защищённый режим.

После успешной проверки Нейропротект отключает расширения браузера, оставляя разрешённые Яндексом менеджеры паролей. Логика понятна. TLS защищает данные во время передачи, но не может остановить вредоносное расширение, которое уже выполняется внутри браузера и читает страницу после расшифровки.

Поэтому значок защищённого режима означает больше, чем просто «сертификат НУЦ принят». Браузер проверил HTTPS по своим правилам и применил дополнительные ограничения для финансовой страницы. Обратное тоже верно. Если защищённый режим не включился, причиной может быть не национальный сертификат, а локальный перехват, недоверенная цепочка или другая проблема проверки.

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

Может ли НУЦ расшифровать банковский HTTPS

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

Обе формулировки слишком грубые.

Публичный корневой сертификат не содержит закрытого ключа НУЦ и сам по себе не позволяет расшифровать записанный TLS-трафик. В современных конфигурациях TLS с прямой секретностью сеансовые ключи создают клиент и сервер. Знания сертификата или даже закрытого ключа удостоверяющего центра недостаточно, чтобы взять старую запись сетевого трафика и получить из неё пароль.

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

Такой риск существует не только у НУЦ. Похожими полномочиями обладают международные публичные удостоверяющие центры, корпоративные центры сертификации и локальные системы HTTPS-перехвата. Поэтому безопасность PKI строится не на предположении, что доверенный центр технически бессилен, а на ограничениях выпуска, защите закрытых ключей, аудите, механизмах отзыва и прозрачности сертификатов.

В схеме Яндекс Браузера CT как раз уменьшает пространство для незаметной злоупотребительной выдачи. Но я бы не называл такую систему абсолютной гарантией. Пользователь всё равно доверяет НУЦ, политике браузера, списку доверенных CT-журналов и реализации проверки.

Для меня практическая разница между двумя вариантами выглядит так. Если национальные сертификаты нужны только для нескольких банков и государственных ресурсов, отдельный браузер со встроенной поддержкой НУЦ создаёт более узкую область дополнительного доверия, чем ручное добавление нового корня в системное хранилище всего устройства.

Если хочется самостоятельно посмотреть сертификат сервера, достаточно OpenSSL.

openssl s_client 
   -connect bank.example:443 
   -servername bank.example 
   </dev/null 2>/dev/null |
 openssl x509 
   -noout 
   -subject 
   -issuer 
   -dates 
   -ext subjectAltName

Проверяю имя сайта в subjectAltName, срок действия и издателя. Наличие российского издателя объясняет ошибку неизвестного центра в браузере, который не доверяет НУЦ, но само по себе не доказывает безопасность страницы. Сначала всегда сверяю настоящий домен банка.

И ещё одна техническая ловушка. Поиск SCT только внутри текстового представления сертификата не всегда даёт полную картину. Стандарт допускает несколько способов доставки SCT, включая расширение самого сертификата и данные TLS. Поэтому отсутствие знакомой строки в выводе одной команды OpenSSL ещё не доказывает, что браузер не получил корректную метку.

В итоге Яндекс Браузер не просто «разрешает сертификаты Минцифры». Браузер добавляет собственную точку доверия к НУЦ, не меняя системное хранилище при установке, применяет обычные проверки X.509 и TLS, требует для новых сертификатов подтверждение через Certificate Transparency и отдельно усиливает контроль на финансовых страницах.

Главная граница такой модели проходит не между «российским» и «иностранным» сертификатом. В любой PKI приходится отвечать на три вопроса. Кто имеет право подтвердить принадлежность домена, насколько широко браузер распространяет такое доверие и можно ли обнаружить неправильную выдачу сертификата. У Яндекс Браузера на третий вопрос есть вполне технический ответ в виде CT. На первые два ответа по-прежнему зависят от того, кому пользователь готов доверять.