SavePearlHarbor

От чего защищает Certificate Transparency?

—

от автора

admin

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

Certificate Transparency

В этом контексте активно обсуждается механизм certificate transparency, который должен защитить пользователей от атак man-in-the-middle, осуществляемых с помощью сертификатов, выпущенных без ведома владельца домена. Вот что написано на профильном сайте:

A CA that has been hacked or sloppy can issue certificates for any website. The communication would still be technically encrypted, but there could be an attacker at the other end who could intercept the private data.

Я долго пытался разобраться, как это работает, и проверить хотя бы 1 сертификат по ct-логам. К моему большому удивлению у меня не получилось ничего. Единственное, что мне рекомендуют в интернете нейросети, Stackoverflow, Habr и прочие ресурсы, — это зайти на сайт одного из агрегаторов логов и что-то там посмотреть.

Агрегаторы ct-логов

Во-первых, мне непонятно, почему я должен верить информации от агрегаторов. Если CA has been hacked, то и агрегатор может быть хакнут. Мы же вообще говорим, что хотим защититься от атак, производимых на государственном уровне с использованием административного давления и инструментов спецслужб. Если они прогнули CA, работающий за деньги, то уж агрегатор прогнут тем более.

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

В третьих, все агрегаторы, которые я нашел, ссылаются на crt.sh. Но этот странный ресурс почему-то у меня на 9 запросов из 10 отвечает ошибкой 502. Я и через VPN пробовал, и через прокси, ошибка на сервере, бесполезно пытаться ее обойти. Автоматизировать контроль своего домена через такой ненадежный ресурс нереально.

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

Доказательство включения в ct-лог

Доверять надо только криптографии. Только тот ресурс, который криптографическими методами подтвердит данные, указанные в сертификате, может что-то удостоверить.

  1. Беру произвольный сертификат из первой попавшейся вкладки браузера.

  2. Достаю из сертификата расширение SCT List

  3. Достаю идентификатор ct-лога

  4. Из публичного списка ct-логов нахожу ct-лог с указанным идентификатором

  5. Отправляю на адрес ct-лога запрос /ct/v1/get-proof-by-hash

Ни по одному сертификату ни одного подтверждения получить не удалось. Везде получаю ответ 404 Not Found.

Скорее всего, я что-то неправильно делаю, неправильно получаю hash от сертификата или неверно указываю параметр tree_size.

Беру специальную утилиту.

certutil -dump cert.pem

Эта утилита, встроенная в Windows, проверяет сертификат по ct-логам. И она тоже по каждой метке SCT во всех сертификатах пишет Not found.

    CT[0]:      Version: 1      Key Id Hash(log-sha256): yKPEf8ezrbk1awE/anoSbeM6TkOlxkb5l605dZkdz5o=      Key Id Hash(log-sha256-hex): c8a3c47fc7b3adb9356b013f6a7a126de33a4e43a5c646f997ad3975991dcf9a      Signing Time: 21.07.2026 16:13      Extensions: 0000      Hash Algorithm: 4 (SHA256)      Signature Algorithm: 3 (ECDSA)      Length: 00460000: 30 44                                     ; SEQUENCE (44 Bytes)0002:    02 20                                  ; INTEGER (20 Bytes)0004:    |  77 35 87 19 76 c3 67 58  e0 71 1d f7 0e d8 2c 340014:    |  ba b1 79 1f d4 9f 4f 58  10 0c 4c 8a b5 de 79 550024:    02 20                                  ; INTEGER (20 Bytes)0026:       66 b1 3e 7d 11 46 16 31  3f e9 1d 6c 31 80 41 2a0036:       ea 65 7f 37 1f 6b bf 3a  16 66 5f 7a c1 71 27 69    Not found: yKPEf8ezrbk1awE/anoSbeM6TkOlxkb5l605dZkdz5o=

Давайте сделаем свой MitM

Чтобы посмотреть, как работает защита от «sloppy CA», я решил его сэмулировать.

  1. Беру цепочку сертификатов с популярного в России сайта habr.com (кстати, рекомендую — хороший ресурс).

  2. Выпускаю свой самоподписанный CA с такими же атрибутами, что у издателя исходного сертификата.

  3. Перевыпускаю своим CA всю цепочку. Получаю 3 сертификата, повторяющих цепочку сертификатов habr.com со всеми атрибутами и расширениями. Отличие только в ключах и контрольных суммах.

  4. Настраиваю локальный nginx

    server {
    listen 0.0.0.0:443 ssl;
    server_name habr.com;
    ssl_certificate /etc/nginx/keys/habr.pem;
    ssl_certificate_key /etc/nginx/keys/habr-key.pem;
    location / {
    proxy_pass https://habr.com;
    }
    }

  5. Прописываю в /etc/hosts 127.0.0.1 habr.com

  6. Добавляю свой самоподписанный CA в трастстор (если вы повторяете мои шаги, не забудьте потом удалить этот серт из списка доверенных).

  7. Открываю браузером https://habr.com

Вуаля. Имеем полноценный MitM, а браузер ни сном, ни духом. Более того, если посмотреть в детальную информацию о соединении, попробовать по ней что-то поискать на crt.sh, то ничего подозрительного не заметишь. Разница есть только в байтах публичного ключа и в fingerprint. Но поскольку в ct-логе лежит не сам сертификат, а так называемый пресертификат, то у него fingerprint с сертификатом и не должен совпадать.

В моей атаке пришлось в трастстор добавить левый сертификат, но поскольку продекларированная задача ct-лога — защита от некорректной работы CA, то в настоящей атаке корневой сертификат будет сразу валидный.

Эту статью я как раз написал через описанный MitM. Пост я готовил часа 4, за все это время никаких предупреждений не всплывало, никаких признаков постороннего вмешательства обнаружено не было. HSTS не помог, браузер считает соединение безопасным.

Совсем недавно в корпоративном блоге Яндекса был пост, где утверждается:

При подключении браузер проверяет эту метку. Если метки нет или проверка не пройдена, соединение блокируется.

Пока что выглядит так, что браузер ведет себя иначе.

Любой может попробовать и убедиться

Я разместил в Яндекс.Облаке proof-of-concept атаки. 1 страничка, предъявляющая при обращении по адресу https://habr.com поддельные сертификаты.

Адрес странички d5dehub7dfspelj1u2u2.6brbn2wz.apigw.yandexcloud.net.

Соответственно, чтобы ею воспользоваться, нужно в DNS прописать habr.com CNAME d5dehub7dfspelj1u2u2.6brbn2wz.apigw.yandexcloud.net. Или узнать текущий IP этого доменного имени и прописать в /etc/hosts. После чего можно заходить браузером.

С помощью curl можно проверить работу ресурса без дополнительных настроек:

curl --connect-to ::d5dehub7dfspelj1u2u2.6brbn2wz.apigw.yandexcloud.net: https://habr.com

Вывод будет такой:

<html><body>I'm not Habr!</body></html>

Выводы

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

Все же хотелось бы разобраться

С большой степенью вероятности я просто что-то делаю неправильно. Может быть в браузере есть какая-то настройка, которую надо включить, чтобы он сверял сертификаты с логами. Или это вообще как-то не так работает, как я себе представляю.

Может быть есть какие-то утилиты, которые позволяют проверять ct-логи правильно?

Напишите, пожалуйста, ваши соображения в комментариях.

ссылка на оригинал статьи https://habr.com/ru/articles/1067248/