dxdt.ru: занимательный интернет-журнал

Cloudflare собираются вместе с Google тестировать новый формат TLS-сертификатов в браузере Chrome. Это сертификаты, в которых вместо значения подписи размещается доказательство принадлежности к дереву Меркла (дерево хешей), где соответствующий корень подписан удостоверяющим центром (УЦ). Это принципиально иная структура, по сравнению с действующей в TLS для веба сейчас. Подписи не будет в оконечном сертификате, но зато и проверять в типичном сценарии нужно меньшее количество подписей. Схема хорошо подходит для криптосистем с постквантовой стойкостью: в этих криптосистемах запись значения подписи часто требует много байтов, а использование дерева позволяет эти значения не передавать вместе с каждым сертификатом. При этом хеш-функции, в целом, считаются достаточно стойкими к гипотетическим атакам на квантовом компьютере. Стойкость доказательств, использующих дерево Меркла, основана на стойкости хеш-функций (помимо подписи, конечно).

То есть, если схему упростить, то УЦ выпускает сертификаты пачками, объединяет их в дерево Меркла и подписывает корень. Схема аналогична тому, как устроены логи Certificate Transparency. Сторона, проверяющая такие сертификаты, должна считать доверенным подходящий корень дерева: то, что значение конкретного сертификата сходится к нужному корню – проверяется путём вычисления значений хеш-функций от сертификата и от вершин, поддерживающих путь к корню; нужные для проверки значения хеш-функций как раз и передаются вместо подписи в сертификате. По ссылке выше есть картинки, объясняющие принцип.

Это пока что эксперимент. В роли тестового УЦ, выпускающего сертификаты “деревьями Меркла”, выступит Cloudflare. Но обещают, что это будет не полноценный УЦ, а только сервис, просто укладывающий “в дерево” уже выпущенные действующим доверенным УЦ сертификаты. Соответствие сертификатов разных типов станет проверять Google, прежде чем раздавать в браузеры соотвествующие “корни доверия”. Обратите внимание, что тут речь про корни в терминах схемы с деревьями Меркла: это совсем не то же самое, что корневые ключи УЦ – ключи УЦ остаются, в том числе, корневые, но они здесь используются для проверки подписей на корнях дерева, охватывающего некоторый набор сертификатов. В разрабатываемой схеме, вообще говоря, будут не просто корни, а некоторые опорные узлы, позволяющие дереву расти. Возможно, я напишу отдельную подробную записку про эту технологию, которая технология, кстати, полностью поменяет имеющуюся сейчас инфраструктуру УЦ для веба. Поменяет уже на техническом уровне. В общем, довольно интересное развитие истории с TLS-сертификатами.

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

Администраторы настраивают DNS “как получилось”, с ошибками и дефектами – указаны IP-адреса вместо хостнеймов при делегировании, указаны лишние NS, серверы имён не отвечают на запросы SOA и т.д., и т.п. Однако система как-то работает. Только вот попытка использовать эти настройки в более или менее строгом варианте, – например, для проведения проверки права управления доменом (DCV), – наталкивается на эти ошибки и проверка не срабатывает. Потому что есть случаи, когда игнорировать дефекты настройки DNS нельзя. Обнаружение этих “дефектов”, например, может свидетельствовать об идущей атаке.

Администраторы дефектной зоны говорят, что, мол, “у нас всё работает, а значит, настроено правильно” – почему же ваш сервис отказывается принимать информацию из нашей DNS-зоны? При этом, “всё работает”, как ни странно, определяется тем, что “браузер успешно открывает веб-сайт”. Но проверяли-то DNS. А ведь просто произошёл как раз тот случай, отличный от “привычного” веба, когда некорректные настройки реально не работают, потому что, вообще говоря, они и не должны работать, это лишь система специально так спроектирована, что позволяет игнорировать дефекты. DNS толерантна к ошибкам. Это хорошо и полезно. Но из этого вовсе и не следует, что ошибки – это больше не ошибки, а особенности настройки.

Проблема эта, конечно, не только DNS касается.

В продолжение предыдущей записки. Два подхода к аутентификации сервисов и приложений – по отпечатку (значению) открытого ключа и по TLS-сертификатам. Сравним эти подходы с точки зрения того, на какое звено оказывается завязана аутентификация на практике. Пример первого подхода, непосредственно по ключам, – классическая конфигурация SSH (но не только, конечно, можно посмотреть на WireGuard и другие протоколы). Пример второго подхода – TLS с двухсторонней аутентификацией (клиента и сервера, mTLS).

Предположим, что у нас клиент (приложение) обращается к серверу. И приложение обнаруживает сервер по имени, с использованием DNS. Пока что будем считать, что и в первом, и во втором случае, системные и сетевые настройки – типовые, а вариант с TLS использует системный список хорошо известных доверенных УЦ (случай с собственным выделенным УЦ разобран отдельно). Рассмотрим разные ситуации в рамках задачи подмены сервера. То есть, задача атакующего – получить подключения клиентов на свой сервер так, чтобы клиенты ничего не заметили. Клиенты здесь – это приложения.

Что получается с вариантом TLS. Клиент находит IP-адрес сервера через DNS, а проверяет подписи в сертификатах. Ни то, ни другое – не привязаны к серверу. Поэтому, – “внезапно!” – решение оказывается полностью завязано на защиту авторитативных серверов зоны, в которой размещены имена серверов, и DNS-резолвера. Почему? Потому, что если атакующий может подставить IP-адрес своего сервера в ответ DNS, то клиент станет подключаться по TLS к подставному серверу. При этом клиент проверяет только валидность серверного сертификата, то есть, подпись на сертификате должна сходиться к доверенному ключу удостоверяющего центра (УЦ). Но при типовых настройках в этом списке больше сотни УЦ, а контроль над авторитативными серверами DNS (даже над одним) позволяет выпустить сертификат для нужного имени в одном из этих УЦ, например, в Let’s Encrypt. Естественно, речь о системе, которая находится в глобально доступной DNS. Но, скажем, Let’s Encrypt и так повсеместно используется для внутренних имён разных API и тому подобных штук: посмотрите в CT-логи, если хотите убедиться лично.

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

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

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

Теперь вариант с проверкой отпечатков ключей (SSH и прочие решения с key pinning). Значения допустимых ключей прямо задаются и на клиенте, и на сервере. Сейчас принято на клиенте сохранять серверный отпечаток при первом подключении. Но вообще известные отпечатки можно заранее настроить другими способами.

В этой схеме аутентификации, чтобы прозрачно подменить сервер – нужно утащить его секретный ключ. “Почувствуйте разницу”, потому что контроля над DNS недостаточно. Если DNS успешно переставлена, но на подменном сервере другой ключ, то клиент сразу же обнаружит подмену: значение открытого ключа не совпадает с ранее сохранённым отпечатком. Преимущество того же SSH тут в том, что уже штатные настройки клиента не позволяют подключиться просто так к серверу, который поменял ключ. (Да, на практике постоянно игнорируют этот момент, к сожалению.) Фундаментальное отличие от ситуации TLS – даже подмена DNS не позволяет прозрачно подменить сервер: нужен оригинальный секретный ключ. Просто взять открытый ключ и положить его на подставной сервер нельзя, потому что подставной сервер не сможет согласовать сеансовые ключи – чтобы подписать пакеты нужно знать серверный секретный ключ. В случае TLS, если есть возможность выпустить сертификат для нового ключа, то и знать исходный секретный ключ не обязательно.

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

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

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

Использование mTLS с собственным УЦ тоже помогает, но отчасти: если клиенты используют не типовой системный список доверенных ключей УЦ, а верят только в ключ конкретного, внутреннего УЦ, который предназначен строго для данной системы, ограничен в выборе хостов, а сертификаты выпускает по запросам администратора, то перенаправление DNS уже не сработает. Но и такая система оказывается защищена на уровне защиты упомянутого УЦ: то есть, ситуация оказывается даже несколько проще, и если есть сетевое перенаправление, то для успешной подмены сервера нужно получить контроль над скриптами внутреннего УЦ (а не DNS). Если вы подумали, что внутренний УЦ будет защищён лучше, чем DNS – то, как бы, это не обязательно так на практике.

Естественно, применение ACL на уровне сетей, на уровне виртуализации, сильно затрудняет подмену через DNS. Если доступ наружу открыт только в направлении некоторых “собственных сетей”, то перенаправить соединение на внешний узел просто так не получится. Но, во-первых, ACL могут настраиваться с использованием DNS; во-вторых, если ACL выстраиваются с точностью до IP-адреса (не IP-префикса), то зачем же тогда вообще прописывать хостнеймы? Как бы там ни было, но на описанные разные подходы к аутентификации – ACL не влияют.

Что-то опять довелось услышать сравнение аутентификации в SSH (по ключам) и двусторонней аутентификации в TLS (HTTPS) по сертификатам: мол, и там, и там – есть секретные ключи, которые нужно передавать для организации работы приложений, так что это одно и то же с точки зрения эксплуатации системы. Но это не так. Ситуации SSH и TLS тут различаются принципиально.

Посудите сами. Речь тут идёт о типовой схеме с SSH-ключами (в SSH тоже можно сделать “сертификаты”, но сейчас не об этом). Итак, в SSH имеем аутентификацию по отпечаткам ключей каждой стороны: сервер, фактически, проверяет отпечаток (то есть, значение – не важно) открытого ключа клиента; а клиент – отпечаток открытого ключа сервера. Стороны аутентифицируют каждая каждую напрямую, без помощи третьей доверенной стороны. Если ключ скомпрометирован, то его нужно непосредственно исключить по значению из списка доверенных. Например, удалить на сервере из authorized_keys.

При этом список доверенных ключей каждая сторона ведёт собственный (да, могут быть вспомогательные механизмы автоматического добавления снаружи и, также, внешней проверки, но штатный способ – собственная, локальная проверка). Включение в список доверенных ключей выполняется с участием администратора. На клиенте, нередко, добавление выполняется автоматизированно, при первом соединении (но не всегда так). Да, тут есть проблема, что многие администраторы и DevOps сейчас, подобно пользователям браузеров, начинают привыкать к игнорированию сообщений о добавлении новых отпечатков в доверенные. (Но действующую подмену, вообще говоря, в правильно настроенном SSH-клиенте проигнорировать сильно сложнее, чем в браузере.)

Теперь TLS. Двусторонняя аутентификация: серверный и клиентский сертификаты. Тут обязательно участвует третья сторона: штатный способ аутентификации – проверка подписи на сертификатах ключей. Технически, можно сравнить отпечатки (key pinning и пр.), но это будет за рамками типовой схемы. Типовая же схема требует сравнения не отпечатка, а подписи, поставленной третьей стороной. Совсем другая история, по сравнению с SSH. Именно что от слова “совсем”. Тут уже нельзя “отключить ключ” клиента или сервера, просто удалив его из списка доверенных. А если нет способа внешней проверки статуса сертификата и способа отзыва сертификатов, то всякий действующий (по времени) сертификат с верной подписью удостоверяющего центра будет всегда принят стороной, проводящей проверку. Подпись известного удостоверяющего центра верна? Верна. Принимаем. Без вариантов.

Если секретный ключ от клиентского сертификата утёк вместе с сертификатом, то тот, кто увёл ключ и сертификат, сможет предъявить этот сертификат серверу и пройти аутентификацию. Без отзыва сертификата – сервер ничего не может поделать: нет у него способа проверить, что это какой-то скомпрометированный ключ. Заметьте, что именно поэтому механизм отзыва тут строго необходим (ну, либо, можно увязнуть в новомодных тенденциях: сертификат должен быть сверхкороткого действия; что, естественно, никак не отменяет невозможность “отключения” доступа для всё ещё действующего сертификата, только интервал времени для успешной атаки уменьшается, это да).

В схеме SSH, чтобы подставить ключ на сервер – нужно прописать его значение в файл на сервере. В схеме с TLS-сертификатами – нужно подписать сертификат на стороне УЦ. На сервер, которому будет предъявлен валидный сертификат, даже не потребуется заходить.

Так что подходы к аутентификации в SSH и TLS (по сертификатам) – совершенно разные, нельзя их смешивать.

Пишут, что в браузере Firefox внедряют встроенный “сервис VPN”, который будет доступен “только для браузера”. То есть, строго говоря, это не VPN на уровне операционной системы, а именно наложенная сеть, предназначенная для клиентов-браузеров, поддержка которой в браузер и встроена. И такая сеть служит транспортом для доступа к веб-ресурсам конкретно браузером.

Развитие в этом направлении давно ожидалось: это логичный шаг, а сходную систему внедряет Google для Chrome. В целом, то, что веб, с точки зрения доступа, будет замыкаться внутри браузера, стало понятно ещё тогда, когда браузеры получили собственный доступ к DNS, минуя операционную систему – сейчас это встроенная в браузеры поддержка доступа к DNS-резолверам через DNS-over-HTTPS/DNS-over-TLS.

Доставка трафика через собственную наложенную сеть хорошо соответствует концепции “Интернет – это то, что показывается в браузере”. Конечно, веб – это лишь один из сервисов, работающих поверх Интернета, однако сейчас получается, что именно развитие технологий доступа к веб-сервисам продвигает создание сетей типа IP-over-IP.

F-Droid – это независимый от Google Play репозиторий приложений для Android-устройств, с требованием открытого исходного кода и со своими правилами. Пишут, что проект F-Droid не сможет продолжать работу, если Google внедрит новую, строгую систему идентификации/аутентификации разработчиков.

Несмотря на излишний пафос сообщения, поспорить с базовыми положениями сложно – цитата:

We do not believe that developer registration is motivated by security. We believe it is about consolidating power and tightening control over a formerly open ecosystem. (Мы не считаем, что регистрация разработчиков мотивирована безопасностью. Мы считаем, что это касается сосредоточения полномочий и усиления контроля над экосистемой, ранее бывшей открытой.)

Я постоянно использую приложения из F-Droid. Они, обычно, лучше, чем схожие версии в Google Play, которые, в моём случае, вообще не работают. Без F-Droid, конечно, будет сложнее.

Некоторые начинают о чём-то догадываться – в отношении “использования ИИ”. Вот The Register пишет (англ.), со ссылкой на исследование из Стэнфорда, что бред, генерируемый ИИ, не так уж полезен в рабочем процессе, поскольку и разбор наукообразной чепухи отнимает много времени, и доверие к источникам подобного резко падает. Для обозначения сгенерированного “с рабочими целями” LLM-текста применяют занятный красочный термин – workslop, от work+slop, что означает: “рабочие (служебные) помои”.

Вообще, проблему с тем, что информационное пространство кругом быстро замусоривается сгенерированным бредом, уже заметили очень многие: восклицания, “что в Интернете невозможно ничего найти” и “постоянно приходится продираться сквозь наукообразную чепуху высшего порядка, сгенерированную LLM” – слышны всё чаще. Приведу свежий пример: я недавно попытался найти какие-то внятные описания того, как должна выглядеть буква “O” (латинская) на реверсе монеты в один пенни Великобритании за такой-то период. Вместо ссылок на внятные разборы (которые, очевидно, всё ещё есть в доступе – это же одна из основ практического исторического метода) – поиск Google выдал сгенерированный ИИ/LLM “ответ”, в котором, с первых же слов, буквально, утверждалось (на английском), что “никакой буквы O на реверсе таких монет нет, поскольку там написано ONE PENNY”. Вот так. Да, ONE – написано, но вот буквы “O” – нет. Отличный пример того, куда ведёт всё это использование “прорывных технологий ИИ” тут и там, навязываемое “с высоких трибун”. Но ничего уже не поделать: например, тот же ресурс “Хабр”, как я обнаружил, нынче просто затоплен подобным сгенерированным потоком.

Да, конечно, тут можно уточнять, что, мол, в примере про монету, данная “поисковая” система имела в виду, что нет отдельной буквы “O”, как обозначения монетного двора, серии или чего-то подобного. Но это всё будет выдумка, тщетная попытка придать содержательности продукту синонимайзера-переростка – потому что исходная система ничего в виду не имела, а просто сгенерировала текст, который совсем не попал в запрос; и всё вместо того, чтобы хотя бы попытаться правильно ранжировать источники.

Что касается довольно шумной темы “белых списков” в “Интернете” (так называемом) – процитирую свою публикацию 2019 года:

Блокирование же трафика по IP-адресам несет немало побочных эффектов, что, впрочем, вряд ли способно предотвратить его использование. Предельным вариантом здесь может быть использование белых списков узлов, но тогда это будет уже не Интернет, а закрытая частная сеть.

То есть, тут ключевой момент – “это уже не Интернет”, поэтому-то, в контексте Интернета, тут и обсуждать особенно нечего. Но, тем не менее, ещё одна цитата из той же публикации, про возможное развитие:

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

Мессенджер Signal внедряет платное централизованное хранение резервных копий сообщений на своих серверах. Занятно, что Signal позиционируется как “безопасный мессенджер”. Впрочем, вряд ли какое-то из этих новомодных приложений не позиционируется как “безопасное” или “самое безопасное”.

У Signal, что называется, и так “накрученный” протокол – в том смысле, что там большое количество логических слоёв, а это усложняет и понимание, и правильную реализацию. Теперь к этому прикручивают ещё и центральное копирование сообщений. Конечно, написано, что копии защищены “сквозным шифрованием” (расхожий маркетинговый термин, end-to-end), а восстановить их может только тот, кто знает специальный секретный ключ (предполагается, что это пользователь данного мессенджера). Конечно, это так только в том случае, если всё сработает штатно. Никакое зашифрование сообщений, как обратимая операция, не является аналогом уничтожения этих сообщений. Кроме того, нужно учитывать, что там заявлена подписочная модель оплаты, то есть, в дополнение к “сквозному шифрованию” должен быть какой-то “сквозной” публичный идентификатор – иначе платёжная система не сможет понять, кто за какую подписку заплатил (да, можно придумать перемешивание с привязкой по секретным ключам, но для этого нужно и оплату принимать совместимым способом, а это из области фантастики).

Раскрученные СМИ мессенджеры развиваются по схожим сценариям. Так что теперь в Signal, даже если пользователь уничтожил устройство с приложением, сообщения можно официально и штатно восстановить из центрального хранилища. Собственно, эта возможность и заявлена в качестве основной. Уничтожение устройства не является обязательным условием копирования сообщений из хранилища. А ключи – ключи утекают в результате ошибок или в результате “ошибок”.

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

В Cloudflare выпустили разбор ситуации с выпуском неавторизованных TLS-сертификатов для 1.1.1.1. Пишут, что в логах Certificate Transparency (CT) эти TLS-сертификаты не обнаружили потому, что не отслеживались сертификаты для IP-адресов, в мониторинг приходило слишком много сообщений из CT, а также и не для всех доменов/ресурсов настроили отслеживание сертификатов.

В общем – не следили за сертификатами в CT-логах, несмотря на наличие соответствующего собственного сервиса. Ситуация “сапожник без сапог” – не редка в корпорациях, и, к сожалению, настигла Cloudflare тоже. Но тут, как минимум, оперативно выпустили подробный разбор случившегося.

В продолжение предыдущей заметки, про подозрительные сертификаты для 1.1.1.1, выпущенные УЦ Fina RDC 2020: интересно, что, согласно crt.sh, соответствующие пресертификаты есть и в CT-логах (Certificate Transparency) Cloudflare. Выпускать такие “странные” сертификаты в данном УЦ начали ещё в прошлом году. То есть, получается, что либо Cloudflare вообще не следит за именами из сертификатов даже в тех CT-логах, в которых является провайдером, либо это всё же по согласованию с Cloudflare выпущено. Естественно, последний вариант – ну уж совсем маловероятен, а вот в то, что Certificate Transparency не отслеживается – поверить как раз нетрудно.