Нет, identity key узла так-же находится в памяти, именно им подписывают дескриптор, обновляемый не реже чем раз в 18 часов.


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

Тикет с описанием и ссылками на появившиеся проблемы доверия к DA.

В рассылке пишут другое. Рекомендуют пересоздавать все ключи. Роджер вроде как не возражает.

Читайте все темы, там много интересных вопросов, типа:

• После удаления всех ключей узлы становятся новыми с чистой историей — если всем сделать это одновременно — пропускная способность Tor-сети рухнет?
• А если всем быстро раздать стабильные флаги заново, не может ли противник ввести массу левых узлов, воспользовавшись ситуацией?
• А те, кто неумышленно или злонамеренно не апгрейдятся, будут иметь большой аптайм и повышенную пропускную способность в статистике и при этом подвергать опасности пользователей, причём перетянув на себя большее их количество, чем пропатченные узлы?
• А может такие узлы сканить и банить в статистике принудительно, наплевав на скорость сети, безопасность важнее?
• А толку сканить тех, кто обновил OpenSSL, но не стёр старые ключи — они могут быть скопрометированы, но просканить их уже нельзя?
• А не выпустить ли новую версию Tor, которая всем принудительно сотрёт старые ключи, а всех остальных выкинуть из статистики?
• А чем пользователи oldstable Debian/Squeezy и FreeBSD провинились — у них же неуязвимая OpenSSL?
• А если они себе OpenSSL бэкпортили более новую?
• А если кто-то (пере)создал ключи случайно накануне, ещё на бажной версии OpenSSL, а затем обновился, но ключи не обновил — ими можно пренебречь? И т.д., и т.п.

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

Так что делать с Tor нодами? У меня их много, и трафик терять неохото.

Шнайер:

Heartbleed is a catastrophic bug in OpenSSL:

<...>

"Catastrophic" is the right word. On the scale of 1 to 10, this is an 11.

Белловин:

[S]ome people are claiming that open source software is inherently more secure:

<...>

Not so. What matters is that people really look, and not just with their eyes, but with a variety of automated static and dynamic analysis tools.

Secure systems require more than that, though. They require a careful design process, careful coding, and careful review and testing. All of these need to be done by people who know how to build secure systems, and not just write code. Secure programming is different and harder; most programmers, however brilliant they may be, have never been taught security. And again, it's not just programming and it's not just debugging; design — humble design — matters a great deal.

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

jabber.no:5223 IS VULNERABLE.

По этому тесту.

Тесты могут быть глючными в обе стороны: false positive/negative.

Интервью с Верном Паксоном из ICSI

Это означает, что уязвимость еще как минимум пару лет будет работать на тех, кто может ей воспользоваться. А еще пару лет до этого ей, очевидно, уже активно пользовались – реальный ущерб нам только предстоит узнать.

Поэтому главный вопрос сегодня: не почему Heartbleed был пропущен, а почему его так долго не замечали специалисты Google?

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

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

Шок и расследование интриг.
Публикация информации об уязвимости лишь PR акция Microsoft по прикрытию тылов в связи EOL WinXP.

Это их худые черти бермудят воду во пруду
Это все придумал Черчиль в 18-ом году
Мы про взрывы, про пожары сочиняли ноту ТАСС,
Но примчались санитары и зафиксировали нас

Пишут, что Dr.Seggelmann жив здоров, и вроде как всё ещё в Германии. "Ошибка, просто ошибка" — сказал доктор.

SSH Communications Security Comments on Heartbleed Vulnerability:

SSH Communications Security’s products are not affected by the Heartbleed flaw.

Heartbleed does not impact the safety of the Secure Shell protocol itself. However, web servers and other hosts typically run both OpenSSL and Secure Shell. This means that if an attacker is able to gain access to the system’s memory, it is possible to steal Secure Shell authentication credentials.

Because Heartbleed permits an attacker to gain direct access to the host’s memory, it should be assumed that all Secure Shell authentication credentials stored on the affected host may have been compromised.

Once affected systems have been patched, organizations should immediately rotate any Secure Shell keys and change Secure Shell passwords stored on those systems. Potentially-affected systems with stored Secure Shell user keys (either public or private user keys) should have those credentials rotated (i.e., replaced) with new keys.

Any delay in rotating Secure Shell authentication credentials could enable an attacker to yet again access the system or utilize Secure Shell authentication credentials to compromise other network systems and applications.

Heartbleed may have allowed attackers to create back doors into critical systems. It is critical that organizations monitor their environments for any anomalous activity.

Т.е., если на одном узле были запущены https-сервер + SSH или Tor + SSH, или [что-то]-SSL + SSH, то подключившись к [что-то]-SSL, можно выкрасть и ключи SSH? Поскольку оба процесса — и неуязвимый SSH, и уязвимый процесс одновременно используют SSHSSL-либу?

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

36creative.com
abescrow.com
activetrans.org
anonfiles.com
app.anatomyone.com
bermanhosting.com
bitbandit.eu
bitchirp.org
block122.com
blog.ageispolis.net
breakwall.net
cdn.anonfiles.com
chatkom.com
chipinforthesalvos.com.au
coinb.in
coupondoc.com

против http://possible.lv/tools/hb/?domain=


И что мы можем?

* Утянуть cert, и поднять в локалке ни чем не отличающийся домен?
* Снифать ssl, и вскрывать?

?

Я не понимаю, почему Шнайер пишет об 11 из 10.


@unknown, как определить?

Поскольку оба процесса — и неуязвимый SSH, и уязвимый процесс одновременно используют SSH-либу?

s/SSH-либу/SSL-либу/
Да, этого можно было ожидать. Видимо, исключением могут быть только маловероятные ситуации типа статической линковки ssh или, напротив, веб-сервера с openssl, т.е. когда ssh и другие службы не используют одновременно один и тот же исполняемый код openssl.