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

Что-то опять довелось услышать сравнение аутентификации в 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 не отслеживается – поверить как раз нетрудно.

Обнаружились подозрительные TLS-сертификаты, валидные для IP-адреса 1.1.1.1 (в поле SAN), но, видимо, выпущенные без согласия компании Cloudflare, являющейся оператором адреса. Один из сертификатов довольно свежий – 26 августа этого года. Выпущены эти сертификаты УЦ (Удостоверяющим Центром), ключи которого, как пишут, входят в список доверенных Microsoft Windows (но не Mozilla, и не Google Chrome).

Эти сертификаты могут быть тестовыми – на такую мысль наводят использованные в них имена доменов. IP-адрес 1.1.1.1 кто-то мог ввести в качестве заглушки: по “старинной традиции” этот адрес многие воспринимают как “невозможный”. В любом случае – УЦ должен проверять право управления для всех имён и адресов, указываемых в сертификате, так что, если это тест, то он, к сожалению, не прошёл.

Такой сертификат, при наличии секретного ключа, позволяет незаметно для пользователя перехватить TLS-трафик в сторону IP-адреса 1.1.1.1, который соответствует нескольким глобальным сервисам Cloudflare (DNS-резолвер и VPN-сервис, как минимум). Чтобы перехват сработал – клиентское ПО должно считать ключи УЦ доверенными, так что, получается, в такой конфигурации сработает только для Windows (ну или только в браузере Edge, если он использует отдельный набор корней, а сама ОС этому УЦ не верит).

В свежей версии браузера Chrome (140) включен механизм сокрытия IP-адреса при помощи прокси-серверов. Пока что доступно только в режиме Incognito, и лишь для некоторых имён хостов (это важный аспект – см. ниже), которые, в контексте веб-страницы, являются “третьей стороной”: то есть с этих узлов загружаются какие-нибудь дополнительные ресурсы, а основной домен просматриваемого веб-узла при этом другой.

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

Интересно, что сейчас применение маскирования IP обещают по списку доменов, который доступен на Github; в этом списке, на момент написания записки, значится почти весь “официальный” веб от “Яндекса” (yandex.ru, mc.yandex.com, yandex.st и др.), а кроме того: vk.com, mail.ru и прочие, хорошо узнаваемые в Рунете, доменные имена.

В августе 2010 года, пятнадцать лет назад, в небольшой заметке про DNSSEC, я, действуя несколько неосторожно, предположил буквально следующее:

До нового Интернета остались такие шаги (думаю, в таком порядке, как они перечислены дальше): DNSSEC на клиентах (года два на выполнение), строгое подписывание анонсов BGP и криптографическое удостоверение AS-ок (три-пять лет), переход подавляющей части трафика на IPv6 (пять-семь лет). А может даже и раньше.

Интересно сравнить с реальностью в 2025 году.

DNSSEC на клиентах

Да, тут было очень активное движение в обозначенную сторону. Сделали плагины для браузеров, например. Даже сперва всё уложилось в те самые два года, но, к сожалению, распространения не случилось и постепенно тема замылилась, пусть и не погасла совсем. То есть, что уж там в 2012, но сказать, что DNSSEC повсеместно внедрена на клиентах даже в 2025 году, конечно, нельзя: ландшафт тут вообще перекосило в другую сторону (см. ниже), а технология-то DNSSEC и в DNS-зонах не получила распространения, куда уж там клиентам.

Однако настроить клиентскую поддержку всё же можно, да и движение с переносом валидации на клиента, пусть и самое минимальное, но пока сохраняется: см. например, systemd-resolved в современных линуксах. Что ещё по этой теме есть сейчас? Ну, в те же браузеры собственный интерфейс “DNS-резолвинга” таки встроили, но это DNS over HTTPS/DNS over TLS, где проверка DNSSEC оставлена внешнему провайдеру. Это не очень-то хорошо, но что же поделать? Как минимум, TLS тут даёт какой-то инструмент для трансляции доверия. В общем, если вычесть всякие технологические оговорки, массовое внедрение “DNSSEC на клиентах” не случилось, сейчас его нет, так что прогноз про два года, строго говоря, не оправдался. Да и DNSSEC, из-за своей хрупкости, вообще не пользуется спросом в непростое время сегментации интернетов.

Строгое подписывание анонсов BGP и криптографическое удостоверение AS

“Подписывание анонсов” – это имеется в виду “сквозной” и строгий вариант sBGP, когда каждый “хоп” ставит проверяемую подпись. Не случилось. Подвижки тут тоже есть (BGPsec, SIDR Ops и др.), но пока даже нет причин говорить, что реализация как-то близка. Причины банальные, как ни странно: мало кому это нужно; как и в случае с DNSSEC – технология хрупкая, это многих пугает; большой риск централизации – тоже не особо хорошо в ситуации, когда идёт битва за банхаммер.

Сейчас одна деятельная сторона, – которая есть исторически сложившаяся, старая часть основателей интернетов, – укрепляется во мнении, что “это наша сеть, в которую мы если разрешаем подключиться кому-то ещё, то только тем, кто себя ведёт так, как мы считаем правильным, и при этом не топчет мрамор пола пусть и чистыми, но всё равно же – лаптями”, а главное – сохранить возможность разрешать подключение на основании детектирования типа обуви. Другая деятельная сторона – ещё хитрее: эта сторона использует глобальность Сети для создания собственных “больших интранетов”, чему немало способствует деятельность стороны первой: потому что вы не можете строить локальный сегмент, когда нет нужной глобальности, относительно которой сегмент и определяется, как локальный. В общем, битва кита со слоном и океан замутила, и на суше подняла пыль: ситуация в целом не очень-то хорошая складывается, так что не до подписывания анонсов BGP. Подписывания нету, и в этой части – прогноз не сработал совсем.

Зато вот с “криптографическим удостоверением AS”, которое есть RPKI (удостоверение при помощи цифровой подписи права быть источником (origin) для IP-префикса), прогресс за пятнадцать лет очень большой: поддержка RPKI для IP-префиксов не только перестала быть исключительной редкостью на стороне AS, но даже и для фильтрации реально используют (но не все, не везде). Вероятно, так случилось потому, что RPKI – несколько более централизованная технология. Так что в этой части, хоть и не через “три-пять” лет, но прогноз близок к реальности.

IPv6 как транспорт для подавляющей части трафика

Тут я уже осторожно указал дистанцию в пять-семь лет по времени, и через пятнадцать лет у нас трафик по IPv6 в Интернете большой, но не подавляюще большой. Популярность IPv6 выросла очень сильно, факт, но этот протокол “всё ещё продолжает идти на смену IPv4” (как вы знаете, адреса для последнего за это время успели закончиться раз пять или семь, как раз по числу лет в интервале ожидания моего прогноза). В общем, нельзя сказать, что совсем не сработал этот прогноз – использование IPv6, как и количество передаваемого по этой версии IP-трафика, в 2017 году относительно 2010 возросло в разы, а ещё больше – сейчас, в 2025. Однако не похоже, что прогноз сработал полностью: для dxdt.ru всё ещё нет AAAA-записи (но есть один авторитативный NS с AAAA).

Интернет сильно поменялся. Особенно, за пять лет периода 2020-2025. Но эта записка посвящена ретроспективе заметок dxdt.ru, так что обсуждение прочих изменений – оставим для других записок.