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

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

Значит, есть один ключ дистрибутива, которым автоматически подписывается всё, что происходит на сервере. И если этот ключ скомпрометирован, можно подменить любой пакет у любого пользователя. Раз подпись проставляется автоматически, всё держится только на том, что есть полное доверие серверу, что он не взломан. Чем тогда это лучше той же системы в BSD, где доверие софту строится на том, что в authorized_keys лежат правильные отпечатки для SSH-сервера, хранящего прикладной софт? Разве что тем, что постфактум можно ткнуть в валидную подпись пальцем, сказав «нет, это не меня взломали, а вас взломали»?

Она была им "вызвана": Valgrind ругнулся на неинициализированную переменную, которую и решили для порядку выкинуть.

Речь была про бандлы с браузером, где никакой автоматики, а не про deb-пакеты с tor демоном.

Ключи для подписи source code или ключи для репозитариев? (проект поддерживает репозитарии для deb и rpm совместимых)

Может это и оффтопик, но умелся ввиду ключ дистрибутива Linux-системы, которым подписываются все пакеты всех разработчиков. Так, с обновлениями, может не только Tor-демон, но и левое ядро прилететь, и левый gnupg, и что-угодно. Это чисто для сравнения ситуаций с DA.

А как её сверить? Простых способов нет. Если будут делать MITM на стороне хостера DA, то единственный, кто сможет заметить неладное — сам владелец DA, да и то чисто теоретически, т.к. его самого могут отмитмить и функции сервера подменить.

Это заметят все владельцы узлов Tor, которые получат левую статистику наравне с пользователями. Но, в отличие от пользователей, у них в логах будет масса ворнингов насчёт несовпадения параметров в собственном конфиге и тех, что приходят от эксплуатируемого DA.

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

2 /comment78568
Обсуждение перехода от старых версий FF к TBB перенесено в соотв. тему.

Анонимная сеть Tor вывела из работы около 600 шлюзов и ретрансляторов (relay), которые оставались уязвимыми к атаке Heartbleed. В связи с этим число узлов в сети Tor сократилось примерно на 10%. Вывод из строя узлов с неисправленной уязвимостью в OpenSSL обусловлен возможностью совершения атаки, которая может привести к утечке ключей шифрования и IP-адресов из памяти обслуживающего соединение процесса. Напомним, что уязвимость в клиентском ПО и базовых компонентах сети Tor была оперативно устранена в день обнаружения проблемы, но исправление проблемы в ретрансляторах, поддерживаемых добровольцами по всему миру, затянулось.
Дополнительно, отмечается наличие проблемы с утечкой ключей шифрования в VPN-сервисах на базе OpenVPN, развёрнутых на серверах с уязвимой версией OpenSSL. Если изначально данная проблема носила теоретический характер, то теперь подтверждена возможность проведения реальных атак по извлечению ключей шифрования в системах на базе OpenVPN. Операторам VPN-сетей рекомендуется оперативно обновить OpenSSL на подверженных уязвимости системах.

http://www.opennet.ru/opennews/art.shtml?num=39597

В Debian, кстати, пофиксили очередные дырки в OpenSSL. Ни по описанию, ни по ссылкам их смысл мне не особо понятен.

CVE-2010-5298

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

CVE-2014-0076

А про это вот такая работа есть:
Recovering OpenSSL ECDSA Nonces Using the FLUSH+RELOAD Cache Side-channel Attack
Но сам пока не читал :)

Анонимная сеть Tor wwwвывела из работы около 600 шлюзов...

Что-то не подтверждается. В Tor блоге ничего про это нет, и в статистике полным полно Tor нод с большим аптаймом и старой версией Tor.

Что-то не подтверждается.

Подтверждение.

полным полно Tor нод с большим аптаймом и старой версией Tor

И OpenSSL без этой ошибки.

Надо же, и тут соли Бернштейна хвалят:

The results of this work also support the theory of Walter [38] that smaller keys are more resilient to side-channel analysis. In this attack a higher proportion of the nonce can be obtained for larger key sizes. This implies that as we, naturally, transition to larger parameters in response to increasing computing capabilities, prevention of side-channel attacks should be incorporated into the implementation design, as is the methodology adopted by the authors of the NaCl cryptographic library [8]. // Заключение

I got the list from Sina's scanner

if they were still vulnerable as of yesterday, I really don't want this identity key on the Tor network even after they've upgraded their openssl.

Сканер же, наверно, не версию OpenSSL проверяет, а выполнимость heartbleed-атаки, так что всё ОК?