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

Cloudflare опубликовали разбор ситуации, приведшей 18 ноября к глобальному падению сервисов. Оказалось, это не маршрутизация, как я предположил в прошлой записке, а просто – “слишком большой конфигурационный файл”.

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

Только вчера упоминал несколько раз Cloudflare в своём докладе на Пиринговом форуме – и уже сегодня “веб-фронт” и другие сервисы Cloudflare надолго упали по всему миру (на момент написания этой заметки – ещё не поднялись). Скорее всего, это опять маршрутизация, как ни странно.

Один из самых активных ИИ-ботов сейчас на dxdt.ru – это “Meta-ExternalAgent”, который приходит с IP-адресов Facebook. А IP-адресов у Facebook очень много. Я настроил для этого бота редирект на специальную страницу, однако он всё равно продолжает повторно приходить, выполняя тысячи GET-запросов в сутки. Больше всего удивляет то, что эти штуки приходят раз или два в сутки, повторно, на одни и те же URL, содержание которых не менялось по десять и более лет. Казалось бы, в “обучении нейросети” можно использовать текст повторно, однако для этого не нужно повторно скачивать тот же текст с исходного сервера. Но нет. (Ну, то есть, формально – текст по URL мог поменяться, конечно, но всё же.)

Пишут про метод, позволяющий обнаружить характер сообщений, которыми обмениваются пользователи с LLM через интерфейсы, использующие TLS. Там нет никакой уязвимости TLS, а речь идёт про анализ метаинформации о соединении: свойства потока TLS-пакетов, выдаваемых интерфейсом LLM, коррелируют с потоком токенов, генерируемых моделью; соответственно, зная примерные характеристики потоков токенов, выдаваемых по “чувствительным темам”, можно попытаться обнаружить факт обсуждения таких тем по TLS-трафику. Это давно известная особенность TLS-соединений. Работает не только для LLM, но и для прочих веб-интерфейсов приложений.

Процитирую фрагмент по этой теме из моего технического описания TLS:

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

Сейчас почти весь TLS-трафик в вебе, защищённый криптосистемами с постквантовой стойкостью, использует для согласования симметричных ключей гибридную криптосистему X25519MLKEM (X25519+ML-KEM). Что здесь означает термин “гибридная”? А означает он, что объединяются секреты, полученные в результате работы двух криптосистем: ML-KEM и X25519. Возможны сочетания ML-KEM с привычными вариантами ECDH – логика их устройства такая же, как и в случае X25519, поэтому дальше, в качестве примера, используется только X25519.

Итак, X25519MLKEM это не какая-то особенная криптосистема, в которой “объединяются X25519 и ML-KEM”, а всего лишь указание на параллельное использование пары криптосистем, где объединяются не криптосистемы, а их вывод – общие секреты сторон. Причём, даже это объединение выполняется самым простым способом: байты, выведенные ML-KEM, дописываются к байтам, выведенным X25519. Желаемую постквантовую стойкость обеспечивает часть ML-KEM. Минимальная практическая взаимосвязь реализаций двух криптосистем тут возможна разве что на уровне генератора (псевдо)случайных чисел и хеш-фунций (но при этом ML-KEM использует SHA-3/SHAKE256).

Таким образом, в сильно гипотетическом случае появления квантового компьютера, пригодного для криптоанализа, стойкость подобных гибридных ключей всего лишь упадёт в два раза, если считать по битовой разрядности: квантово-компьютерный атакующий сможет вычислить секрет X25519.

Гибридный подход требует выполнения операций двух криптосистем в каждом сеансе получения симметричных секретных кючей. То есть, буквально, нужно выполнить все шаги X25519 (сформировать и отправить открытый ключ, получить открытый ключ второй стороны, вычислить общий секрет) и все шаги ML-KEM (сформировать открытый ключ, сформировать шифротекст на другой стороне соединения, передать/прочитать шифротекст и вычислить секрет на принимающей стороне). Несмотря на то, что конкретно TLS позволяет переиспользовать выдачу X25519 в одной сессии, всё равно гибридизация выглядит перегруженной.

Зачем же тогда нужен гибрид? Базовая причина довольно простая: подстраховать ML-KEM на тот случай, если данная криптосистема окажется очень уязвимой для классических атак. Проще говоря, сломают именно алгоритм ML-KEM. Вообще, идея внедрения постквантовой криптографии довольно старая (это может показаться контринтуитивным, но криптосистемы с постквантовой стойкостью появились даже раньше, чем был предложен квантовый алгоритм Шора для взлома других криптосистем). Эксперименты с практическим внедрением новых криптосистем в TLS тоже проводились раньше, до появления стандарта на ту же криптосистему ML-KEM.

Например, в 2019 году Cloudflare совместно с Google Chrome испытывали сочетание SIKE и X25519 (эксперимент CECPQ2b), где постквантовую стойкость относили на счёт криптосистемы SIKE. Однако использованная версия SIKE оказалась недостаточно стойкой к классическим атакам. Так что, не будь в составе того эксперимента X25519, которая пока сохраняет свою стойкость, все TLS-сессии, установленные в рамках эксперимента с SIKE, были бы сейчас скомпрометированы постфактум (если, конечно, их кто-то записал). Квантовый компьютер для этого не потребовался бы. Такая же ситуация возможна и для ML-KEM (пусть ML-KEM и использует другой, относительно SIKE, математический аппарат).

Однако соответствующий стандарт NIST на ML-KEM никакой гибридизации с “классической” криптосистемой не требует: почему-то считается, что данная криптосистема имеет достаточную “классическую стойкость”. Тут необходимо отметить, что никто, естественно, не гарантирует стойкость ML-KEM. Оценка стойкости криптосистем в целом, и асимметричных криптосистем в частности, представляет собой дисциплину, наполненную эвристикой, предположениями и “допусками” при моделировании. С сугубо теоретической точки зрения не известно, возможны ли в принципе стойкие криптосистемы кроме единственной абсолютно стойкой (шифр Вернама), в которой длина секретного ключа равна длине сообщения. Так что для практических криптосистем лишь предлагаются оценки стойкости, взятые в некоторой модели вычислительных ресурсов. А потом появляются всё новые и новые атаки, понижающие предложенные оценки.

Конечно, именно поэтому никто не может гарантировать, что завтра не будет полностью взломана и X25519 – классическая часть гибрида с ML-KEM. Но, всё же, ML-KEM и более новая, и использует другой математический аппарат. А X25519 уже успешно и массово работает десятилетиями, а эффективных атак пока выявлено не было. Как бы там ни было, но один факт не вызывает сомнений: две независимых криптосистемы, – обычно, – лучше, чем одна.

Кроме теоретических аспектов, важны и практические: для той же ML-KEM требуется новая реализация, в которой много других алгоритмов, по сравнению с X25519 (или каким-то ещё вариантом ECDH). Новая реализация – это всегда новые дефекты и уязвимости именно в реализации, без учёта самого математического алгоритма. То есть, если использовать только ML-KEM – практически гарантированы новые критические ошибки, которых уже нет во второй части гибрида – в X25519. Более того, части ошибок реализации в X25519 просто и не может быть, потому что там другая математика.

Считается, что ML-KEM защищает от криптоанализа на гипотетическом квантовом компьютере. Очевидно, если бы подходящий квантовый компьютер появился, то использование гибридной пары с X25519 тут же потеряло бы смысл, так как эта криптосистема оказалась бы взломана. Чем не обоснование для отказа от гибрида? Но ведь этого квантового компьютера ещё нет и на горизонте! Так что обосновывать этим гипотетическим событием отказ от гибридных криптосистем на практике – несколько странно. Особенно, если учитывать, что никто не отменял классических атак на ML-KEM, и они пока что выглядят куда более реальными, чем квантовый компьютер для криптоанализа.

И тем не менее: стандарты – не требуют гибридов, а в IETF уже есть черновики RFC, описывающие “чистое” использование той же ML-KEM в TLS 1.3.

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, конечно, будет сложнее.