[warn] Naming authorities disagree about nicknames for $C1D04F2F5E9A0FF9240638BE9805563C03A3D8CB ("PoderosoTorII" vs "PoderosoTorIII")
Вы бы не могли подсказать как понимать такой ворнинг и следует ли о чём-нить беспокоиться? Весь остальной вывод в норме.
Серверы в сети Tor идентифицируются своим долгоживущим identity ключём ($C1D04F2F5E9A0FF9240638BE9805563C03A3D8CB — хэш этого ключа). Символьное имя (PoderosoTorII) существует только для удобства. Этот Warning скорее всего значит что владелец ноды поменял имя своего сервера, а у некоторых DA (или в локальном кэше [?]) осталось старое (на некоторое время). А может быть Мэллори проводит свою атаку :)
Вот что есть у меня в логах :
Feb 12 11:16:21.052 [warn] Naming authorities disagree about nicknames for $C1D04F2F5E9A0FF9240638BE9805563C03A3D8CB ("PoderosoTorII" vs "PoderosoTorIII")
Feb 14 14:04:15.216 [warn] Naming authorities disagree about nicknames for $C1D04F2F5E9A0FF9240638BE9805563C03A3D8CB ("PoderosoTorII" vs "PoderosoTorIII")
Feb 11 14:20:48.089 [warn] Naming authorities disagree about nicknames for $C1D04F2F5E9A0FF9240638BE9805563C03A3D8CB ("PoderosoTorII" vs "PoderosoTorIII")
Feb 15 17:09:23.534 [warn] Naming authorities disagree about nicknames for $C1D04F2F5E9A0FF9240638BE9805563C03A3D8CB ("PoderosoTorIII" vs "PoderosoTorII")
Feb 18 14:22:21.155 [warn] Naming authorities disagree about nicknames for $C1D04F2F5E9A0FF9240638BE9805563C03A3D8CB ("PoderosoTorIII" vs "PoderosoTorII")
Feb 18 14:29:57.645 [warn] Naming authorities disagree about nicknames for $C1D04F2F5E9A0FF9240638BE9805563C03A3D8CB ("PoderosoTorIII" vs "PoderosoTorII")
Вероятнее всего владелец сервера поменял просто имя (а потом обратно).
Ну а если была атака, то и на меня тоже — такие же записи в логах. Все мы под колпаком :)
tor-0.2.0.35 на *nix-системе. Явных косяков при браузинге не подмечено. Используется в связке с Torbutton. Что могут значит строчки, содержащие такие слова как bug и error? Насколько они фатальны для анонимности? Свидетельствует ли это о каких-то злонамеренных действиях с чьей-либо стороны? Я указал всего несколько bridge'й в конфиге, а он, судя по логам, находит новые bridge'и и включает их в список сам?
Что могут значит строчки, содержащие такие слова как bug и error?
То, что Вам следует сообщить об этом в or-talk. Судя по сообщениям, Вы пытаетесь подключиться к hidden-ресурсу, но по какой-то причине не удаётся соединиться с rendezvous-узлом.
Наверное, лучше включить дебаг-уровень логов, и если проблема повторится вновь, выслать лог как багрепорт. Вышеприведённый кусок лога, имхо, малоинформативен для разработчиков.
Этож сервак CCC. Наверно откуда-то в куда-то террабайты таскали или генерировали, загудели по такому случаю, да и не заметили как сертификат истек.
Ну а клиент, бедный, знает что истекший == никакой, и двигает скачивать новый, да только на зеркалах всё то-же самое не обновленное, с истекшим сроком годности. И так всё по новой.
В такой ситуации главное, чтобы умные клиенты удовольствие растягивали во времени и не задосили сетку в усмерть, в порыве утоления жажды сертификатной, а пользователи расслабились. Ибо коллективного данненберга уже засыпали коллективными письмами и он уже выписал новый сертификат имени себя.
Конфигурация такова: компьютер-рутер A содинён с инетом через wifi и по езернету с компьютером B.
Дано:
На A стоит старый Linux 2.6.21.4 (Debian-based-дистр) и нет желания его обновлять.
На A в силу мудакнотости дистростроителей нет iptables и установить его — высокий риск порушить всю систему, т.е. не вариант.
На B нет wifi.
В силу слабой защищённости A, а также из-за кучи проблем с обновлениями всего Debian-подобного, сетевые tor/privoxy на A лучше не запускать.
Нужно: поднять на B соединение через Tor.
Раз нет iptables, трансляцию на A нативно (NAT) не сделать. Есть другие способы?
Было испробовано:
Попытался поднять privoxy на A, настроить его слушать только с локального езернет-адреса и подцепиться к ней с B — в итоге работает только бразуер, другие программы (tor, jabber, ssh через corkscrew) работать отказываются. Возможно, дело в старой privoxy (в логах прог пишется, что privoxy не дала сделать forward).
Поднять локальный socks на B через ssh от B до A (опция -D), и подцепить к нему локальную (та, что на B) privoxy с помощью той же строки в конфиге, какой она обычно связывается с Tor'ом — не работает, ругань на forward или почему-то пишет что privoxy убила такое соединение.
Поскольку tor умеет только http/https прокси, но никак не socks, последний способ был с его принудительной соксификацией через ssh посредством proxychains:
Т.е. поднимается локальный socks на B через ssh от B до A (опция -D), на который и цепляются все программы на B (127.0.0.1:8080). Firefox с таким соксом работает наура, tor запускается как
где конфиг proxychains:
и туннель
Конфиг тора:
После этого в логах tor при старте:
Т.е. не понятны причины происхождения 2х ворнингов:
(даже если я не менял системное время) и
Также, не ясно отчего соединение вдруг отваливается (смысл ворнинга ясен, причина — нет).
Трудно сказать, вызваны ли эти ворнинги проблемами в реализации proxychains, нестандартностью ssh socks или какими-то хитрыми бан-штуками самого ISP. Как-никак, но пол часа на старт тора, при том, что браузер напрямую просто летает — ненормально. Из-за закрытости портов оставил только бриджи с 443, но и из тех, судя по логам на A, работают лишь совсем немногие. Пытался отсортировать список бриджей в конфиге так, чтобы заведомо рабочие по netstat (с которыми иногда пишется ESTABLISHED) шли в конфиге первыми, но всё равно работает медленно и глючно. Сейчас добавил массу новых бриджей, теперь их 20 штук — если и сейчас будет работать глючно, не знаю на что и думать.
Ещё есть вариант пропустить весь трафик с B через NAT к удалённому хосту C, где всё работает (firewall, NAT и прочее), но ISP и блокировки на C те же, потому не стал делать (ожидаются жуткие тормоза по сравнению с прямым соединением в tor).
Удалось подцепить tor на A через privoxy на B, указав её tor'у как HTTPS-proxy. Почему оказалось некошерным обычное HTTP — так и осталось не ясным. Теперь работает более-менее стабильно. Спасибо всем откликнувшимся, кто помог.
Заметил, что стал писаться явный IP эксита в логах:
We tried for 15 seconds to connect to '[scrubbed]' using exit $XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX at <IP Exit-ноды>. Retrying on a new circuit.
Это ж не очень хорошо: писать в логи конкретные использованные экситы и соответствующие им моменты времени по умолчанию (уровень Log notice). Как Tor-разработчики на такое решились? Или стали исходить из того, что в TB всё равно на диск ничего не пишется, потому нет разницы?
Люди добрые, как это понимать? Разве статистика на check.torproject.org не самая актуальная? Появилось при одном из запусков TorBrowser, ничто не предвещало беды. IP, конечно же, не мой внешний.
Для тех, у кого картинка режется RefContolем: http://rghost.net/38271958/image.png
комментариев: 98 документов: 8 редакций: 10
Серверы в сети Tor идентифицируются своим долгоживущим identity ключём ($C1D04F2F5E9A0FF9240638BE9805563C03A3D8CB — хэш этого ключа). Символьное имя (PoderosoTorII) существует только для удобства. Этот Warning скорее всего значит что владелец ноды поменял имя своего сервера, а у некоторых DA (или в локальном кэше [?]) осталось старое (на некоторое время). А может быть Мэллори проводит свою атаку :)
Вот что есть у меня в логах :
А если без шуток, это возможно? Реальный-то ключ не меняется...
комментариев: 98 документов: 8 редакций: 10
Ну а если была атака, то и на меня тоже — такие же записи в логах. Все мы под колпаком :)
tor-0.2.0.35 на *nix-системе. Явных косяков при браузинге не подмечено. Используется в связке с Torbutton. Что могут значит строчки, содержащие такие слова как bug и error? Насколько они фатальны для анонимности? Свидетельствует ли это о каких-то злонамеренных действиях с чьей-либо стороны? Я указал всего несколько bridge'й в конфиге, а он, судя по логам, находит новые bridge'и и включает их в список сам?
комментариев: 11558 документов: 1036 редакций: 4118
То, что Вам следует сообщить об этом в or-talk. Судя по сообщениям, Вы пытаетесь подключиться к hidden-ресурсу, но по какой-то причине не удаётся соединиться с rendezvous-узлом.
Инет молчит на тему такого ворнинга. Что это могло бы значить, кто-нибудь в курсе?
Tor 0.2.1.20
Ну а клиент, бедный, знает что истекший == никакой, и двигает скачивать новый, да только на зеркалах всё то-же самое не обновленное, с истекшим сроком годности. И так всё по новой.
В такой ситуации главное, чтобы умные клиенты удовольствие растягивали во времени и не задосили сетку в усмерть, в порыве утоления жажды сертификатной, а пользователи расслабились. Ибо коллективного данненберга уже засыпали коллективными письмами и он уже выписал новый сертификат имени себя.
комментариев: 11558 документов: 1036 редакций: 4118
Конфигурация такова: компьютер-рутер A содинён с инетом через wifi и по езернету с компьютером B.
Дано:
- На A стоит старый Linux 2.6.21.4 (Debian-based-дистр) и нет желания его обновлять.
- На A в силу мудакнотости дистростроителей нет iptables и установить его — высокий риск порушить всю систему, т.е. не вариант.
- На B нет wifi.
- В силу слабой защищённости A, а также из-за кучи проблем с обновлениями всего Debian-подобного, сетевые tor/privoxy на A лучше не запускать.
Нужно: поднять на B соединение через Tor.Раз нет iptables, трансляцию на A нативно (NAT) не сделать. Есть другие способы?
Было испробовано:
Т.е. поднимается локальный socks на B через ssh от B до A (опция -D), на который и цепляются все программы на B (127.0.0.1:8080). Firefox с таким соксом работает наура, tor запускается как
где конфиг proxychains:
и туннель
Конфиг тора:
После этого в логах tor при старте:
Т.е. не понятны причины происхождения 2х ворнингов:
(даже если я не менял системное время) и
Также, не ясно отчего соединение вдруг отваливается (смысл ворнинга ясен, причина — нет).
Трудно сказать, вызваны ли эти ворнинги проблемами в реализации proxychains, нестандартностью ssh socks или какими-то хитрыми бан-штуками самого ISP. Как-никак, но пол часа на старт тора, при том, что браузер напрямую просто летает — ненормально. Из-за закрытости портов оставил только бриджи с 443, но и из тех, судя по логам на A, работают лишь совсем немногие. Пытался отсортировать список бриджей в конфиге так, чтобы заведомо рабочие по netstat (с которыми иногда пишется ESTABLISHED) шли в конфиге первыми, но всё равно работает медленно и глючно. Сейчас добавил массу новых бриджей, теперь их 20 штук — если и сейчас будет работать глючно, не знаю на что и думать.
Ещё есть вариант пропустить весь трафик с B через NAT к удалённому хосту C, где всё работает (firewall, NAT и прочее), но ISP и блокировки на C те же, потому не стал делать (ожидаются жуткие тормоза по сравнению с прямым соединением в tor).
Это ж не очень хорошо: писать в логи конкретные использованные экситы и соответствующие им моменты времени по умолчанию (уровень Log notice). Как Tor-разработчики на такое решились? Или стали исходить из того, что в TB всё равно на диск ничего не пишется, потому нет разницы?
Для тех, у кого картинка режется RefContolем: http://rghost.net/38271958/image.png