TLS и подмена сертификата на jabber.ru

21. October 2023, 12:59 Безопасность, Интернет, Компьютеры и ПО

Пишут про перехват TLS-трафика сервиса Jabber.ru, без ведома администраторов: это практическая атака, судя по подробному описанию – там всё как положено: MITM в TLS и подмена серверного сертификата на тоже валидный. Как пишут, выпуск сертификата, скорее всего, проведён при помощи перехвата трафика, идущего на оригинальный сервер – подменные сертификаты попали в CT-логи, в описании есть на них ссылки (это сертификаты Let’s Encrypt, конечно).

Вообще, побороться с подобной подменой, когда возможен перехват трафика на уровне хостера (а это практически всегда так), весьма сложно. Единственный более или менее эффективный способ – прямая авторизация серверных ключей клиентом по отпечаткам, однако, это сложно, плохо масштабируется, ну и так далее. (Отмечу, что применительно к Jabber/XMPP – есть схемы с защитой точка-точка, между пользователями – OMEMO, например). Certificate Transparency (CT), CAA и подобные технологии, направленные на УЦ, от таких атак не особо защищают: CT, несомненно, полезно, но часто работает постфактум, потому что, как минимум, нужно клиентам проверять метки в сертификатах; и это, если вообще считать, что CT тут работает – технически, выпустить быстрый подменный сертификат УЦ может без меток логов, ничто этому не мешает; да и метки можно сделать без публикации в логах, если есть ключи от этих логов; но, конечно, это всё существенно усложняет процесс. Что касается CAA-записей: да, это полезно, но для УЦ, технически, отказаться от проверки CAA ещё проще, чем проигнорировать CT-логи и SCT-метки.

(Ссылка: описание инцидента от OpenNet на русском.)

Дополнение: понятно, что УЦ, в такой конфигурации атаки, ни при чём – УЦ не имеет возможности в рамках сетевых протоколов отличить подменный узел от настоящего с точностью, превышающей перенаправление сетевого трафика в локальной сети хостера; естественно, автоматически выпускаемые TLS-сертификаты для веба не могут служить инструментом защиты от подобных атак, это и не планировалось, никакие CT тут не помогут; возможность активного и полного перехвата трафика с подменой – автоматически приводит к возможности выпустить TLS-сертификат с соответствующим именем хоста через УЦ TLS; перехват трафика – позволяет подменить данные и при DNS-проверке, это даже в чём-то проще, но перехватывать нужно трафик к DNS-серверам и/или от них (и не должно быть поддержки DNSSEC, да).

Адрес записки: https://dxdt.ru/2023/10/21/11256/

Похожие записки:



Далее - мнения и дискуссии

(Сообщения ниже добавляются читателями сайта, через форму, расположенную в конце страницы.)

Комментарии читателей блога: 4

  • 1. 22nd October 2023, 14:12 // Читатель void написал:

    LetsEncrypt в атаке не участвовал, поэтому давайте примем, что УЦ работают нормально.

    Тогда от описанной атаки можно было бы защититься: подписать зону DNSSEC и опубликовать CAA-запись, запрещающую метод подверждения аутентичности HTTP-01 (RFC 8657, параметр validationmethods).

    Также вместо DNSSEC можно еще разместить DNS-сервер на отдельном “китайском” хостинге, который заведомо не будет сотрудничать с атакующим.

  • 2. 22nd October 2023, 15:32 // Александр Венедюхин:

    Я, конечно, согласен, что DNSSEС (если его ещё проверяет УЦ) и CAA улучшили бы ситуацию в этом конкретном случае. Но если смотреть в чуть большей общности, то возникает куча оговорок. Успешный перехват DNS-трафика для блокирования конкретно CAA, конечно, несколько проще, чем полная подмена DNS, но всё же наводит на мысли, что там уже и недалеко до подмены DNS-проверки. А вот, что касается “участия УЦ”: тут пока ведь не ясно – судя по техническому описанию атаки, УЦ сделать ничего не мог бы, так или иначе, так что, вроде как, и спросить нечего. Однако напрашивается “бумажный” аспект: формально, если УЦ не предупредили, как положено, то такая атака прямо нарушает правила/лицензию использования услуг УЦ типа Let’s Encrypt (то есть, “имени CA/B-форума”); другое дело, что это довольно слабый аспект. Учёт CAA – тоже момент не самый простой. Есть ли среди “хорошо известных” УЦ такой, у которого в разделе “Особые поручения” присутствует специальная кнопка “Забыть проверить CAA” или “Сломать проверку CAA” – ну, вопрос дискуссионный; вот кнопка “Не публиковать в CT-логах” – вроде как встречается, говорят. Опять же, подчеркну: в каких-то конкретных случаях – и CAA, и CT – помогают, надо ставить, тут нет сомнений; но, к сожалению, это далеко не универсальное решение.

  • 3. 30th October 2023, 18:44 // Читатель Alex написал:

    А скажите, что мешает LE проводить обновление сертификата через HTTPS подписанный предыдущим сертификатом (все еще валидным)?
    Почему я вообще должен держать (ну или запускать) HTTP(без S) сервер только для LE?
    Более того, если я в себе уверен, я бы вообще запретил обновлять сертификат другим путем, пока старый не проэкспайрился.

    Это звучит так логично, что я не могу понять почему этого не сделано в LE? Наверное я что-то упускаю?

  • 4. 30th October 2023, 22:19 // Александр Венедюхин:

    > что мешает LE проводить обновление сертификата через HTTPS подписанный предыдущим сертификатом

    В валидации сертификата на этапе проверки права управления доменом смысла очень мало, так или иначе, поскольку, например, нельзя отказать в выдаче сертификата серверу, если у него нет этого предыдущего сертификата, соответственно, добавление HTTPS ничего не меняет – его всё равно требуется игнорировать в части валидации. Но сам HTTPS добавляет сложностей на уровне доступа, для проверяющего робота.

    > Почему я вообще должен держать (ну или запускать) HTTP(без S) сервер только для LE?

    Это, скорее, для certbot или другой утилиты. Сам Let’s Encrypt, вроде, поддерживает проверку через DNS, да даже и доступ по 443/tcp.

    > Это звучит так логично, что я не могу понять почему этого не сделано в LE?

    Ну, как минимум, можно исключить веб-сервер и вообще воспользоваться DNS для подтверждения права управления.

    А что касается запрета выпускать сертификат, то это, в принципе, можно сделать через CAA-запись (ну, с точностью до описанных выше особенностей, конечно, но вообще – CAA как раз для этого и придумали).

Написать комментарий

Ваш комментарий:

Введите ключевое слово "QDS44" латиницей СПРАВА НАЛЕВО (<--) без кавычек: (это необходимо для защиты от спама).

Если видите "капчу", то решите её. Это необходимо для отправки комментария ("капча" не применяется для зарегистрированных пользователей). Обычно, комментарии поступают на премодерацию, которая нередко занимает продолжительное время.