9 октября 2026Команда Сарнас

Поддельные TLS-сертификаты через захват национальных доменов верхнего уровня

Захват зон .gh, .sl и .as позволил злоумышленникам получить от настоящих удостоверяющих центров TLS-сертификаты для доменов Google и других крупных брендов — без взлома самой PKI. Разбор показывает, почему подделка оказалась неотличима от легитимного сертификата и какую роль в обнаружении сыграла Certificate Transparency.

7 октября 2026 года Google сообщила о выпуске несанкционированных TLS-сертификатов для нескольких своих доменов, а также для ряда ведущих мировых брендов и популярных онлайн-сервисов. Атакующие не взламывали ни удостоверяющие центры, ни инфраструктуру владельцев доменов: они захватили контроль над тремя национальными доменами верхнего уровня — .gh, .sl и .as — и меняли DNS-записи выбранных доменов внутри этих зон.

Google не раскрыла, какие именно её домены пострадали, и не назвала другие затронутые организации. Неизвестно и точное число выпущенных сертификатов.

Что именно произошло

Атака шла в два шага. Сначала злоумышленники получили контроль над тремя ccTLD. Захват зоны верхнего уровня даёт власть над DNS-записями доменов внутри неё: именно эти записи и указывают, куда ведёт домен. Затем атакующие изменили авторитетные DNS-записи для выбранных доменов внутри этих пространств имён. Управляя этими записями, они прошли автоматические проверки подтверждения прав на домен и получили сертификаты от настоящих удостоверяющих центров.

Google подчёркивает: инцидент не включал компрометацию инфраструктуры владельцев доменов, а удостоверяющие центры соблюдали все требования. То есть формально всё было выдано по правилам — сломанным оказалось само допущение, на котором держится автоматическая проверка: что контроль над DNS-записями домена означает контроль над доменом.

Google обновила Chrome, чтобы блокировать все выявленные несанкционированные сертификаты, и связалась с выдавшими их центрами сертификации, чтобы обеспечить отзыв экземпляров, выпущенных для ресурсов Google. Пользователям Chrome, по словам компании, никаких действий предпринимать не нужно.

Как устроена цепочка доверия и почему подделка неотличима

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

Проверка подписи удостоверяющего центра выполняется в рамках проверки пути сертификации. Она проверяет связь между именем субъекта и/или альтернативным именем субъекта и открытым ключом субъекта. Имя субъекта — это то, на кого выдан сертификат, а альтернативное имя перечисляет домены, для которых он действует; именно по ним браузер понимает, что сертификат выдан для запрошенного сайта.

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

Certificate Transparency: как выпуск сертификатов становится наблюдаемым

Certificate Transparency — это экосистема для обнаружения злонамеренно или ошибочно выпущенных сертификатов. Журналы CT построены на Merkle-деревьях, они публично проверяемы, только добавляемые и защищены от подмены.

При выпуске сертификата журнал выдаёт SCT (Signed Certificate Timestamp). В её состав входят хеш публичного ключа журнала, хеш публичного ключа издателя сертификата — чтобы связать издателя с итоговым сертификатом — и предсертификата.

Хеши в дереве считаются с разделением доменов:

MTH({d(0)}) = SHA-256(0x00 || d(0))
MTH(D[n]) = SHA-256(0x01 || MTH(D[0:k]) || MTH(D[k:n]))

Разделение доменов требуется для устойчивости ко второму прообразу. Merkle audit path позволяет доказать существование листа в дереве: если корень, вычисленный по audit path, совпадает с истинным корнем, путь служит доказательством.

Журнал по требованию выдаёт Signed Tree Head не старше Maximum Merge Delay. Если за этот период новых поступлений не было, журнал подписывает тот же Merkle Tree Hash со свежей меткой времени.

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

Предыстория: DigiNotar и появление CT

В 2011 году взлом нидерландского удостоверяющего центра DigiNotar позволил выпустить поддельные сертификаты для google.com и более 200 других популярных доменов. Эти сертификаты использовались против как минимум 300 000 человек, связанных с Ираном, пока те просматривали подделанные сайты. С тех пор произошло много похожих инцидентов — чаще всего из-за ошибок удостоверяющих центров, но также и по вине владельцев доменов.

До появления CT между ошибочным выпуском сертификата и реакцией удостоверяющего центра могла быть значительная задержка. Аудиты проверяли операционные практики и историю, а не техническую корректность. CT задумывалась как ответ на это: независимые журналы на основе деревьев Меркель делают выпуск сертификатов прозрачным и проверяемым.

Baseline Requirements CA/Browser Forum развивались параллельно: версия 1.1 вступила в силу 14 сентября 2012 года, версия 1.1.7 — 3 апреля 2014 года, 1.1.8 принята 5 июня 2014 года, 1.1.9 — бюллетенем 129 от 4 августа 2014 года. Более поздние версии принимались бюллетенями SC048 (1.8.0), SC050 (1.8.1), SC053 (1.8.2), SC051 (1.8.3) и SC054 (1.8.4).

Почему это сделали и что оказалось слабым звеном

Инцидент показал, что слабое звено — не инфраструктура владельцев доменов и не сами удостоверяющие центры, а процесс проверки контроля над доменом. Удостоверяющие центры формально соблюдали все требования, но выданные сертификаты всё равно оказались несанкционированными.

Второй слой проблемы — отзыв. Процедура официального отзыва сертификатов медленная и громоздкая. По RFC 5280 при отзыве удостоверяющий центр периодически выпускает подписанный список отзыва сертификатов (CRL), где каждый отозванный сертификат идентифицируется по серийному номеру, а система, использующая сертификат, должна получить достаточно свежий CRL и проверить, что серийного номера в нём нет. На практике этот путь оказывается слишком медленным для реакции на активную атаку.

Google прямо предупреждает: на вмешательство на стороне браузера не следует полагаться как на единственную защиту пользователей. Из-за сложности DNS-перехватов компания не может гарантировать, что её анализ выявил все затронутые домены, а вмешательства Chrome надёжно не защищают пользователей не-Chrome.

Что это меняет на практике

Владельцам доменов Google рекомендует мониторить журналы прозрачности сертификатов на предмет неожиданного выпуска сертификатов по своим доменам.

Для пользователей инцидент означает, что поддельный сертификат может выглядеть как обычное защищённое соединение. Ошибка вида NET::ERR_CERT_COMMON_NAME_INVALID возникает, когда сертификат действителен, но выдан на другое имя: пользователь зашёл по IP-адресу, на поддомен, не указанный в сертификате, или на старый адрес после переезда сайта. Тот же сценарий используют мошенники, подставляя настоящий сертификат от похожего домена. Предупреждение о неизвестном удостоверяющем центре может означать одну из четырёх ситуаций: сертификат НУЦ в браузере без российского корня, самоподписанный сертификат, атаку человека посередине или корпоративный прокси. Снаружи самоподписанный сертификат и атака «человек посередине» неразличимы, и браузер не может определить, какой из них перед ним. Если на сайте предполагается ввод данных, правило одно: закрыть вкладку и ввести адрес вручную, не переходя по ссылкам из писем.

Ограничения и открытые вопросы

Google признаёт неполноту своего анализа: из-за сложности DNS-перехватов нельзя гарантировать, что выявлены все затронутые домены, а вмешательства Chrome надёжно не защищают пользователей не-Chrome.

Остаётся неясным, какие ещё организации пострадали, сколько несанкционированных сертификатов было выпущено и все ли они, кроме сертификатов для доменов Google, заблокированы. Сроки действия выпущенных поддельных сертификатов не указаны.

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