Opened 14 years ago

Last modified 2 years ago

#261 closed defect (Fixed)

getinfo orconn-status sometimes crashes

Reported by: goodell Owned by:
Priority: Low Milestone:
Component: Core Tor/Tor Version:
Severity: Blocker Keywords:
Cc: goodell Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Requesting 'getinfo orconn-status' from the Controller sometimes causes Tor to crash.
On most of my servers, this request consistently works normally, but on serifos, this
request seems to consistently cause the crash condition. I have no explanation, though
I suspect that perhaps some combination of high-volume client activity and high-volume
server activity is to blame. This is my test:

$ telnet localhost 9051
250 OK
getinfo orconn-status
Connection closed by foreign host.

The crash is violent, and there are no interesting error messages in the log.

The backtrace is as follows:

(gdb) bt
#0 0xb7ce8c73 in strlen () from /lib/tls/i686/cmov/
#1 0x080733f5 in handle_control_getinfo (conn=0xb4289cf0, len=<value optimized out>, body=0x8abe078 "orconn-status\r\n") at control.c:1415
#2 0x08075dde in connection_control_process_inbuf_v1 (conn=0xb4289cf0) at control.c:2185
#3 0x08075f59 in connection_control_process_inbuf (conn=0xb4289cf0) at control.c:2374
#4 0x08065efa in connection_process_inbuf (conn=0x0, package_partial=1) at connection.c:1918
#5 0x08068439 in connection_handle_read (conn=0xb4289cf0) at connection.c:1225
#6 0x08086769 in conn_read_callback (fd=186, event=2, _conn=0xb4289cf0) at main.c:383
#7 0xb7db5c79 in event_base_priority_init () from /usr/lib/
#8 0xb7db5f65 in event_base_loop () from /usr/lib/
#9 0xb7db5dcb in event_loop () from /usr/lib/
#10 0xb7db5cb0 in event_dispatch () from /usr/lib/
#11 0x080887d7 in tor_main (argc=0, argv=0x0) at main.c:1155
#12 0xb7c8feb0 in libc_start_main () from /lib/tls/i686/cmov/
#13 0x0804c5c1 in _start () at ../sysdeps/i386/elf/start.S:119

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Change History (5)

comment:1 Changed 14 years ago by arma

Not all conns have nicknames. Is the correct fix to use fingerprints in more places?

comment:2 Changed 14 years ago by arma

Oh. We already do the fingerprint thing when needed. More likely, the bug is that
non-open conns don't always have a nickname yet.

comment:3 Changed 14 years ago by arma

flyspray2trac: bug closed.

comment:4 Changed 8 years ago by nickm

Component: Tor ClientTor

comment:5 Changed 2 years ago by nickl

Severity: Blocker

Found this whitepaper:

Not sure if it is still any use.

Untagging Tor: A Formal Treatment of Onion Encryption

Abstract. Tor is a primary tool for maintaining anonymity online. It provides a low-latency, circuit-based, bidirectional secure channel be- tween two parties through a network of onion routers, with the aim of obscuring exactly who is talking to whom, even to adversaries control- ling part of the network. Tor relies heavily on cryptographic techniques, yet its onion encryption scheme is susceptible to tagging attacks (Fu and Ling, 2009), which allow an active adversary controlling the first and last node of a circuit to deanonymize with near-certainty. This contrasts with less active traffic correlation attacks, where the same adversary can at best deanonymize with high probability. The Tor project has been ac- tively looking to defend against tagging attacks and its most concrete al- ternative is proposal 261, which specifies a new onion encryption scheme based on a variable-input-length tweakable cipher.
We provide a formal treatment of low-latency, circuit-based onion en- cryption, relaxed to the unidirectional setting, by expanding existing secure channel notions to the new setting and introducing circuit hiding to capture the anonymity aspect of Tor. We demonstrate that circuit hiding prevents tagging attacks and show proposal 261’s relay protocol is circuit hiding and thus resistant against tagging attacks.

Note: See TracTickets for help on using tickets.