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