Имя, за которое может поручиться только владелец

Текст подготовлен 7 октября 2026 года.

Коротко

6 октября Google сообщил, что злоумышленники захватили реестры трёх национальных доменов — Ганы (.gh), Сьерра-Леоне (.sl) и Американского Самоа (.as) — и с их помощью получили настоящие, принимаемые браузерами сертификаты для нескольких доменов Google и других крупных сервисов. Ни один удостоверяющий центр взломан не был, и, по словам Google, центры, выпустившие эти сертификаты, действовали по правилам. Это и тревожит: проверки были выполнены правильно, а атака всё равно удалась. Слабое место — в самих проверках. 1 2

Эта статья о том, как такое возможно, почему стандартные меры защиты лишь ограничивают ущерб и как lopux.net — проект компании Reliable Communications s.r.o., сетевого оператора, зарегистрированного в Чехии, — убирает то звено, которое атаковали. В модели lopux.net имена хранятся в блокчейне, а владельцы сайтов сами публикуют свои ключи; ни удостоверяющих центров, ни доменных реестров посередине нет.

Что произошло

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

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

Google заблокировал найденные сертификаты в Chrome, попросил центры их отозвать и поискал другие в открытых журналах сертификатов (Certificate Transparency). Компания прямо заявила, что не может гарантировать, что нашла все пострадавшие домены, и что полагаться на блокировку в браузере для защиты пользователей не стоит. 1

Так уже было

2011, DigiNotar. Взломали нидерландский удостоверяющий центр и выпустили больше пятисот поддельных сертификатов — среди них wildcard-сертификат на google.com. С его помощью перехватывали почту примерно трёхсот тысяч человек в Иране. Атаку заметили, потому что в браузере одного пользователя — Chrome — были встроены настоящие ключи Google. Через несколько недель компания обанкротилась. 5
2017, Того (.tg). Реестр национального домена Того неделю находился под контролем злоумышленников, и для google.tg получили сертификат в популярном бесплатном удостоверяющем центре. Chrome отверг его только потому, что ключи самого Google встроены в браузер, — такой защиты почти ни у одного другого сайта нет. 3
2017–2019, «Sea Turtle». Cisco Talos описала кампанию, за которой стояло государство: атаковали регистраторов, реестры и DNS-провайдеров, чтобы перенаправлять трафик государственных организаций примерно в десятке стран. Talos назвала её первым известным случаем взлома реестра ради шпионажа. 4

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

Почему привычные меры лишь ограничивают ущерб

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

Мониторинг журналов Certificate Transparency показывает поддельный сертификат только после выпуска — и только если кто-то следит и успевает отреагировать.
Записи CAA, в которых перечислены центры, имеющие право выпускать сертификаты для домена, публикуются в DNS — на том самом уровне, который злоумышленник контролирует после захвата реестра.
Отзыв сертификата доходит до браузеров не сразу, а многие программы, помимо браузеров, его вообще не проверяют.
Закрепление ключа (key pinning) выдало DigiNotar в 2011 году и спасло Google в 2017-м, но универсальный механизм для этого убрали из браузеров несколько лет назад. Сегодня оно защищает лишь горстку очень крупных компаний, чьи ключи разработчики браузеров вписывают вручную.

Отдельно стоит сказать о DNSSEC и DANE: на бумаге они ближе всего к подходу lopux.net — владелец сам подписывает свои записи и может опубликовать в DNS отпечатки своих ключей. Но цепочка доверия проходит через реестр. Тот, кто контролирует реестр, может подменить ключи подписи домена вместе с его записями, — а в этом инциденте злоумышленники контролировали именно реестр. К тому же ни один распространённый браузер DANE не проверяет.

Вместе с журналами Certificate Transparency и закреплением ключей всё это — надстройки над несовершенной основой, по сути костыли: каждый закрывает одну дыру, не трогает модель доверия, которая эти дыры порождает, и нередко открывает новую. DNSSEC делает ответы DNS в несколько раз больше, и подписанные зоны стали излюбленным отражателем для атак с усилением (amplification) — понадобились костыли к костылю: ограничение частоты ответов, минимальные ответы на запросы ANY. А в 2024 году уязвимость KeyTrap показала, что одним специально составленным ответом можно на минуты или часы остановить любой крупный валидирующий резолвер, причём ошибка была не в чьей-то реализации, а в процедуре проверки, которую предписывает сам стандарт. 6 7 8

Интернет уже проходил через это. Когда в IPv4 закончились адреса, его спасли NAT и груда обходных решений. IPv6 задумывался как чистая замена со встроенной безопасностью. Поддержка IPsec была обязательной для каждого узла, пока в 2011 году требование не смягчили, а сквозной IPsec так и не наступил. Neighbor Discovery пришёл на смену ARP и унаследовал его уязвимость к подмене; криптографическая защита SEND так и не получила реального распространения, поэтому сети полагаются на RA Guard в коммутаторах, который научились обходить через заголовки расширения и снова латали. Переходные туннели, призванные облегчить миграцию, проносили трафик мимо IPv4-файрволов. Каждый новый слой безопасности приносил собственный слой дыр и костылей: расширения приватности для адресов со встроенным MAC-адресом, целый RFC про допустимую фильтрацию ICMPv6, захват dual-stack-хостов поддельными Router Advertisement внутри чисто IPv4-сетей, рекомендация обнулить число итераций NSEC3, многочасовой сбой Slack при внедрении DNSSEC… 9 10 11 12 13 14 15 16 17 18

Главное остаётся прежним: подлинность имени подтверждают организации, которые им не владеют.

Подход lopux.net: убрать посредников

lopux.net объединяет в одном приложении два сервиса. Лопух-VPN — это VPN: он ведёт трафик пользователя через серверы проекта по зашифрованному туннелю, который выглядит как обычный веб-трафик. Лопух-Интернет — отдельное пространство имён, намеренно вне доменной системы ICANN; его записи хранятся не в реестре, а в публичном блокчейне. Пока в нём две зоны верхнего уровня: .lopux и .ipvx.

Сервисами можно пользоваться по отдельности. Лопух-VPN, как любой VPN, скрывает IP-адрес пользователя от посещаемых сайтов; кроме того, сервис не привязывает IP-адреса к учётным записям.

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

Записи — в блокчейне, а не в базе реестра. Имя и его записи хранятся в публичном блокчейне, и изменить их можно только подписью владельца — любую другую подпись блокчейн отклоняет. Каждое изменение публично и снабжено отметкой времени.

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

Несколько независимых источников. Приложение читает блокчейн сразу через несколько публичных RPC-узлов — или через узел, который пользователь поднял сам, — и сравнивает ответы. При расхождении соединение не устанавливается.

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

Атака 2026 года держалась на двух шагах: подмене записей в реестре и прохождении проверки удостоверяющего центра. В модели lopux.net первый шаг невозможен без ключа владельца, а второго просто нет.

Сегодня ограничено намеренно, но открыто для расширения

Пока эта технология служит только самому lopux.net: именам в .lopux и .ipvx и сайтам за ними. Это ограничение сознательное: технических препятствий для расширения нет.

Конструкция не привязана к этим именам. Блокчейн-резолверы, которые обслуживают Лопух-Интернет, можно открыть для всего интернета, а записи обычных доменов — .com, .org или национальных — так же хранить в блокчейне, с теми же отпечатками ключей, опубликованными владельцами. Владелец существующего домена оставил бы его у своего регистратора и просто выбрал бы хранить его записи в блокчейне через lopux.net.

Чего lopux.net на этом этапе делать не планирует — так это регистрировать новые имена в обычном доменном пространстве. Регистрация там принадлежит ICANN и её реестрам. Имя, выданное в обход этой системы, однажды мог бы зарегистрировать кто-то другой через официальную, а два владельца у одного имени — ровно та ситуация, которую эта конструкция и призвана исключить. Хранение записей домена, у которого владелец уже есть, такого конфликта не создаёт.

Пользователь тогда мог бы попасть на такой сайт одним из двух способов:

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

Зачем нужно приложение

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

Почему это важно не только для lopux.net

Атака на реестры ещё раз показала: владеть доменом и иметь возможность это доказать — разные вещи, и второе сейчас зависит от посредников. Для большей части интернета это быстро не изменится. Но для сервисов, чьи пользователи живут под давлением государства, поддельный сертификат означает перехват переписки — и для них стоит строить имена, подлинность которых может подтвердить только владелец. Этим и занимается lopux.net, начиная с собственных сайтов.

И оговорка напоследок. Всё описанное сейчас работает в тестовой сети Ethereum Sepolia, а не в основной, и без обратной связи от пользователей проекту не обойтись. Попробовать сервис может любой, абсолютно бесплатно, — и в проекте будут рады услышать, что работает, что ломается и что непонятно.