LINUX.ORG.RU

Это RIP для всех. Надеюсь, что-нибудь придумают.

anonymous
()

Это нет слов как серьезно для линуксоида (и не только)

The Consequences

We've known for a decade this attack is possible. It's now here and it's devastating. There are a few major takeaways and all of them are bad.

If you fetch a poisoned certificate from the keyserver network, you will break your GnuPG installation. Poisoned certificates cannot be deleted from the keyserver network. The number of deliberately poisoned certificates, currently at only a few, will only rise over time. We do not know whether the attackers are intent on poisoning other certificates. We do not even know the scope of the damage.

That last one requires some explanation. Any certificate may be poisoned at any time, and is unlikely to be discovered until it breaks an OpenPGP installation.

The number one use of OpenPGP today is to verify downloaded packages for Linux-based operating systems, usually using a software tool called GnuPG. If someone were to poison a vendor's public certificate and upload it to the keyserver network, the next time a system administrator refreshed their keyring from the keyserver network the vendor's now-poisoned certificate would be downloaded. At that point upgrades become impossible because the authenticity of downloaded packages cannot be verified. Even downloading the vendor's certificate and re-importing it would be of no use, because GnuPG would choke trying to import the new certificate. It is not hard to imagine how motivated adversaries could employ this against a Linux-based computer network.

Это катастрофа.

dexpl ★★★★★
()

Если всё так плохо, где бугурт в моих интернетах? Да хотя бы новости на лоре и опеннете?

TheAnonymous ★★★★★
()

TL;DR

Кто-то запихнул 150000 подписей (предельно допустимое количество для SKS) в сертификат автора и загрузил на публичный сервер, gnupg и прочие реализации превращаются в тыкву при попытке это всё валидировать

Harald ★★★★★
()

Бекапим ключики и обменивается при личной встречи.

Ух как плохо, прижимают наши интернеты.

Много дистров на gpg завязывают свои обновления?

Есть ещё signify от OpenBSD.

Будем как всегда, ключами обмениваться при личных встречах на GPG вечеринках.

gpg --armor --export --output my_current_pgp_public_keys.pub
anonymous
()

Это-же какой-то адовый адокъ просто. Надеюсь, проблему начнут решать немедленно. Странно, что об этом сейчас не пишут на каждом новостном портале.

DawnCaster ★★
()
Последнее исправление: DawnCaster (всего исправлений: 1)

Много дистров на gpg завязывают свои обновления?

Достаточно много. Не уверен, правда, что они все пользуются публичными серверами ключей.

DawnCaster ★★
()
Последнее исправление: DawnCaster (всего исправлений: 1)
Ответ на: комментарий от DawnCaster

У них всех множество каналов распространения ключей для подписи пакетов. Все, кажись, используют, как вариант (например первичный) публичные серверы ключей.

В тоже время основным каналом распространения новых публичных ключей есть сама система распространения пакетов дистрибутива. Причём не только своих ключей, так Gentoo точно распространяет ключи: Kali Linux, Debian, Ubuntu, Arch. Возможно другие дистры поступают также, возможно даже есть между ними договорённость о распространении ключей друг друга.

Особняком выделяется OpenBSD с signify.

anonymous
()
Ответ на: комментарий от anonymous

Все, кажись, используют, как вариант (например первичный) публичные серверы ключей.

Вот тут и может трындец случиться, если кто-нибудь испортит ключ дистрибутива.

В тоже время основным каналом распространения новых публичных ключей есть сама система распространения пакетов дистрибутива.

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

DawnCaster ★★
()

Скоты хотят испортить алгоритмы и базы ключей чтобы людям жизнь усложнить! Видать скотам они теперь сильно мешать начали, остальное посетители, очередь дошла до GPG...

Не надо трогать сервера!

Не надо прикасатся к алгоритмам!

Не надо прикасатся к базам ключей!!!

Надо увеличить максимальное число подписей ключа до 150 000 всего у одной клиентской программе - gnupg !

anonymous
()

Не надо трогать сервера ключей и их ПО!

Не надо прикасатся к алгоритмам обмена и верификации ключей!

Не надо прикасатся к базам хранения ключей!!!

Надо увеличить максимальное число подписей ключа до 150 000 всего у _одной_ программе - gnupg !

Проблему рассматривать как _возможные_ временные трудности _только_ у пользователей программы _gnupg_.

anonymous
()
Ответ на: комментарий от anonymous

Юзер повесится, пока будет проверяться валидность 150000 подписей ключа. Атака не на сервера, а на пользователей.

anonymous
()
Ответ на: комментарий от anonymous

А нельзя просто проверять сколько подписей активно? Желательно на сервере (потому что это очевидно злонамеренное поведение), а потом уже можно и на клиенте добавить разумные лимиты на случай старых серверов.

anonymous
()
Ответ на: комментарий от anonymous

Не надо трогать сервера ключей и их ПО!
Не надо прикасатся к алгоритмам обмена и верификации ключей!
А нельзя просто проверять сколько подписей активно? Желательно на сервере

Где-то здесь противоречие.

anonymous
()
Ответ на: комментарий от anonymous

Можно проверять на другом сервере перед отправкой серверу чтобы сервер защищал сервер от атак на сервере.

anonymous
()

Эт задница. Для всех. Оптом.

Deleted
()
Ответ на: комментарий от anonymous

Юзер повесится, пока будет проверяться валидность 150000 подписей ключа. Атака не на сервера, а на пользователей.

Засланник товарища майора, попрошу не вводить в заблуждение необразованных!

Атака не на сервера ключей! Атаки как таковой нет... Есть проблема в том, что сервера ключей поддерживают аж 150 000 подписей одного ключа, а ВСЕГО ОДНА ПОЛЬЗОВАТЕЛЬСКАЯ ПРОГРАМА — GNUPG такого числа подписей одного ключа не поддерживает.

Решение проблемы - увеличить в GNUPG число поддерживаемых подписей одного ключа до 150 000.

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

Но проблема есть только в одном клиенте, и только в одном его параметре!

Надо просто увеличить до 150 000 число подписей одного ключа в gnupg.

Больше ничего трогать и ни к чему прикасаться не надо!!!

anonymous
()
Ответ на: комментарий от anonymous

Не надо трогать сервера ключей и их ПО!

Не надо прикасатся к алгоритмам обмена и верификации ключей!

Слова анонима в ответах:

SKS Keyserver Network Under Attack (комментарий)

SKS Keyserver Network Under Attack (комментарий)

А нельзя просто проверять сколько подписей активно? Желательно на сервере

Вопрос другого анонима:

SKS Keyserver Network Under Attack (комментарий)

Где-то здесь противоречие.

Это твой вымер. Противоречия в предыдущих постах нет!

anonymous
()
Ответ на: комментарий от anonymous

А нельзя просто проверять сколько подписей активно? Желательно на сервере (потому что это очевидно злонамеренное поведение), а потом уже можно и на клиенте добавить разумные лимиты на случай старых серверов.

Вот как скотам хочется засунуть трояна на сервера обрабатывающие верификации ключей!

К серверам не прикасаться!

К алгоритмам добавления и верификации ключей не прикасаться!

К базам ключей не прикасаться!

Чем больше подписей имеет один ключ тем лучше! Лимит в 150 000 подписей нигде уменьшать не надо!

Надо, только в одной, программе - gnupg, увеличить лимит до 150000 подписей на один ключ.

И БОЛЬШЕ НИЧЕГО НЕ ДЕЛАТЬ!!!!!!!!!!!!!!

anonymous
()
Ответ на: комментарий от anonymous

Чем больше подписей имеет один ключ тем лучше! Лимит в 150 000 подписей нигде уменьшать не надо!
Надо, только в одной, программе - gnupg, увеличить лимит до 150000 подписей на один ключ.

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

Проблема в самой возможности давать кому угодно подписывать чьи угодно ключи. Увеличение лимита в GPG никак не исправит ситуацию, потому что остаются следующие фундаментальные возможности подгадить:

1) Заполнить все допустимые 150 000 подписей - спамом. Такие ключи не увеличивают доверия, и не несут смысла. Зато если лимит заполнен - добавить осмысленные подписи от реальных людей будет нельзя.

2) Проверка 150000 подписей в GPG при обращении к ключам - будет вызывать нехилые тормоза. Особенно обидно, что будет тратится время на обработку бессмысленных подписей.

3) Загадив спамом значительное число ключей, можно раздуть объемы баз данных до невменяемых значений.

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

DawnCaster ★★
()
Последнее исправление: DawnCaster (всего исправлений: 1)
Ответ на: комментарий от DawnCaster

https://lists.gnupg.org/pipermail/gnupg-announce/2019q3/000439.html

Вот скоты и похерили Gnupg!

Объясняю что произошло, для тех кто не в теме.

С помощью серверов ключей можно верифицировать локальное хранилище ключей. Работает оно по такому алгоритму: Вася дал тебе в руки свой публичный ключ, ты ключу Васи веришь и подписываешь его ключ своим ключом; Вася, встретил Вову (не Того, а хорошего) и Вова передал ему свой открытый ключ, Вася верт ключу Вовы и подписывает ключ Вовы; ты с сервера ключей импортирует ключ Вовы, чтобы верифицировать подписанную ключом Вовы прогу или зашифрованное к тебе письмо.... Так вот, импортированный ключ Вовы у тебя не доверительный, ты Вову не встречал и он тебе свой ключ не давал. Есть в gpg серверов такая киллер фича, как проверка базы доверительных ключей:

gpg --check-trustdb

Именно с помощью верификации базы доверительных ключей, ввиду того, что ты подписал ключ Васи, а Вася подписал ключ Вовы товарищу майору не удастся подменить при импорте ключ Вовы, а если товарищ майор и предпримет такую попытку (для MitM атаки), то этот факт легко обнаруживается тобой при помощи верификации базы ключей:

gpg --check-trustdb

В чем была создана искусственная проблема: максимальное количество подписей одного публичного ключа на серверах - 150 000, а в проге gnupg меньше, что вызвало проблемы только в gnupg. И следовало просто увеличить максимальное количество подписей одного ключа ТОЛЬКО В GNUPG до 150 000, как на серверах.

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

anonymous
()
Ответ на: комментарий от anonymous

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

Не надо искать заговор там, где просто глупость. GNU-шники как всегда посчитали себя самыми умными и сказали: «Ну на фига 150k? Ненужно! Азаза!»

Вот теперь жрите свободу ложками, смотрите не обляпайтесь.

mandala ★★★★★
()
Ответ на: комментарий от DawnCaster

Проблема в самой возможности давать кому угодно подписывать чьи угодно ключи.

Это требование гарантии анонимности!

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

anonymous
()
Ответ на: комментарий от mandala

Не надо искать заговор там, где просто глупость. GNU-шники...

Есть такое понятие как «юриздикция», так вот организация GNU находится в юрисдикции США. К ним подошли и попросили так, что GNU-шники отказать не смогли. Заговор это? Да сегодня это можно считать уже нормой.

Почему разрабы OpenBSD со своей крыптографией сидят в Канаде, а с США сбежали?

anonymous
()
Ответ на: комментарий от anonymous

товарищу майору не удастся подменить при импорте ключ Вовы

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

anonymous
()
Ответ на: комментарий от anonymous

Ну и к чему ты вспомнил экспортные ограничения на криптографию, которые давно смягчили практически в ноль? (оставили только ограничения для разных чучхе и им подобных).

И зачем им подходить, у них столько ресурсов что они весь трафик тупо сохраняли, пока не поняли что с таким объемом им тупо не справиться.

Из не давнего про их арсенал: отказались предоставить суду данные как поймали педобира, который сидел через тор-браузер. Лисоводы тогда возбудились – это ж зеро-дырка скорее всего в лисе самой. так и пришлось суду педобира отпустить.

И ты считаешь что им стоит рисковать давить на кого то? Зачем? Когда можно все сделать тихо и без лишнего шума.

mandala ★★★★★
()
Ответ на: комментарий от Deleted

Пиндосы вообще не хотели криптографическое ПО экспортировать разрешать. Со временем до них дошла бредовость их требований и поумерили пыл.

mandala ★★★★★
()
Ответ на: комментарий от anonymous

В чем была создана искусственная проблема: максимальное количество подписей одного публичного ключа на серверах - 150 000, а в проге gnupg меньше, что вызвало проблемы только в gnupg. И следовало просто увеличить максимальное количество подписей одного ключа ТОЛЬКО В GNUPG до 150 000, как на серверах.

Я уже выше написал. Проблема вообще не в максимальном количестве подписей одного публичного ключа. А в том что кто угодно может их проставлять и загружать на сервер.

Попробую объяснить на пальцах, пользуясь вашей-же анологией с Васей и Вовой:

Откуда-то из тумана появляется некий Лёха. Который страсть как не любит Вову. И до того как Вася успел поставить свою подпись Вове - он проставляет и загружает на сервер 150000 фейковых подписей Вове. После чего - Вася уже не может проставить и загрузить на сервер свою подпись для ключа Вовы, что-бы вы могли загрузить ключ Вовы с подписями и убедиться что Вася знает Вову а значит ему можно доверять.

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

И вы от безнадеги переходите к общению через бумажную почту, которую теперь уже 100% будет просматривать товарищ майор.

Достаточно понятно теперь ?

DawnCaster ★★
()
Последнее исправление: DawnCaster (всего исправлений: 1)

Мне предполагается простым и почти что очевидным, чтобы подписи к ключу мог выкладывать только владелец ключа.

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

anarquista ★★★★★
()
Ответ на: комментарий от mandala

Со временем до них дошла бредовость их требований и поумерили пыл.

Пыл поумерился не сам по себе, а из-за того, что конкуренты стали разрабатывать своё криптографическое ПО.

Это как с ядерной бомбой. Как только на Католийском холме поняли, что СССР в ответку может и долбануть, до них дошла бредовость их требований и они поумерили пыл.

Deleted
()
Ответ на: комментарий от anonymous

А по ссылке с чанджлогом - всё совсем не так плохо.

Инфраструктура серверов ключей сломана. Не скомпрометирована, а именно сломана - она содержит фатальный баг способный привести как сервер ключей так и вашу инсталляцию GPG в нерабочее состояние.

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

DawnCaster ★★
()
Ответ на: комментарий от anarquista

Мне предполагается простым и почти что очевидным, чтобы подписи к ключу мог выкладывать только владелец ключа.

И автор подписи будет управлять сетью доверия своей подписи. Централизация в квадрате - сервер ключей да еще каждый ключ контролируется автором.

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

Странная практика в ограничении подписывающего.
По идее у каждого должен быть свой «сервер» (клиент сети доверия), который выдает все подписанные им «публичные» документы. И каждый сам напрямую вытаскивает нужные ему подписанные документы из сети и обрабатывает в соответствии со своей логикой доверия. Естественно это будет сильно тормозить, но можно кешировать, вплоть до полной базы всех публичных подписанных документов на некоторый момент времени.

anonymous
()
Ответ на: комментарий от anonymous

И автор подписи будет управлять сетью доверия своей подписи.

И что в этом плохого? Ну, да, подписавший должен иметь возможность отозвать свою подпись.

anarquista ★★★★★
()
Ответ на: комментарий от anarquista

И автор подписи будет управлять сетью доверия своей подписи.

И что в этом плохого? Ну, да, подписавший должен иметь возможность отозвать свою подпись.

Это как «маразм» в виде авторского права, когда один (автор) управляет многими (читателями).

anonymous
()
Ответ на: комментарий от anonymous

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

anarquista ★★★★★
()
Ответ на: комментарий от anarquista

Аналогия не доказательство

Это аксиома? Посмотри на теорию категорий и доказательства на коммутативных диаграммах.

да, каждый человек имеет право распоряжаться плодами своего труда, в том числе и автор

«Имеет право». Если ты не можешь обеспечить выполнение этого права, то это пустые слова. Не надо «шизу» про права переносить на «дикий» мир. Сам же ввел аксиому про аналогии, сам же его нарушаешь.
Автор может как угодно распорядится «оригиналом». «Копия», сделанная другим, - это не плод его труда. Копия ключа, пописанная другим, не плод труда автора ключа.
Сеть на световых скоростях (интернет) хорошо подлечит «шизу» о правах, основанную на скорости звука в ограниченном пространстве.

anonymous
()
Ответ на: комментарий от anonymous

речь лишь о том, как не превратить сервер ключей в помойку. для этого достаточно следовать одному простому правилу: принимать подписи ключей только от владельца ключа.

anarquista ★★★★★
()
Ответ на: комментарий от anonymous

Если ты не можешь обеспечить выполнение этого права, то это пустые слова.

Во многих странах человек может обеспечить выполнение этого права, для этого есть специально обученные и оплаченные люди.

anarquista ★★★★★
()
Ответ на: комментарий от anarquista

Плоды получают посредники. Аффтар имеет копейки «с барского плеча» посредников.

Deleted
()
Ответ на: комментарий от anarquista

Во многих странах человек может обеспечить выполнение этого права, для этого есть специально обученные и оплаченные люди.

Они могут только избирательно на ограниченном пространстве обеспечить выполнение «этого права». За одно нап...еть владельцу «этого права», что «эти права» выполняются.
Сам-то хоть понимаешь, что ты в достаточно примитивный диалог «автор-читатель» внедряешь третьего, который как минимум превращает(усложняет) один диалог в 3 диалога. Кстати, MitM - это частный случай внедрения третьего в диалог.

anonymous
()
Ответ на: комментарий от anarquista

речь лишь о том, как не превратить сервер ключей в помойку.

Зачем нужен такой сервер ключей? Зачем нужны подписанные ключи на таком сервере, если нужно непосредственное общение автора и подписывающего без участия сервера? Зачем третий лишний?

anonymous
()
Ответ на: комментарий от mandala

Ну и к чему ты вспомнил экспортные ограничения на криптографию, которые давно смягчили практически в ноль? ....

Ой, там все сложнее. Изначально в США были очень жёсткие экспортные ограничения разного типа:

1. Гос запрет, сегодня он есть тоже.

2. Запрет не государства, а юрлиц, через патенты.

На алгоритмы криптографии с использованием открытого и закрытого ключа действовали оба запрета.

Европа не имела таких ограничений и по этому разработку GnuPG решили делать в ЕС! Был парадокс, я очень интенсивно использовал gpg в начале 2000, хоть это нарушало кучу законов в США. Пользовались все, хоть gpg в США была нелегальной. Потом начали смягчать законы на экспорт дырявых, слабеньких алгоритмов. В конце 2к истёк строк патента на шифрование по открытому и закрытому ключу и gpg стал легален в США.

Сегодня за этой «атакой» на PGP стоят фашисты с БНД. Германия в ЕС хуже всех относится к анонимности и ненавидит всякие шифрования.

anonymous
()
Ответ на: комментарий от anonymous

нужно непосредственное общение автора и подписывающего без участия сервера? Зачем третий лишний?

Сервера ключей нужны:

1. Чтобы ты мог импортировать ключ человека с которым никогда не встретишся лично.

2. Мог криптографически верифицировать, что импортированных ключ действительно принадлежит ему, а не товарищу майору.

Для непосредственно общения двух людей сервера ключей не нужны.

SKS Keyserver Network Under Attack (комментарий)

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

anonymous
()
Ответ на: комментарий от anonymous

Чтобы ты мог импортировать ключ человека с которым никогда не встретишся лично.

От Васи я могу получить ключ Вовы, с которым я никогда не встречусь. Зачем мне ключ Вовы, подписанный ключом Васи, если и так получил этот ключ от Васи? Зачем тут вообще сервер?

Мог криптографически верифицировать, что импортированных ключ действительно принадлежит ему, а не товарищу майору.

Ничего ты не можешь верифицировать. Ты можешь довериться цепочке доверия, вот такая вот тавталогия получается - «довериться ... доверию». И в этой цепочке вполне может сидеть товарищь майор, которому доверяет Вася.

anonymous
()
Ответ на: комментарий от anonymous

От Васи я могу получить ключ Вовы, с которым я никогда не встречусь. Зачем мне ключ Вовы, подписанный ключом Васи, если и так получил этот ключ от Васи? Зачем тут вообще сервер?

1. С Вовой Вася мог встретиться позже, чем с тобой. Ты сначала встретился с Васей, получил Васин ключ. Потом Вася встретился с Вовой, подписал Вовин ключ. И только потом ты идёшь на сервер, чтобы скачать Вовин ключ, подписанный Васей. Тебе не нужно специально обращаться к Васе за Вовины ключом.

2. Через сервер тупо удобнее передавать ключи, чем непосредственно друг другу.

anarquista ★★★★★
()
Ответ на: комментарий от anarquista

1. С Вовой Вася мог встретиться позже, чем с тобой... <и тд и тп>

Сервер - это альтернативный вербальному канал связи с Васей (часть связи), которому ты доверяешь на основании уже состоявшейся вербальной связи, некоторые/многие даже без этого доверяют. Вместо сервера можно использовать любой другой способ связи, которому можно доверять. Это невербальная встреча с Васей.

2. Через сервер тупо удобнее передавать ключи, чем непосредственно друг другу.

«Тупо удобно» - это субъективная эмоционально окрашенная характеристика. И зависит от положения звезд и/или ограниченности инструментов, вроде gpg и сервера ключей.

anonymous
()
13 января 2021 г.
Ответ на: комментарий от anonymous

Именно с помощью верификации базы доверительных ключей, ввиду того, что ты подписал ключ Васи, а Вася подписал ключ Вовы товарищу майору не удастся подменить при импорте ключ Вовы, а если товарищ майор и предпримет такую попытку (для MitM атаки), то этот факт легко обнаруживается тобой при помощи верификации базы ключей:

Ты че чушь несешь ? Сам то докажи что не маиор и не у корыта корпорации сначала , а может ты обычный продовый воришка из копры

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.