Разведка по журналам сертификатов: как чужая инфраструктура рисуется за пять минут

Чтобы получить схему чужой сети, сегодня не нужны ни сканеры портов, ни словарные переборы DNS. Достаточно открытого журнала, куда удостоверяющие центры складывают всё, что они когда-либо подписали, — Certificate Transparency. Один HTTP-запрос отдаёт список хостов вместе с датами выдачи с точностью до секунды.

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

Пять минут наблюдателя

Логи целиком зеркалируются мониторами — crt.sh, Censys, merklemap — и через них ищутся по любому имени. Простейший вариант обращения выглядит так:

curl -s 'https://crt.sh/?q=example.com&output=json' | jq -r '.[].name_value' | tr ';' '\n' | sort -u

Подстановочный символ % (в адресе он кодируется как %25) возвращает разом всю россыпь поддоменов. На случай ответа Unsupported use of '%' у проекта открыта база напрямую:

psql -h crt.sh -p 5432 -U guest certwatch

Насколько богатый улов там бывает, показали Робертс и Левин (WPES 2019, University of Maryland), разобрав полный срез сертификатов из Censys. Из одних только имён хостов извлеклись более 130 000 имён пользователей на семи сайтах, 5 861 адрес электронной почты в поддоменах одного облачного сервиса баз данных, 77 825 доменов, по которым восстанавливаются связи «поставщик — клиент», и 25 346 уникальных поддоменов одной только компании Discovery. Регулярно всплывали внутренние QA- и staging-серверы, админки, кодовые имена невыпущенных продуктов.

Что о вас самих знает наблюдатель, покажет одна строка:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"

Каждая строка вывода давно прочитана кем-то помимо вас.

Откуда взялась эта публичность и почему её не выключить

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

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

По правилам Chrome сертификату со сроком до 180 дней нужно не меньше двух SCT (подписанных отметок о включении в лог), а при более длинном сроке — не меньше трёх; при этом хотя бы пара SCT обязана происходить от различных операторов логов. Safari довольствуется двумя. Сам SCT — обязательство лога добавить запись в дерево в рамках Maximum Merge Delay, то есть обычно в течение суток; фактически поиск находит её через считаные минуты.

23 секунды и 84 секунды

Как быстро строчка из журнала оборачивается трафиком на 443-м порту, замеряли дважды — независимыми командами, с интервалом в четыре года.

В 2018-м Шайтле с соавторами (IMC 2018, TU München и партнёры) развернули 11 honeypot-поддоменов со случайными двенадцатисимвольными именами. Наружу эти имена попали единственным путём — через CT-лог. DNS-запросы начались спустя 73 секунды; резолверам Google, 1&1 и Amazon хватило 12 минут, чтобы обойти всю одиннадцатку. Первое HTTP-соединение приходило где-то между 59 минутами и 19 сутками, но чаще всего укладывалось в первые пару часов. Одна из машин прошлась по honeypot'ам сканом 30 портов.

Спустя четыре года измерение повторили в UCSB — группа Плетинкса (EuroS&P 2023). Цифры уменьшились примерно на порядок: медиана до первого DNS-запроса составила 23 секунды, до первого HTTPS-запроса — 84 секунды.

Отдельного внимания заслуживает их двухсотдневный эксперимент. Одни хосты обходились самоподписанными сертификатами и в CT не попадали, другие получали обычный публичный. За 200 дней на контрольную группу по IPv6 не пришло ни одного входящего пакета. Вторая группа собрала порядка 2 700 — с 959 уникальных адресов из 112 автономных систем. По IPv4 к засвеченным именам обращались с 2 291 адреса, принадлежащих 267 AS.

Важна тут именно IPv6-половина: перебирать такое адресное пространство бессмысленно, следовательно, узнать об этих машинах можно было только из журнала.

Четыре развилки — и цена каждой

Wildcard

Шаг наименьшего сопротивления, и ровно его советуют Робертс с Левином. Оговорка существенная: маскируется лишь один уровень, крайний слева. Хост a.b.example.com под *.example.com не попадает — ему потребуется собственный сертификат, а значит, имя вновь окажется в журнале. Wildcard у Let's Encrypt выпускается исключительно по DNS-01; HTTP-01 и TLS-ALPN-01 для валидации подстановочных имён прямо непригодны.

certbot certonly --dns-cloudflare \
  --dns-cloudflare-credentials /root/.secrets/cf.ini \
  -d 'example.com' -d '*.example.com'

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

REALITY

Здесь проблема снимается на корню, поскольку сертификат не выпускается вовсе: рукопожатие TLS заимствуется у постороннего сайта, прописанного в dest/target, и клиенту предъявляется именно его сертификат. Отправлять в CT-лог попросту нечего. Ограничение очевидное — схема закрывает прокси-трафик, но Grafana или Immich таким образом не укроешь.

Собственный удостоверяющий центр

Вариант для внутренних сервисов, которыми пользуетесь вы и пара-тройка ваших устройств. Корень придётся вручную разложить по всем клиентам, зато перечень имён остаётся вашим частным делом.

Смириться и укрепить периметр

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

server {
    listen               443 ssl default_server;
    ssl_reject_handshake on;   # nginx 1.19.4 и новее
}

Дальше — проверка подлинности на входе, а не за формой логина: mTLS, basic-auth на уровне обратного прокси, допуск исключительно из VPN-подсети. Восемьдесят четыре секунды означают не «успею настроить по-быстрому», а «времени нет вовсе»: к первому чужому запросу защита должна уже стоять.

Источники

• Certificate Transparency — How CT Works — устройство логов, SCT, MMD
• Chrome Certificate Transparency Policy — требования к числу SCT и операторам
• Scheitle et al., The Rise of Certificate Transparency and Its Implications on the Internet Ecosystem, IMC 2018 — honeypot, 73 секунды до DNS
• Pletinckx et al., Certifiably Vulnerable: Using CT Logs for Target Reconnaissance, EuroS&P 2023 — 23 и 84 секунды, 200-дневный honeypot
• Roberts & Levin, When Certificate Transparency Is Too Transparent, WPES 2019 — что утекает через имена хостов
• Let's Encrypt: Challenge Types — DNS-01 как единственный путь к wildcard
• nginx: ssl_reject_handshake
• XTLS REALITY: конфигурация