Hello tories, after reading this mail I started to upgrade my two tor nodes which ran stable for years. I never have seen my tor process disappearing from the process list. Unfortunamtely, after upgrading to 2.2.34 on both nodes tor is crashing within a short time. I started tor in debug mode sending its debug log into a file. The crash always happens at the same point. root@h1896303:/chroot/tor/log# tail debug.log.2 Nov 01 19:52:13.842 [debug] connection_or_process_cells_from_inbuf(): 129: starting, inbuf_datalen 512 (0 pending in tls object). Nov 01 19:52:13.842 [debug] relay_lookup_conn(): found conn for stream 62648. Nov 01 19:52:13.843 [debug] circuit_receive_relay_cell(): Sending away from origin. Nov 01 19:52:13.843 [debug] connection_edge_process_relay_cell(): Now seen 239 relay cells here (command 2, stream 62648). Nov 01 19:52:13.843 [debug] connection_edge_process_relay_cell(): circ deliver_window now 999. Nov 01 19:52:13.843 [debug] connection_or_process_cells_from_inbuf(): 129: starting, inbuf_datalen 0 (0 pending in tls object). Nov 01 19:52:13.843 [debug] conn_read_callback(): socket -1 wants to read. Nov 01 19:52:13.843 [debug] fetch_from_buf_http(): headerlen 186, bodylen 0. Nov 01 19:52:13.843 [debug] directory_handle_command_get(): Received GET command. Nov 01 19:52:13.843 [debug] directory_handle_command_get(): rewritten url as '/tor/status-vote/current/consensus/14C131+27B6B5+49015F+585769+805509+D586D1+E8A9C4+ED03BB.z'. My tor runs in a chrooted environment. Together with tor I upgraded libevent to the latest release (2.0.15). Any ideas? Where can I start searching the bug? Thanks for any hint in advance Thomas Am Freitag, 28. Oktober 2011 schrieb Roger Dingledine: > Tor 0.2.2.34 fixes a critical anonymity vulnerability where an attacker > can deanonymize Tor users. Everybody should upgrade. > > The attack relies on four components: 1) Clients reuse their TLS cert > when talking to different relays, so relays can recognize a user by > the identity key in her cert. 2) An attacker who knows the client's > identity key can probe each guard relay to see if that identity key > is connected to that guard relay right now. 3) A variety of active > attacks in the literature (starting from "Low-Cost Traffic Analysis > of Tor" by Murdoch and Danezis in 2005) allow a malicious website to > discover the guard relays that a Tor user visiting the website is using. > 4) Clients typically pick three guards at random, so the set of guards > for a given user could well be a unique fingerprint for her. This > release fixes components #1 and #2, which is enough to block the attack; > the other two remain as open research problems. > > Special thanks to "frosty_un" for reporting the issue to us! (As far > as we know, this has nothing to do with any claimed attack currently > getting attention in the media.) > > Clients should upgrade so they are no longer recognizable by the TLS > certs they present. Relays should upgrade so they no longer allow a > remote attacker to probe them to test whether unpatched clients are > currently connected to them. > > This release also fixes several vulnerabilities that allow an attacker > to enumerate bridge relays. Some bridge enumeration attacks still > remain; see for example proposal 188. > > https://www.torproject.org/download/download > > Changes in version 0.2.2.34 - 2011-10-26 > o Privacy/anonymity fixes (clients): ... ...
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ tor-talk mailing list tor-talk@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk