Думаю, многие помнят позапрошлогодний инцидент с Man-in-the-Middle атакой на XMPP-сервис jabber.ru. Эта история наделала много шума, но, как мне кажется, главный вывод из неё так и не был усвоен широкой аудиторией. А зря. Потому что эта атака вскрыла системную уязвимость в процессе выдачи TLS сертификатов, которая напрямую касается миллионов сайтов, особенно тех, кто доверяет свою безопасность Cloudflare.
Я поднял эту тему на форуме Cloudflare 23 дня назад, но, как и в случае с другими подобными запросами, ответа не получил. Поэтому я здесь, чтобы разложить всё по полочкам вам.
Разбор полетов: инцидент с jabber.ru
Для тех, кто пропустил или забыл, краткий пересказ:
Что произошло? В течение нескольких месяцев (как минимум с июля по октябрь 2023 года) весь трафик крупнейшего российского XMPP-сервиса jabber.ru перехватывался и расшифровывался. Атакующие смогли получить полностью валидные TLS сертификаты от Let's Encrypt для доменов jabber.ru и xmpp.ru.
Как это сделали? Это не был взлом серверов. Атака была реализована на уровне сети хостинг-провайдеров — Hetzner и Linode. Злоумышленники (предположительно, это была операция в рамках "законного перехвата" государственными акторами) перенастроили маршрутизацию так, что весь трафик, предназначенный серверам jabber.ru, включая запросы на валидацию домена от Let's Encrypt, шёл через их инфраструктуру.
Перехватив запросы валидации (вероятнее всего, http-01 или tls-alpn-01), они успешно доказали удостоверяющему центру (УЦ) LE, что контролируют домен, и получили легитимные сертификаты. Обнаружили атаку случайно, когда один из мошеннических сертификатов истёк и не был вовремя продлён, что вызвало у пользователей ошибки подключения.
Имхо, ключевой момент здесь — уязвимость не в протоколе XMPP и не в самом УЦ Let's Encrypt. Уязвимость кроется в базовом механизме подтверждения владения доменом (Domain Validation, DV).
Технический ликбез: CAA, RFC 8657 и как это должно нас спасать
Казалось бы, если твой трафик могут перехватить на уровне провайдера, то ты беззащитен. Но это не так. Для защиты от подобных сценариев существует механизм Certification Authority Authorization (CAA), описанный в RFC 8659.
Это простая DNS запись, которая говорит: "Для моего домена сертификаты может выпускать только вот этот УЦ".
# Разрешаем только Let's Encrypt
example.com. IN CAA 0 issue "letsencrypt.org"Но, как показал случай с jabber.ru, этого недостаточно. Атакующие ведь и использовали разрешённый УЦ, который им и выдал сертификат.
Постфактум, благодаря анализу инцидента инженером по имени Хьюго Ландау (Hugo Landau), он пришёл к выводу, что предложенный им стандарт ещё в далеком 2019 году под номером RFC 8657 мог бы предотвратить подобный инцидент. Этот стандарт расширяет CAA двумя критически важными параметрами:
-
accounturi
Это «второй фактор» для выдачи сертификата. Этот параметр привязывает выдачу сертификатов к конкретному аккаунту в УЦ. URI вашего аккаунта в Let's Encrypt — это уникальный идентификатор.# Разрешаем Let's Encrypt, но ТОЛЬКО с аккаунта с ID 12345678 example.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678"Даже если злоумышленник перехватит ваш трафик, он не сможет получить сертификат, потому что его запрос придёт с другого аккаунта Let's Encrypt, а LE поддерживает этот стандарт ещё с января 2021 года. УЦ сверит
accounturiиз запроса с тем, что указан в вашей CAA-записи, увидит несоответствие и откажет в выпуске. -
validationmethods
Этот параметр позволяет ограничить методы, которыми УЦ может проверять владение доменом.# Разрешаем Let's Encrypt, но только через DNS-валидацию example.com. IN CAA 0 issue "letsencrypt.org; validationmethods=dns-01"Поскольку атака на jabber.ru была возможна из-за перехвата сетевого трафика, ограничение валидации методом
dns-01(который требует внесения изменений в DNS-зону, а не контроля над трафиком) сделало бы атаку значительно сложнее, а использование DNSSEC доменом могло бы сделать её вовсе невозможной. -
Комбо
# Максимальная защита example.com. IN CAA 0 issue "letsencrypt.org; validationmethods=dns-01; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12345678"Хьюго Ландау, автор RFC 8657, заявлял в своём анализе инцидента, что основываясь на том, что мы знаем об этой атаке, она была бы предотвращена развёртыванием этого расширения.
Слон в посудной лавке: при чём тут Cloudflare?
А теперь самое главное. Cloudflare, будучи лидером в области интернет-инфраструктуры и безопасности, для своего безальтернативного для бесплатных аккаунтов сервиса Universal SSL делает очень странную вещь - когда он включен, Cloudflare автоматически добавляет в вашу DNS-зону CAA-записи для своих партнёрских УЦ (Let's Encrypt, Google Trust Services и др.).
Вот как выглядит эта запись:
# Записи для обычных сертификатов (issue)
example.com. IN CAA 0 issue "letsencrypt.org"
example.com. IN CAA 0 issue "pki.goog; cansignhttpexchanges=yes"
example.com. IN CAA 0 issue "digicert.com; cansignhttpexchanges=yes"
example.com. IN CAA 0 issue "comodoca.com"
example.com. IN CAA 0 issue "ssl.com"
# Записи для wildcard-сертификатов (issuewild)
example.com. IN CAA 0 issuewild "letsencrypt.org"
example.com. IN CAA 0 issuewild "pki.goog; cansignhttpexchanges=yes"
example.com. IN CAA 0 issuewild "digicert.com; cansignhttpexchanges=yes"
example.com. IN CAA 0 issuewild "comodoca.com"
example.com. IN CAA 0 issuewild "ssl.com"Видите проблему? Они до сих пор не используют accounturi и не дают переписать записи!
Это оставляет ту же самую дыру в безопасности, от которой пострадал jabber.ru . Cloudflare, по сути, говорит: "Любой аккаунт в Let's Encrypt может получить сертификат для этого домена, если пройдёт валидацию".
Ваша собственная, более строгая CAA-запись с accounturi для вашего сервера, не спрятанного за прокси, становится практически бесполезной. Потому что по правилам обработки CAA, если есть хотя бы одна разрешающая запись без accounturi, УЦ имеет право выпустить сертификат для любого аккаунта. А если вы решите вручную прописать в CF записи с accounturi , то CF заботливо их не применит и оставит свои. А чтобы отказаться от Universal SSL , придётся заплатить чеканную монету.
Таким образом, Cloudflare не просто не использует современные стандарты безопасности для своих клиентов, но и активно мешает им делать это самостоятельно, сводя на нет всю идею RFC 8657.
Выводы и что делать?
Ситуация на данный момент патовая. С одной стороны, у нас есть рабочий и поддерживаемый ведущими УЦ (Let's Encrypt внедрил это ещё в 2021 году) стандарт, который решает реальную и доказанную проблему. С другой - крупнейший инфраструктурный провайдер, который не только игнорирует этот стандарт, игнорирует сообщения об этом стандарте, но и своей реализацией создаёт риски для миллионов пользователей.
Для пользователей:
Проведите аудит. Проверьте свои CAA-записи. Если вы используете Universal SSL от Cloudflare, знайте, что вы уязвимы для атак типа jabber.ru.
Требуйте перемен. Если вам небезразлична безопасность вашего проекта, поддержите мою тему на форуме Cloudflare. Чем больше будет резонанс, тем выше вероятность, что нас услышат. Это не первый такой запрос, но предыдущие были попросту проигнорированы.
Рассмотрите альтернативы. Для критически важных проектов, возможно, стоит отказаться от Universal SSL в пользу ручного управления сертификатами и полного контроля над CAA-записями либо в Cloudflare, либо в другом сервисе.
Что должен сделать Cloudflare:
Начать использовать
accounturiиvalidationmethodsдля всех сертификатов, которые они выпускают в рамках Universal SSL. Это немедленно и по умолчанию повысит безопасность для всех их клиентов. Они же точно знают ID своих профилей, который запрашивают выпуск сертификатов?Обеспечить полное управление CAA-записями для пользователей, чтобы они могли добавлять свои собственные записи с
accounturiиvalidationmethods, и чтобы эти записи корректно сосуществовали с записями Cloudflare.Обновить документацию и честно рассказать пользователям о текущих рисках и о том, как они обрабатывают CAA.
Да, белый пушистый лис не объявит себя до некоторого времени, но, как показывает практика, он гарантированно придёт. И лучше закрыть эту дыру сейчас, чем потом разгребать последствия, как это пришлось делать администраторам jabber.ru.
