Opened 10 years ago

Closed 9 years ago

Last modified 7 years ago

#1160 closed defect (fixed)

AllowSingleHopExits setting can be bypassed by client

Reported by: keb Owned by:
Priority: Low Milestone:
Component: Core Tor/Tor Version:
Severity: Keywords:
Cc: keb, nickm, coderman, Sebastian, bsdtechie, arma Actual Points:
Parent ID: #1751 Points:
Reviewer: Sponsor:

Description (last modified by nickm)

Using the software Tortunnel
it is easy to setup a 1-hop proxy through a selected exit node,
even if the node has AllowSingleHopExits set to 0 (default).

Maybe i'm being alarmist, but this seems like abuse waiting to happen -
a disaster for exit node operators and for network capacity re:p2p.
If this isnt fixable in a few days i'll be switching to non-exit.

[Automatically added by flyspray2trac: Operating System: All]

Child Tickets

Attachments (1)

notices.log.1 (91.8 KB) - added by keb 9 years ago.
tor log file with RefuseUnknownExits 1

Download all attachments as: .zip

Change History (15)

comment:1 Changed 10 years ago by keb

comment:2 Changed 10 years ago by nickm

Yeah, it looks like it could be time to implement some variant of proposal 163. Somebody should decide
how many steps in the arms race we should bypass.

comment:4 Changed 10 years ago by keb

A correspondent sent me some code to recognize tortunnel connections
so i patched it in and the results are as follows:

According to the USR1 stats dump,
from Dec 04 08:31:30.180 until Dec 11 23:01:12.434
there were 593 circuits made.
From the node's log the tortunnel connections were on
Dec 04 09:59:33.102
Dec 04 15:01:08.289
Dec 05 00:22:14.449
Dec 05 05:59:07.405
Dec 05 10:59:42.238
Dec 05 13:20:13.715
Dec 05 16:02:21.712
Dec 05 20:48:21.909
Dec 07 08:34:41.294
Dec 07 13:44:42.938
Dec 07 17:34:39.810
Dec 08 02:02:58.210
Dec 08 06:51:44.685
Dec 08 12:35:26.871
Dec 08 20:10:49.473
Dec 09 01:14:34.580
Dec 09 05:20:11.074
Dec 09 09:21:53.337
Dec 09 14:38:32.310
Dec 09 19:41:53.796
Dec 09 23:25:10.127
Dec 10 04:03:18.261
Dec 10 12:44:05.637
Dec 10 16:15:04.614
Dec 10 19:07:25.651
Dec 10 20:24:04.295

I hope this is helpful in understanding whether the problem is serious yet.
Let me know if more info is needed, i could send it privately.
(e.g. the logging patch, or more dump data)

comment:5 Changed 10 years ago by coderman

Just to be clear that was 26 tortunnel requests out of 593 total?

Also, someone appears to be checking new relays with appropriate
exit policies with tortunnel once in the directory. Disabling
tortunnel for Good Samaritan bad exit checks would be undesirable.

I suppose the next question is traffic volume associated with
these circuits. If all but one of the tortunnel users are
aggressive torrent'ers choking them off would be quite useful.

Can you determine the ratio of tortunnel traffic volume to the
rest of the relay traffic? Perhaps there should be a patch for
that ...

Thanks for the update!

comment:6 Changed 10 years ago by keb

drat, i read the stats wrong!
there were actually 593 circuits open at the time of the signal,
some of them for the whole 7 days the server was up and some just created.
i will have to log at info level to record circuits opened over a period,
but my node does transfer a total of about 288KB/s continuously.
not sure if there is a way to record traffic volume by circuit,
that may be creeping into de-anonymizing territory.

comment:7 Changed 9 years ago by arma

If you update to the latest 0.2.2.x git
(commit 1108358e96e818f1d433a3025310c81e55891df9), and set
"RefuseUnknownExits 1" in your torrc, your Tor will try much harder
to prevent one-hop exits.

Look for "Attempt by %s to open a stream" log messages.

Let us know if it breaks / works / remains silent / etc.

comment:8 Changed 9 years ago by stars

Hello, i upgrade my Tor to the last git master and enable it on a non-exit relay, i have guard and stable flag and i have 5 message about the "open stream.." . So it seem work good but i will give a feedback later.

Just interesting that a non exit relay has clients who try to connect to it

SwissTorHelp Relay

comment:9 Changed 9 years ago by nickm

Just seeing the messages doesn't mean it's working well; those could all be false positives or something.
Roger--can you give people some suggestion for how they're supposed to be evaluating the quality of the output?

comment:10 Changed 9 years ago by keb

ok, compiled, configured, started.
loglevel is set to notice.

Mar 11 21:57:15.771 [notice] Performing bandwidth self-test...done.
Mar 11 22:16:49.754 [notice] Attempt by [scrubbed] to open a stream from unknown relay. Closing.
Mar 11 22:16:49.942 [notice] Attempt by [scrubbed] to open a stream from unknown relay. Closing.
Mar 11 22:27:52.611 [warn] eventdns: All nameservers have failed
Mar 11 22:27:52.674 [notice] eventdns: Nameserver is back up
Mar 11 22:58:37.109 [notice] Attempt by [scrubbed] to open a stream from unknown relay. Closing.
Mar 11 22:58:37.386 [notice] Attempt by [scrubbed] to open a stream from unknown relay. Closing.
Mar 11 22:58:43.122 [notice] Attempt by [scrubbed] to open a stream from unknown relay. Closing.
Mar 11 22:58:43.328 [notice] Attempt by [scrubbed] to open a stream from unknown relay. Closing.

would more info be useful?

Changed 9 years ago by keb

Attachment: notices.log.1 added

tor log file with RefuseUnknownExits 1

comment:11 Changed 9 years ago by keb

i attached the complete log file since i started running that version.

AllowSingleHopExits 0
RefuseUnknownExits 1

everything seems fine until 2010-03-16 when
there is no more traffic through the node
as shown by
hmm the descriptor hasnt been published since then either...

ok it must be just trunk.kgprog that isnt showing traffic. other sites and my provider show full usage

comment:12 Changed 9 years ago by nickm

Description: modified (diff)
Parent ID: #1751

comment:13 Changed 9 years ago by arma

Resolution: Nonefixed
Status: newclosed

Check out the solution implemented in #1751.

Closing this one as fixed, so I can close #1751.

comment:14 Changed 7 years ago by nickm

Component: Tor RelayTor
Note: See TracTickets for help on using tickets.