Re: Arm Release 1.4.0
On Mon, Dec 06, 2010 at 10:25:39AM -0800, Damian Johnson wrote: Hazaa, many thanks for the patches! Committed with the exception of sockstat2 (see below). http://www.atagar.com/transfer/tmp/arm_bsdTest2.tar.bz2 One unrelated problem I noticed is that Arm tends to show local connections as Outbound. Netstat, lsof, etc doesn't include a notion of the directionality of a connection, so I'm using the local port to determine if it's inbound or outbound. If it matches the ORPort or DirPort then it's inbound, otherwise it's outbound (line 323 of the connPanel.py [1]). Do you know a smarter way of handling this? I'm familiar with Linux's chroot jail environments (where this works), but not that details of what the bsd counterpart does. Given that the connection doesn't leave the system, replacing the Tor jail IP address with the public IP address of the gateway is a bit confusing. Sorry, I'm not following. Why isn't the tor connection leaving the system? I'm using the results of 'GETINFO address' which tends to be a lot more helpful than showing the ip on the local network (though I can include an option to display the local address instead if you'd like). FreeBSD jails resemble linux jails mainly by name :), and most probably have an own IP somewhere within RFC 1918. This IP serves as the internal adress to the jail when called from a local subnet, and may show multiple connections to the SocksPort, usually IP:9050. This is, what it looks like: [Host's public gateway IP address scrubbed]:9050 -- scrubbed 0.0s (OUTBOUND) And what it 'SHOULD NEITHER' but with proper IP look like: [Jail's private IP address scrubbed]:9050 -- scrubbed 0.0s (OUTBOUND) These connections are 'inbound' to the jail's SocksPort from the host or a private subnet. Also, when running Arm outside the Tor jail, the Tor configuration file isn't found. See the features.pathPrefix entry in the sample armrc [2]. It's specifically for jail environments (arm will otherwise also be failing to find tor's state, log file, and some other resources used to prepopulate data). If you have a suggestion for an automatic method for determining the jail path then I'm all ears. so arm is trying to read a torrc on the host in the location it knows which is displayed from the jail, but is ignoring the jail flag. I'm attempting to read the torrc from the location Tor reports (via 'GETINFO config-file'), using the features.pathPrefix as... well, a path prefix. I'm not familiar with a method of getting the jail path for Linux jails. Is this information available for bsd jails? I'm happy to help with a patch to autodetect for bsd jails if you have a suggestion for how. 'GETINFO config-file' will show the path to torrc from within the jail. So arm tries to read: /path/to/torrc The location from the host though would be /path/to/jail/path/to/torrc Reading the file in that way, I believe, is not a good idea. All this only applies for systems running Tor in a jail and arm from the host. Arm works nicely with Tor if both are running on the same host or inside a jail on FreeBSD. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Arm Release 1.4.0
On Mon, Dec 06, 2010 at 06:26:10PM -0800, Damian Johnson wrote: if (localPort == ORPort or localPort == DirPort): # treat as an inbound connection with the external ip # this is part of arm's current behavior elif (localPort == SocksPort and OS == FreeBSD): # treat as an inbound connection with the internal ip (ie, what's reported by sockstat) # this is new to fix the issue you mention Yes, and maybe just ignore them. IMHO there's no point in seeing these. else: # treat as an outbound connection # again, part of arm's current behavior ... right? If not, could you please clarify? 'GETINFO config-file' will show the path to torrc from within the jail. So arm tries to read: /path/to/torrc The location from the host though would be /path/to/jail/path/to/torrc Reading the file in that way, I believe, is not a good idea. All this only applies for systems running Tor in a jail and arm from the host. Arm works nicely with Tor if both are running on the same host or inside a jail on FreeBSD. If you set features.pathPrefix /path/to/jail in your armrc then it'll read: /path/to/jail/path/to/torrc like you wanted. Again, if you have an approach for arm to detect that (a) Tor exists in a BSD jail and (b) what its path is then I'd be happy to make it work by default instead. Well, I personally do not like anything reading files in a jail in that way and can do without this particular feature. And if, setting 'features.pathPrefix /path/to/jail' will get the desired results. Thanks Damian, thanks Fabian Regards P.S. wonder where the list sentinels will start to grumble on this ... *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Arm Release 1.4.0
Answering to Fabian's mail, which came a minute before I was about send a more verbose answer. On Sun, Dec 05, 2010 at 01:02:16PM +0100, Fabian Keil wrote: Damian Johnson atag...@gmail.com wrote: Hi all. I've checked in the resolver fixes (thank Fabian and Hans!) and a test tarball is available at: http://www.atagar.com/transfer/tmp/arm_bsdTest.tar.bz2 http://www.atagar.com/transfer/tmp/arm_bsdTest.tar.bz2.asc Thanks. Thanks, too. BTW where is the git repo, please ? For BSD I'm using the following commands: sockstat -4 | egrep 'process\s*pid' | grep -v '*:*' procstat -f 'pgrep process' | grep 'pid' | grep -v '0.0.0.0:0' Neither of those commands work for me. To let Arm figure out Tor's pid I still need the pgrep patch I mailed you yesterday. It did work fine under FreeBSD 7.4-PRERELEASE with sockstat the way you suggested. I modified in src/util/connections.py again to RUN_BSD_SOCKSTAT = sockstat -4c | grep '%s%s' (See Fabian's patch.) This works fine, too. Just one cycle less. Neither of the other options though did succeed in displaying a connection list. Attached are the patches I used to get it working on FreeBSD 9.0 CURRENT. I also rebased the sockstat+awk patch, but sockstat+grep probably works reliably enough. One unrelated problem I noticed is that Arm tends to show local connections as Outbound. A connection from the Privoxy jail to the Tor jail: _tor tor2750 25 tcp4 10.0.0.2:9050 10.0.0.1:20528 shows up as: [public gateway IP address scrubbed]:9050 -- scrubbed 0.0s (OUTBOUND) Can verify this, running arm on a host connecting to a jail's tor controlport results in this. Given that the connection doesn't leave the system, replacing the Tor jail IP address with the public IP address of the gateway is a bit confusing. Also, when running Arm outside the Tor jail, the Tor configuration file isn't found. An old torrc located in the host in the same path as the jail, I wondered where these odd configs came from. Removing the hosts torrc gave ### Unable to load the torrc ### so arm is trying to read a torrc on the host in the location it knows which is displayed from the jail, but is ignoring the jail flag. Sorry for not getting deeper in this right now. To Fabian, instead of adding another patch: Running 'pgrep tor' might show multiple results, anything containing the string 'tor' will present it's pid. On 7 it's 'pgrep -x' to get an exact match of the argument ,see man pgrep(1). Thanks for the patches ! To all : The working connection list looks great ! *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Arm Release 1.4.0
On Sat, Dec 04, 2010 at 07:49:58PM -0800, Damian Johnson wrote: ... For BSD I'm using the following commands: sockstat -4 | egrep 'process\s*pid' | grep -v '*:*' procstat -f 'pgrep process' | grep 'pid' | grep -v '0.0.0.0:0' The purpose of these greps is to only get established connections and to filter by the pid (in case there's multiple tor instances). To test please do the following: 1. Run arm at its debug runlevel (arm -e 1) 15:08:52 [ARM_INFO] Terminal color support detected and enabled 15:08:52 [ARM_DEBUG] GETINFO events/names (runtime: 0.0002) [1 duplicate hidden] 15:08:52 [ARM_DEBUG] GETCONF ORPort (cache fetch) [19 duplicates hidden] 15:08:52 [ARM_DEBUG] GETINFO accounting/enabled (runtime: 0.0001) 15:08:52 [ARM_DEBUG] GETINFO desc/id/Unknown (runtime: 0.0001) 15:08:52 [ARM_DEBUG] GETINFO fingerprint (cache fetch) [2 duplicates hidden] 15:08:52 [ARM_WARN] Unable to resolve tor pid, abandoning connection listing 15:08:52 [ARM_DEBUG] GETINFO config/names (runtime: 0.0012) 15:08:52 [ARM_DEBUG] GETINFO config-text (runtime: 0.0016) --- 15:08:51 [ARM_DEBUG] system call: sockstat -4c | grep 'tor' (runtime: 0.00) 15:08:51 [ARM_DEBUG] GETINFO ns/id/Unknown (runtime: 0.0002) 15:08:51 [ARM_DEBUG] GETINFO fingerprint (runtime: 0.0002) 15:08:51 [ARM_DEBUG] GETINFO address (runtime: 0.0003) 15:08:51 [ARM_DEBUG] GETINFO status/version/current (runtime: 0.0002) 15:08:51 [ARM_DEBUG] GETINFO version (cache fetch) 15:08:51 [ARM_INFO] Operating System: FreeBSD, Connection Resolvers: sockstat (bsd), procstat (bsd) 15:08:51 [ARM_WARN] Unable to load torrc (no such file or directory: '/path/to/torrc') ### this is the path on the host, tor is running in a jail 15:08:51 [ARM_DEBUG] GETINFO config-file (runtime: 0.0002) 15:08:51 [ARM_DEBUG] system call: ps -o pid -C tor (runtime: 0.00) 15:08:51 [ARM_DEBUG] system call: netstat -npl | grep 127.0.0.1:9051 (runtime: 0.00) ### 15:08:51 [ARM_INFO] system call (failed): pidof tor (error: 'pidof' is unavailable) 15:08:51 [ARM_INFO] Loaded configuration descriptions from '/tmp/arm/torConfigDescriptions.txt' (runtime: 0.000) 15:08:51 [ARM_DEBUG] GETINFO version (runtime: 0.0002) 15:08:45 [ARM_NOTICE] No configuration found at '/home/user/.armrc', using defaults 2. Arm defaults to the bsd resolvers if os.uname() matches FreeBSD. Please look for an entry like the following in your logs (it'll be near the start): See above. 3. Go to arm's second page and press u to bring up the resolver options. Regardless of the OS detected it will have: * auto * netstat * ss * lsof * sockstat * sockstat (bsd) * procstat (bsd) To make it short: the sockstat (bsd) option works on FreeBSD 7.4-PRERELEASE. This is nice. See above for log. That said, from the link you provided it looks like this isn't necessary. What arm currently attempts is: lsof -nPi | grep process\s*pid.*(ESTABLISHED) If FreeBSD has an equivalents for the flags (n = prevent dns lookups, P = show port numbers (not names), i = ip only) then please show me what its output looks like and I'd be happy to add it as another fallback resolver. What order should sockstat, procstat, and lsof be attempted in? Are any of them preferable due to jails over the others? I would avoid lsof. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Arm Release 1.4.0
On Fri, Dec 03, 2010 at 08:34:46PM +0100, Fabian Keil wrote: Damian Johnson atag...@gmail.com wrote: The lsof command issued by arm [1] is: lsof -nPi | grep process\s*pid.*(ESTABLISHED) What I'll need from you is the following: - A command that, when executed as the tor user, produces connection results filtered to tor's connections. - Example output. tor-jail# uname -or FreeBSD 9.0-CURRENT tor-jail# su -m _tor -c /bin/csh tor-jail# id uid=256(_tor) gid=256(_tor) groups=256(_tor) tor-jail# procstat -f `pgrep tor` | egrep 'TCP|UDP|PID' PID COMM FD T V FLAGSREF OFFSET PRO NAME 3561 tor 4 s - rw---n-- 2 0 TCP 10.0.0.2:9050 10.0.0.1:22370 3561 tor 5 s - rw---n-- 2 0 TCP 10.0.0.2:9050 0.0.0.0:0 3561 tor 6 s - rw---n-- 2 0 TCP 10.0.0.2:9040 0.0.0.0:0 3561 tor 7 s - rw---n-- 2 0 UDP 10.0.0.2:53 0.0.0.0:0 3561 tor 8 s - rw---n-- 2 0 TCP 10.0.0.2:9051 0.0.0.0:0 3561 tor14 s - rw---n-- 2 0 TCP 10.0.0.2:9050 10.0.0.1:44381 3561 tor15 s - rw---n-- 2 0 TCP 10.0.0.2:33734 [scrubbed]:443 3561 tor16 s - rw---n-- 2 0 TCP 10.0.0.2:47704 [scrubbed]:9001 3561 tor17 s - rw---n-- 2 0 TCP 10.0.0.2:9050 10.0.0.1:46343 3561 tor18 s - rw---n-- 2 0 TCP 10.0.0.2:9050 10.0.0.1:64196 3561 tor19 s - rw---n-- 2 0 TCP 10.0.0.2:18856 [scrubbed]:443 3561 tor20 s - rw---n-- 2 0 TCP 10.0.0.2:9050 10.0.0.1:20385 3561 tor22 s - rw---n-- 2 0 TCP 10.0.0.2:9050 10.0.0.1:27541 3561 tor23 s - rw---n-- 2 0 TCP 10.0.0.2:9050 10.0.0.1:21877 (Public IP addresses scrubbed) Sorry for jumping in , but please notice the above command might not not work on all versions of FBSD, at least it doesn't on a 7-Stable jail. Maybe the following just produces a similar sufficient output: _...@ato# id uid=256(_tor) gid=256(_tor) groups=256(_tor) _...@ato# sockstat -4 | grep tor _tor tor4397 7 tcp4 172.27.72.202:9050*:* _tor tor4397 8 udp4 172.27.72.202:53 *:* _tor tor4397 9 tcp4 172.27.72.202:9051*:* _tor tor4397 12 tcp4 172.27.72.202:54011 [scrubbed]:9001 _tor tor4397 15 tcp4 172.27.72.202:59374 [scrubbed]:9001 _tor tor4397 19 tcp4 172.27.72.202:59673 [scrubbed]:9001 _tor tor4397 20 tcp4 172.27.72.202:51946 [scrubbed]:443 _tor tor4397 22 tcp4 172.27.72.202:60344 [scrubbed]:9001 for *not* displaying listening ports just use _...@ato# sockstat -4 | grep tor| sed '/\*/d' _tor tor4397 4 tcp4 172.27.72.202:52420 [scrubbed]:443 _tor tor4397 12 tcp4 172.27.72.202:54011 [scrubbed]:9001 _tor tor4397 13 tcp4 172.27.72.202:51736 [scrubbed]:443 - Be available to test a potential fix. If you're up for that then I'm glad to have the help! Lets take further discussion of this off the list. I don't think this is generally of interest to the rest of the tor community. -Damian It's at least interesting to a part of the rest of the tor community. It certainly is ! Fabian *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Arm Release 1.4.0
On Fri, Dec 03, 2010 at 09:35:39PM +, John Case wrote: On Fri, 3 Dec 2010, Hans Schnehl wrote: Sorry for jumping in , but please notice the above command might not not work on all versions of FBSD, at least it doesn't on a 7-Stable jail. Not working refers to Fabian's use of procstat. Maybe the following just produces a similar sufficient output: _...@ato# id uid=256(_tor) gid=256(_tor) groups=256(_tor) _...@ato# sockstat -4 | grep tor _tor tor4397 7 tcp4 172.27.72.202:9050*:* _tor tor4397 8 udp4 172.27.72.202:53 *:* _tor tor4397 9 tcp4 172.27.72.202:9051*:* _tor tor4397 12 tcp4 172.27.72.202:54011 [scrubbed]:9001 _tor tor4397 15 tcp4 172.27.72.202:59374 [scrubbed]:9001 _tor tor4397 19 tcp4 172.27.72.202:59673 [scrubbed]:9001 _tor tor4397 20 tcp4 172.27.72.202:51946 [scrubbed]:443 _tor tor4397 22 tcp4 172.27.72.202:60344 [scrubbed]:9001 for *not* displaying listening ports just use _...@ato# sockstat -4 | grep tor| sed '/\*/d' _tor tor4397 4 tcp4 172.27.72.202:52420 [scrubbed]:443 _tor tor4397 12 tcp4 172.27.72.202:54011 [scrubbed]:9001 _tor tor4397 13 tcp4 172.27.72.202:51736 [scrubbed]:443 Wait, so the method detailed here: http://lists.freebsd.org/pipermail/freebsd-questions/2007-November/162970.html specifically: ps -Al after polling for lsof and a foreach loop, doesn't work ? I know it's not elegant, but it appeared to me that: lsof + ps -Al would work ... especially if the system in question is doing little (or nothing) other than Tor ... I suppose it would, but some (like me) tend to run tor in rather minimal jails. lsof isn't exactly a small application, so it might just make sense using the base system's sockstat. At least that was the idea. Up to the one porting arm to FBSD, I guess. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Botnet attack? [was: Re: Declining traffic]
On Tue, Apr 27, 2010 at 01:35:20AM -0500, Scott Bennett wrote:
On Mon, 26 Apr 2010 13:36:17 -0400 Flamsmark flamsm...@gmail.com
wrote:
On 26 April 2010 09:59, Timo Schoeler timo.schoe...@riscworks.net wrote:
(Deutsche Telekom AG). For me it really seems as there's some kind of
botnet attack going on.
What makes you think that this is a botnet attack? What are the
characteristics of a botnet attack, and how do these logs exhibit them? If
someone playing around, it's rather background noise... relax, guys ;)
What my system logged over a two- to three-hour period was a very high
rate of illicit connection attempts being logged, a rate much higher that
usual and for an extended period of time. Some of the connection attempts
involved only one or two tries for a single port number. However, consider
another type that also occurred frequently during that time span. That
other type looked more like an individual attack that came in this evening:
[snip]
2010-04-26 23:38:20.086026 rule 5.logscanners.0/0(match): block in on bge0:
81.64.6.141.3422 24.1.225.89.8080: tcp 16 [bad hdr length 12 - too short,
20]
2010-04-26 23:38:20.990386 rule 5.logscanners.0/0(match): block in on bge0:
81.64.6.141.3416 24.1.225.89.8000: tcp 16 [bad hdr length 12 - too short,
20]
2010-04-26 23:38:25.214087 rule 5.logscanners.0/0(match): block in on bge0:
81.64.6.141.3419 24.1.225.89.8001: tcp 16 [bad hdr length 12 - too short,
20]
2010-04-26 23:38:26.122380 rule 5.logscanners.0/0(match): block in on bge0:
81.64.6.141.3422 24.1.225.89.8080: tcp 16 [bad hdr length 12 - too short,
20]
[lot's of snip]
There was a scan. yes. Happens.
But these - [bad hdr length 12 - too short, 20] - are *NOT* a
maliciuos attempt of something but rather a matte ofr tcpdump running against
a pflog* interface. There are different expectations about the snaplen ,
so if increasse the snaplen to sth. higher than 68 bytes the message will
disappear, it is rather harmless.
PLease see man tcpdump
[quote]
TCP Packets
[snip]
If the snapshot was small enough that tcpdump didn't capture the full
TCP header, it interprets as much of the header as it can and then
reports ``[|tcp]'' to indicate the remainder could not be interpreted.
If the header contains a bogus option (one with a length that's either
too small or beyond the end of the header), tcpdump reports it as
``[bad opt]'' and does not interpret any further options (since it's
impossible to tell where they start). If the header length indicates
options are present but the IP datagram length is not long enough for
the options to actually be there, tcpdump reports it as ``[bad hdr
length]''.
[/quote]
on my bsd's a snaplen on 104 is sufficient, but you might try 256 or find
the appropriate value by checking it.
tcpdump ${wtf} -s 104 -i pflog*
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Consider traffic before setting AccountingStart in the middle of an accounting period.
On Sat, Apr 17, 2010 at 03:12:54PM +0200, Paul Menzel wrote:
Dear Tor folks,
my server plan only includes 1 TB of traffic. Since traffic increased
quite a bit during the last few days [1] I have to limit the volume to
not go bankrupt.
In `man torrc` [2] I found AccountingMax and AccountingStart. My
accounting starts let us say at April 2nd and I just set
Accounting{Max,Start} and reloaded Tor on April 12th.
Will Tor consider traffic before in its accounting? That information is
quite crucial to me.
hi,
sorry to say so, but Tor it will *NOT* be aware of traffic before it
starts accounting, better watch you wallet ;)
***
To unsubscribe, send an e-mail to majord...@torproject.org with
unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Still problems with TLS negotiation
On Sat, Jan 02, 2010 at 07:53:03PM +0100, Hans de Hartog wrote: Hi, I upgraded all my servers from FreeBSD 7.2-RELEASE-p4 to 8.0-RELEASE and tor stopped working because of the TLS renegotiation problem. So I upgraded to tor 0.2.1.21 (promised to solve that problem) but the problem is still there. Going back to FreeBSD 7.2 is no option so I tried tor 0.2.2.6-alpha. You need to compile the mentioned versions of Tor against openssl-0.9.8.l, which is the one in the FreeBSD ports tree. neither 7-stable or 8-stable ship with openssl-0.9.8.l, but the versions or Tor you are trying to run need that version of openssl. Still no go. However, the error message (TLS error: unexpected close while renegotiating) is now suffixed with (SSL_ST_OK) but tor isn't doing any usefull work. If it helps: openssl version: 0.9.8k 25 Mar 2009 (I can not change that, it's part of the base system). You do not need to change that, just install the ports version in addition. So, this was the end of a faithfull tor-supporting system, running for months as an exit-router... :-( No, it is not ! Keep going, please :) There is a thread under Tor-relays dealing exactly with this issue. If you want to skip the 'introduction' you may want to see : http://archives.seul.org/tor/relays/Dec-2009/msg00013.html which handles how to compile Tor against openssl-0.9.8.l by using the ports systems built in routines. If you wish not to use this routine just scroll down and you will find a description of how to do without. Regards, Hans. dito *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Consensus drops node
On Mon, Mar 23, 2009 at 03:53:16PM -0700, Kyle Williams wrote: Yes, I've seen this too. The node JanusPAv2 just dropped out of the mix about 7 days ago.I wasn't too concerned since I was testing the max through put of a embedded device. I though it was probably something I did when I was half-awake, but now I'm starting to question it a bit more...hrm.. Last I saw my node, it had a Guard and Fast status. Then one morning, it was gone and no traffic was passing through. On Mon, Mar 23, 2009 at 2:51 PM, Hans Schnehl torvallena...@gmail.comwrote: Hi all, six hours ago the node 'vallenator's performance began to decrease gradually from around 18 mbit/s to at present about 1 mbit/s. The node was running rather stable at it's upper level (see above) with an uptime of now 32 days. I did not do anything on this running machine, so I initially suspected my hoster to intercept or interfere, not necessarily with a motivation against Tor, but maybe for more or less genious technical reasons. But they did not do so. What happened is, the node was actually 'forgotte'n, or dropped out of consensus by the authoritive routers, it still is as of now. Since I do not have logging enabled I am unable to search or provide logs with possible traces of what was happening. Anybody else experiencing this? I'll keep the node running 'as is' and watch for any changes to occur within the next hours but probably I'll take the chance to rebuild a few things on that machine if if there is no change. Any ideas about this ? Regards Hans The node came up again by itself. It did so after 18 hours of gradually but signifigantly loosing connections to the rest of the 'Tor-world' until there was only noise left. I assume the built in scheduled 18hourly publishing of descriptors caught some or all of the authorities by surprise in realising this box is still there and never stopped working ;). For these 18 hours the node was not listed in the current consensus. By now it is, again, with the number of connections and utilized bandwidth increasing. If you find vallenator on kprogs torstatus (trunk) this incident shows nicely in the graphics. Apparently there was a short but complete loss of connectivity or the node became unresponsive for just a few minutes in the beginning of this. Due to the number of at that time already established connections, these and throughput reestablished very fast back on the previous level. But since the node appeared to have gone for the authorities, gradually connections to other nodes and the 'Tor-world' vanished. The blackout itself might have been caused by some apprentice (like me) practising to pull and reinsert plugs on the hosters side or other reasonable activity. Kyle mentioned, this happened to him when he 'was testing the max througphut of a embedded device' and it sounds a little like he was expecting this device to fail sooner or later, and maybe it didn't fail and just became unresponsive at the wrong moment. My node was for a short period of time unresponsive to or disconnected from the general network. The turn to publish descriptors fell exactly within this period of unresponsiveness. So there probably were no descriptors sent to the authorities at the time they expected these to be there, ergo them dropping the router from the lists. The node didn't really notice and sat there chewing it's fingernails and wondering about all the evil in this world. ahemm. Earlier versions of Tor did publish descriptors when sending it a SIGHUP, but this is not possible anymore. So probably presently the only way of solving this is to either restart Tor, or just wait 18 hours until Tor will republish it's descriptors, and hopefully this doesn't happen in another unresponsive period. Regards
Consensus drops node
Hi all, six hours ago the node 'vallenator's performance began to decrease gradually from around 18 mbit/s to at present about 1 mbit/s. The node was running rather stable at it's upper level (see above) with an uptime of now 32 days. I did not do anything on this running machine, so I initially suspected my hoster to intercept or interfere, not necessarily with a motivation against Tor, but maybe for more or less genious technical reasons. But they did not do so. What happened is, the node was actually 'forgotte'n, or dropped out of consensus by the authoritive routers, it still is as of now. Since I do not have logging enabled I am unable to search or provide logs with possible traces of what was happening. Anybody else experiencing this? I'll keep the node running 'as is' and watch for any changes to occur within the next hours but probably I'll take the chance to rebuild a few things on that machine if if there is no change. Any ideas about this ? Regards Hans
Re: No data retention in germany for donated services
On Tue, Dec 09, 2008 at 10:58:03AM +0100, Karsten N. wrote: Seth David Schoen schrieb: NO DATA RETENTION FOR FREE-OF-CHARGE SERVICES Original German text of this article Keine Vorratsdatenspeicherung für unentgeltliche Dienste is available at http://www.daten-speicherung.de/index.php/keine-vorratsdatenspeicherung-fuer-unentgeltliche-dienste/ Copyright 2008 Patrick Breyer; licensed under Creative Commons BY-2.0 (Germany) license. http://creativecommons.org/licenses/by/2.0/de/ Translation by Seth Schoen. This text version omits hyperlinks to the German text of laws, treaties, and court decisions which appear in-line in the original German version. The article by Patrick Breyer and the translation by Seth Schoen gives the information about one main reason, why Tor nodes are not affected by the EU data retention an the German data retention law §113a TKG. Supported by qualified lawyers, we have identified one or two more points, why tor nodes has to be data retention free, but these points are technical and more difficult to communicate with the judiciary. So we ask the tor community, to keep tor non-commercial at all. If a commercial version of tor was online, it will be much more difficult in the next time, to fight against data retention in EU. Yes, it is possible, to make a data retention law for donated services in EU too. But this will takes time. We can use this time, to make tor more robust against this attack. We will keep the German tor admins and the board of torproject.org up-to-date about the lawyers expert opinion but with respect to the recommendation of the lawyers, we will not publish it at the moment. This is great news for all Tornode operators in Germany, if it comes true in the meaning of the local (german) jurisdiction has to accept this. It saves German operators from having to chose between breaking anonymity by loggging data or being criminalyzed, or art least heavily fined or punished otherwise. It also would save quite a lot of work and money to be spent for saving all the data. This would be, presuming it to become accepted, excellent. Unfortunatelly it does not solve the problem, the mere fact traffic is going to be logged and held for 6 months is the problem, not who does the actual logging. So the necessary data will be easily obtained on request of executives from the isp's where nodes are hosted/running. But it may keep up the number of nodes in that country. Regards Hans
Re: DoS attack
On Sat, Nov 22, 2008 at 06:43:03PM -0500, Roger Dingledine wrote: On Wed, Oct 01, 2008 at 03:10:40PM +0200, Karsten N. wrote: the Tor node gpfa is for 10 hours target of a DoS attack. The attack is running on at the moment. Hi Karsten, How did this resolve? Hopefully it ended after a while? Thanks, --Roger Hi, due to the overlay in timing (parallel start of an 'attack' on my machine) I believe this to be the same issue. With standard *x tools (no intelligence sorcery or alike, for the paranoid) I managed to find the person in charge of the machine and called him up. He then basically 'pulled the plug' as the box proved to be inresponsive and apparently had gone out of control. Until failure there was a Tornode active. The box was killed on 1 Oct 2008 at around 16:00 (UST). Actually this is about the same time when the scroogle issue a bit earlier was solved, when, according to this post http://archives.seul.org/or/talk/Oct-2008/msg00014.html an attack on scroogle ceased, so I believe this all was the same issue. According to the person in charge the reason was a misconfigured or out of control machine. If the above is not related to Karstens post, my apologies for the noise. I do not remember who I talked to, and I do not own any logs, the person was surprised but friendly and almost immediately responded to solve the matter. Regards Hans
Re: any middlemen seeing DoS currently?
On Fri, Nov 07, 2008 at 02:49:47PM +0100, Eugen Leitl wrote: On Fri, Nov 07, 2008 at 02:10:32PM +0100, Olaf Selke wrote: Eugen Leitl wrote: I've seen continuous table state increase since about 3.5 hours. It went up from 1 k baseline to 5 k. Anyone else seeing this? yes, the same here Anyone knows which kind of attack that is? Any suggestions how to block it (pf here) yet? you may set the timeout values in pf.conf to rather low values. Actually I start wondering if larger values are of any use anyway. maybe like: - set timeout interval 2 set timeout frag 5 set timeout tcp.first 5 set timeout tcp.opening 5 set timeout tcp.established 600 set timeout tcp.closing 5 set timeout tcp.finwait 3 set timeout tcp.closed 5 -- besides the default. this will kick yourself too if the line is idle for too long. Hans
Re: any middlemen seeing DoS currently?
On Fri, Nov 07, 2008 at 01:38:28PM +0100, Eugen Leitl wrote: I've seen continuous table state increase since about 3.5 hours. It went up from 1 k baseline to 5 k. Anyone else seeing this? Any alternative explanation to DoS? (ISP throttling?). Thanks. Yes, now roughly 4.5 hours ago states went to the upper limit 10k. Flushed tables the hard way but ten minutes later they were up on 10k again. Talked to my ISP's helpline and according to them it may not be their responsibility, but h !?!
Re: any middlemen seeing DoS currently?
On Fri, Nov 07, 2008 at 10:23:02PM +0100, Dominik Schaefer wrote: Hans Schnehl schrieb: you may set the timeout values in pf.conf to rather low values. Actually I start wondering if larger values are of any use anyway. maybe like: - set timeout interval 2 set timeout frag 5 set timeout tcp.first 5 set timeout tcp.opening 5 set timeout tcp.established 600 set timeout tcp.closing 5 set timeout tcp.finwait 3 set timeout tcp.closed 5 -- If I am not mistaken (don't know pf), this will terminate all idle connections after 600s. Correct. That means that your Tor relay will at least loose idle exit connections (maybe even circuits?) which are still valid. This is especially bad for people using long-lived connection to instant messaging services, IRC, and others for which Tor prefers relays with the stable flag. If your relay has that flag, it may be worth to keep that in mind. Thanks for bringing this up, these values are _not_ useful under normal circumstances. These settings will, under conditions like mentioned in this threat, reduce the number of states in pf's table. As soon as the state tables reach their upper limit no further connections are accepted until the number drops under the limit again. It is the choice of having useless states or trying to get rid of unused connections rather fast in order to provide access for 'real' connections. It reduced the number of states by 20% within an hour or so on vallenator. AFAIK this present situation will take some more time until the new certificate is through. _Until then_ , these 'emergency response settings' may be helpful if using pf ;) Hans
Consensus drops router
Hi, vallenator disappeared from current-consensus. The time is CET( + 1), I did not change anything in my configuration. Please see attached gif. Anyone else seeing this ? Hans attachment: traffic.gif
Re: invitation to directory server operators
On Sat, Sep 13, 2008 at 04:46:14AM -0500, Scott Bennett wrote: On: Sat, 13 Sep 2008 09:01:34 +0200 Gitano [EMAIL PROTECTED] wrote: Scott Bennett wrote: This entry doesn't work on my server (Picolo) even though the flag 'Directory (v2)' is set. Why do you believe it doesn't work? My server is not listed as a HSDir server. There is, however, the requirement that your server be up for at least 24 hours before the authorities will list a new HSDir server with the HSDir flag set in the consensus and status documents. If it hasn't been that long yet, please give it enough time. Ok - so a server, getting a new IP every 24 hours (ADSL), will never become a HSDir server? [...snip...] they forced a disconnection of the PPPoE session *at least* every 24 hours, usually assigning a different IP address. That meant any login sessions I had open to other locations got broken without notification to either end, and all open tor connections got broken without warning or notification to either end (i.e., all TCP connections to anywhere else) [...snip}... Just for clarification for Germans: Isps of various countries, even in Europe, do _NOT_ force a 24 hour dis/reconnect with dialup adsl lines. Even if the line is disconnected, they _may_ just give away the same IP that was used before to the same machine. They do not have to, but in practice they often do. (see below) Also, it appears that even when the signal is lost or erratic enough to cause the modem to reset itself and then reconnect, it seems to get the same IP address every time, so ^^^ there may be a pause of 60 - 75 seconds or so, but then everything seems to resume with few, if any, broken connections. If you can find an ISP that doesn't force a disconnection and reconnection every day, life will be much less unpleasant. For Non-Germans: In Germany and some neighboring states it's standard of isp's providing adsl dialups to disconnect _every_ line after 24 hours and reconnect with giving away a new IP. AFAIK there is no exeption to the rule with dialup lines. So the idea of running a HSDir server is probably limited to those with more permanent IPs, unless the 24 hour waiting period for HSDir servers to become active is changed to something shorter. 0.5c Regards Hans
Re: invitation to directory server operators
On Sat, Sep 13, 2008 at 06:18:51AM -0500, Scott Bennett wrote: On Sat, 13 Sep 2008 12:31:34 +0200 Hans Schnehl [EMAIL PROTECTED] wrote: On Sat, Sep 13, 2008 at 04:46:14AM -0500, Scott Bennett wrote: On: Sat, 13 Sep 2008 09:01:34 +0200 Gitano [EMAIL PROTECTED] wrote: Scott Bennett wrote: This entry doesn't work on my server (Picolo) even though the flag 'Directory (v2)' is set. Why do you believe it doesn't work? My server is not listed as a HSDir server. There is, however, the requirement that your server be up for at least 24 hours before the authorities will list a new HSDir server with the HSDir flag set in the consensus and status documents. If it hasn't been that long yet, please give it enough time. Ok - so a server, getting a new IP every 24 hours (ADSL), will never become a HSDir server? [...snip...] So the idea of running a HSDir server is probably limited to those with more permanent IPs, unless the 24 hour waiting period for HSDir servers to become active is changed to something shorter. Oh, well. However, I do notice that German HSDir servers outnumber those of all other countries at present, so *somebody* there is getting better service. They do either run a rented server or pay a rather expensive price for that. For a private person who wishes to run a Tor-node with higher bandwidth and undisrupted connectivity I assume it to be best to rent a server somewhere. Prices have become quite moderate by now. Last not least this would contribute more bandwidth, nodes and anonymity, and that's what it's all about, isn't it? 0.5c That must be before adjusting for inflation, right? ;-) In this country, the U.S. Mint has not produced 0.5c coins since the mid-19th century or perhaps earlier. Now 1.0c coins are not worth picking up off the ground, though if you good get 5 or 10 kg of them, you could sell them for the copper, because the face value has dropped significantly below the metal value. Reading about precious metals coinage is like reading something from Anderson's fairy tales nowadays. Numismatic evaluation but back to topic ;)
Re: tortila as a bad exit
On Tue, Aug 12, 2008 at 11:29:56AM +0100, Robert Hogan wrote:
On Tuesday 12 August 2008 10:09:13 Drake Wilson wrote:
Quoth Scott Bennett [EMAIL PROTECTED], on 2008-08-11 23:30:20 -0500:
I'm not convinced. It hasn't taken any 300 circuits for me. It
seems to happen every time I have a circuit that exits via tortila. It
happens with every destination web page.
I can confirm this. I can't seem to find much pattern to it, though.
I did a simple wget test (no privoxy) and found fairly consistent insertions
of
adsense spam to stevepavlima.com regardless of the site I targeted (google.*,
guardian.co.uk, irishtimes.com, cnn.com).
script type=text/javascriptvar
externalscript=http://pagead2.googlesyndication.stevepavlima.com/show_ads.js;;
document.write('script type=text/javascript src='+externalscript+'?'+new
Date() * 1+'\/script');/script
I found that using a regular browser the corruption appears infrequent
(caching,
browsers doing their best to make sense of gargabe), but the corruption is
consistent using wget. Where there was no insertion of stevepavlima.com
(which
was rare) I just saw simple truncation.
Can anyone else confirm this?
Yes, I can confirm this. Sending single requests to random
addresses via this node is sufficient. I did this on two following
days, the first go was quite immediately after a post in or-talk
regarding this issue, so possibly there were others also trying to
check this node at that time. The second go though was about 24
hours later, so the first 'rush' of testing tortila might have been
over, but results are similar. Very few of the results were
requested via 'host.node.exit' but most were done with a modified
torrc. I chose sites that have content where I just about know what
to expect without double-checking. These results were unforced,
meaning that only one request was sent at a time. But even the
honourable torproject.org site had a minor (bottom) change of
appearance.
There is a simple browser feature, which is to simultanously open
all bookmarks in a bookmark folder. Doing this it was possible to
get results of mixing pages, one time the source site from where content
was merged into others plus the modified ones. Streams seem to have
mixed up somehow with other pages' content or the page itself got
mixed up. On some altered pages 'noise' is to be found, that could
be interpreted as dump of encrypted traffic added unmodified in
between valid html/php/ or whatever tags. Others are simply
incomplete, maybe the missing parts have merged into other streams.
Some of them show php/perl/html tags printed.
I tried only one other node similar to 'tortila', which was 'nexus',
but could not at all reproduce the results from 'tortila' there.
Maybe I should continue with other methods.
As noted, this is done with very little effort, but I hope it can help.
As of today, 12th of August and a few more tries, it appears as if
this behaviour can be witnessed without any real effort, any
connection from the Tor network through 'tortila' is endangered of
being modified. There is no obvious pattern, changes are random and
make no sense, yet I do not really believe this to be a bug in Tor.
There are the same javascript tags reappearing on a number of
altered pages, there is the same mixed nonsense, again javascript
related, within pages if requests for the same page are made at
another time. There also seem to be pages more resistant or even
more or less immune against this as they do not use javascript.
My best guess is some http proxy with filtering capabilities is
misconfigured to run with a Tor exitnode is the cause of this issue.
The worse guess is someone trying to make money with the Tor network
by adding payed ads to webpages in order to reach a rather huge
audience. If this is so, it is not very successful. But this
certainly is a 'bad exit' if the owner does not manage a proper
reconfiguration.
And yes, stevepavlima is very frequent on modified pages.
Regards
Hans
Re: SIGHUP without effect (was: 0.2.1.2-alpha failing to upload descriptor updates automatically)
On Thu, Jul 24, 2008 at 06:53:36AM -0500, Scott Bennett wrote: I'm running 0.2.1.2-alpha and have noticed a recurring problem. It appears that tor is sometimes not uploading a new descriptor on schedule. Once this happens, it appears that it will *never* upload a descriptor update on its own, though it can be tricked into doing so by making some significant change in torrc, then giving it a SIGHUP. I've been trying to keep an eye on it and forcing it to update when the authorities stop listing it in the consensus documents by commenting/uncommenting an ExitPolicy line and giving it SIGHUP. Very simular, on 0.2.0.28-rc (r15188) sending a SIGHUP did not do what it is supposed to. Trying to publish new descriptors (bandwidth) lead to quite unexpected results. The authorities (cached-consensus) simply stopped listing the node and cached-descriptors(.new) were not updated any more. This though did not have an immediate effect as there were enough machines using the node because of the previously downloaded descriptors and consensus. It simply died away slowly when more and more machines 'forgot' the node to exist. Some 12 hours later Tor had to be restartet when it was finally running on some 30% of its previous capacity, but then uploading the new descriptors then accepted (or recognized) correctly by the authorities. The second SIGHUP for to publish altered descriptors didn't do anything a few days later. The reason again was to increase bandwidth and to become a HSDir-Server. There might be things to be considered to set this flag I do not yet know, and if there are, let me know, please. The SIGHUP though did nothing at all. #/bin/kill -HUP 12345 tail -f ../debug.log (info) showed the signal being recieved and new descriptors uploaded to I believe 5 authorative servers, but only 4 responding. Some time later still no change could be seen, so a new and very unpatient SIGHUP did not have any result. I remember seeing this message: ...Consensus does not include configured authority 'dannenberg' at . but no change to the servers descriptors had been acknowledged. The altered descriptors were then correctly uploaded or recognized with the next schedule 18 hours after the previous one. I suppose Tor's behaviour to ignore SIGHUP uploads with an unmodified torrc may be rather a feature, but I'm not sure about this if Tor ignores signals which are sent for good reason. This on a FreeBSD amd64 box, Scott runs FreeBSD i386, does this also happen with linux's ? Bug or feature ? Happy ignoring ? Regards Hans P.S.: The moment I write this the box crashes hard. The reason for all this reconfiguring was to find the limit of this tiny server. Think I found it :)
Re: How can a site still determine my browser language? [Mofify Headers]
Hi On Mon, May 19, 2008 at 06:52:06PM -0700, Steven wrote: Hi, I have been using Privoxy and Tor for a while and came across this strange phenomenon lately. Privoxy is configured to - hide-accept-language Fake these language settings: en_US - hide-referrer Fake as the root directory of the site - hide-user-agent User Agent string to send: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1) - session-cookies-only (and I delete cookies manually anyway before each try) [snip] real browser is German. But how can Google detect that? There are no other Privoxy does not handle https, nor does it claim to do so. If altering Headers, Privoxy cannot deal with https traffic. So, as a result, if google (or whoever) is accessed via https, the browser will send the headers it reads in it's configuration. Some sites might just spawn one https connection within all the ordinary http, just to check if headers are alike. You can take care of that either in about:config or use a tool. I think firefox rewrites it's config in case of an update or for whatever reasons the creators have decided to. There is an add-on called modify headers dealing with headers quite reliably. Makes more sense to set the headers to something reasonable, else the purpose is contradicted. Also pleasse take care that settings in Privoxy are the same as the ones in modify headers else the effect is again contradicted. Or rather dismiss this particular feature in Privoxy if using modify headers. To be found at addons.mozilla.org. To take care of cookies you might consider another addon called cookie culler to be found under the same address. There actually is an option under Firefox- Preferences - Privacy - Private Data called Always clear my private data when I close Firef... at your choice, wiping out fairly much or all what a data munger like google likes to know. If you wish to stay anonymous against google, you NEVER, and this is literally NEVER EVER login there without shelter and without tor. There also is a recommended list of tools/addons to use with tor somewhere on tor's website. Check your headers in http(s) at: https://torstat.xenobite.eu can be quite startling :) scroll down to bottom, http, https check. Thanks, Steven Regards Hans
Re: Tor security advisory: Debian flaw causes weak identity keys [rename server]
Hi Sebastian [...snip] Should I rename my node? It doesn't show up as named anymore because of the key change. You don't have to rename your node. Even after renaming, it will take a while for your router to be listed as named again. ^^ Sebastian Some, like my node, may never get listed named again. Lost my keys roughly one year ago (my fault), authorities never made it to agree on the named flag again. Still get the there is another router... you may consider using another ... message. There are more important things, though. Kind regards Hans
A Question to people from UK
This is a not strictly tor-related matter, but related to anonymity in the wider approach. I was told in the UK you are obliged to deliver your private gpg/pgp keys to the authorities as soon as you use one of these programs for yourself. I am aware of the fact, that in the UK you are threatened with quite harsh laws (imprisonment for several years) if you do not deliver the key to encrypted harddisks und else on demand. What is new to me is the obligation to deliver mentioned keys. I hope this is a hoax, but just for informational reasons it would be nice if someone with the appropriate knowledge could clarify this. thx in advance. Regards Hans
lefkada down
Hi, Since a week these messages appeared: [...snip] Feb 29 08:21:07.148 [info] router_set_networkstatus_v2(): Not replacing network-status from directory server lefkada at 140.247.60.64:80 (published 2008-02-22 19:07:05); we already have it. [snip...] Consequently only four of five authorities listed in cached-status matched a current network-status since about one week. After a qd 'rm -f cached-status/* ' there is: [...snip] Feb 29 09:21:19.123 [info] connection_dir_request_failed(): Giving up on directory server at '140.247.60.64'; retrying [snip...] Now there are only four authorities listed. Maybe hard to find a majority there ? All this on Tor v0.2.0.20-rc-dev (r13725). Am I missing something in my configuration? Regards Hans
Re: lefkada down
On Fri, Feb 29, 2008 at 05:06:54AM -0500, Roger Dingledine wrote: On Fri, Feb 29, 2008 at 10:38:18AM +0100, Hans Schnehl wrote: Feb 29 08:21:07.148 [info] router_set_networkstatus_v2(): Not replacing network-status from directory server lefkada at 140.247.60.64:80 (published 2008-02-22 19:07:05); we already have it. [snip...] Right, Lefkada's been down for nearly a week. Its owner is working on that. Good thing we have other directory authorities. :) Consequently only four of five authorities listed in cached-status matched a current network-status since about one week. [snip] Now there are only four authorities listed. Maybe hard to find a majority there ? All this on Tor v0.2.0.20-rc-dev (r13725). You are a little bit confused. Tor 0.2.0.x uses the new v3 directory Yes, I remember this was told in my life before ;) system, which means it looks at ~/.tor/cached-consensus. The ~/.tor/cached-status/ directory is just for mirroring v2 networkstatus documents to the Tor users that are running 0.1.2.x. Hope that helps, --Roger Thanks for clearing. Hans
Re: Which name servers do you use?
On Thu, Jan 24, 2008 at 08:58:41PM +0100, Marco Bonetti wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi all, I was lurking through my tor logs recently, when this notice comes to my attention: Jan 23 03:25:05.416 [notice] Your DNS provider has given $IP_ADDRESS as an answer for 6 different invalid addresses. Apparently they are hijacking DNS failures. I'll try to correct for this by treating future occurrences of $IP_ADDRESS as 'not found'. AFAIK OpenDns are financing their service by 'hijacking' invalid requests. They do actually announce this somewhere on their website, so people using them should know. It is their business-model to take unknown and invalid requests to paid-for sites with the usual links etc. To my opinion this is all right, as they in return provide a really fast service, as you mentioned. This consequently leads to Tor's above notice and the IP of the link-farm site to be treated as 'not found'. And that's just fine. Two days ago I've added OpenDNS name servers on top of my resolv.conf, effectively replacing the Open Root Server Network ones which I usually use, to try them out. I like ORSN philosophy and way of work[1] but I've to admit that OpenDNS servers are dramatically faster. So, here comes the questions: which ones do you use? Are there any other interesting name servers to try out? There are sufficient numbers of open nameservers out in the net, of which many try to earn money by taking invalid requests to linkfarms of various qualities, if the word quality is appropriate in this context. I think these are not a bad choice for Tor, as they let especially dial-up Tor-ops avoid bothering their ISP's sometimes rotten nameservers. Some of those probably exist only for the purpose of logging requests, but that's not crucial, the ISP can do this too. I use fast servers somewhere in Ukrainia which do the same thing, (advertising), and so Tor comes up with the message and the reaction and everything else is fine. (I also block the regarding IP's) ciao, marco [1] see: http://www.orsn.org/ and http://www.opendns.com/ These are both a good choice, whereas OpenDNS certainly is faster (hopefully ORSN will get better soon). Regards Hans
Re: We're missing a certificate from authority lefkada with signing key 0000000000000000000000000000
On Wed, Jan 23, 2008 at 05:51:34PM +, otto otto wrote: I'm also getting this messeages, since a day now, every minute a message? I'm also running tor-0.2.0.15-alpha. Any idea what causes these messages? Thanks. otto this has already been discussed more than sufficiently on this list. see http://archives.seul.org/or/talk/Jan-2008/msg00254.html Minor Bugfixes -first... Regards Hans
Re: Hostname
On Tue, Jan 22, 2008 at 03:57:46PM -0600, Drake Wilson wrote: Quoth Khaled Moussa [EMAIL PROTECTED], on 2008-01-22 23:42:33 +0200: Is there a way for hiding the IP of host and ISP name from Tor network and TorStatus for security reasons? That's an extremely vague question. IP of _what_ host, and for _what_ reasons? I believe this is about not to show up in the publicly available lists (TorStatus) on blutmagie, kprog and others. Anyway, based on my predicted disambiguation of your question, the answer is generally no, Tor clients and relays cannot easily hide themselves from the Tor network. Of course the network must know 'itself', so there is no point in hiding from the Tor network and in the same time being a member. But if my assumption is correct, you might want to set up your node as a bridge. These are not listed in the mentioned status lists. http://archives.seul.org/or/talk/Dec-2007/msg00268.html http://archives.seul.org/or/talk/Dec-2007/msg00269.html give hints how to do this. --- Drake Wilson Regards Hans
Re: shinjiru closed exit node acceptnolimits
On Tue, Jan 08, 2008 at 08:17:13PM +0300, accept no limits wrote: Hello everybody, here an update. unsuspended. So I don't know why it was suspended and I don't know why it was unsuspended. Nevermind... Now the server has new IPs and this exit node will soon be back. Bye accept no limits Perfect and good to know! Congratulations ! Hans
Re: What to do at IP number change?
Hi, On Mon, Jan 07, 2008 at 09:19:11PM +0100, [EMAIL PROTECTED] wrote: Hi, On Mon, 7 Jan 2008 20:55:36 +0100 Tom Hek [EMAIL PROTECTED] wrote: i'm changing my public IP number ten times per day and to avoid confusion, *Ten times per day?* Please tell us again why it is you're bothering to run a tor server if you also feel you have to hide its existence. it's because a moving target is harder to hit; it's more safe to change the IP number often. Another point is that states like germany do like IP numbers so much that they do data retention and therefore i give them what they want - many IP numbers ;-) The advantage of making it harder for attackers to find back your node (I wonder if a serious attacker of a certain quality would really be stopped significantly) are IMHO negligible compare to the advantage to more or less constantly relaying traffic. Considering the time it needs for other servers and possible clients to realize your ever changing IP it may be a bad choice, as all of them will have to download the node's new IP and during this time ther will be less traffic relayed as if the node was wellknown. I also live on a dial-up adsl2 line, and I can see how long it takes for traffic utilizing the provided bandwidth after a reconnect. It is indeed a loss of bandwidth to the network. A word about obfuscation: If we run a tor node, we are as anonymous as Sta. Claus hiding behind sunglasses to our ISP's. If they want, they can see that we are running a router/tor-node. Actually they can hardly miss it. Of course it may be fun to do somthing like tor-war-driving, but as mentioned, not necessarily good for the network ;) i'm stopping my TOR server before and starting after the number change. But after the start TOR is very slow. Is there a better way to tell the TOR server that the public IP has changed? Tor will detect it and republish his server descriptor with the new IP in it. That is true iff the Address line in torrc contains a host+domain name, not an IP address, and the name server data base in question has been updated to reflect the changed address. So i should use a DynDNS host+domain name? You may, but not necessarily have to. I made myself a little script catching the changed IP via mpd_linkup (or ppp.linkup or what you may use) and changing the Address 123.123.123.123 into the new Address 234.234.234.234 and then sends a SIGHUP to Tor. Regrets Regards Hans
Re: What to do at IP number change?
On Mon, Jan 07, 2008 at 10:52:57PM +0100, [EMAIL PROTECTED] wrote: Hi, A word about obfuscation: If we run a tor node, we are as anonymous as Sta. Claus hiding behind sunglasses to our ISP's. that's clear; i'm using TOR as a mix with a transparent local http proxy which uses an ISP proxy as parent proxy, so that the exit traffic goes through two proxies and with several numbers in the X_FORWARDED_FOR header ;-) That's good enough for hiding my public IP to http servers which do log only the TCP/IP number and for most which do evaluate the X_FORWARDED_FOR header. And because of the mixing the ISP can't see which traffic is caused by me. So he can see a TOR server which uses one of his proxies but not my personal traffic. For obfuscation i opened all exit ports except 25 (because of spam). So i should use a DynDNS host+domain name? You may, but not necessarily have to. I made myself a little script catching the changed IP via mpd_linkup (or ppp.linkup or what you may use) and changing the Address 123.123.123.123 into the new Address 234.234.234.234 and then sends a SIGHUP to Tor. Ok, i will use /etc/ppp/ip-up.local but what exactly shall i write into that file? killall -s SIGHUP tor?ybe you I am not familiar how to do this on linux and have no machine to try here, can please someone help out? You need the following: #!/bin/sh torpid= 'catch the PID' newip='See_above' #something like the following should do then: (please someone translate to a linux) sed -i '' 's/^\(Address\) .*/\1 '$newip'/' /path/to/your/torrc /path/to/kill -s HUP $torpid to be put in a script and initiated by e.g. ip-up.local does the trick for me. Maybe this is a complete waste of time, if Tor is able to determine the new IP alone faster. IN this case a simple: /path/to/kill -s HUP $torpid should be fine. What may be faster or more efficient, to HUP tor with a new IP, or to let the Authorities find out themselves about a renewed IP, I do not know. Anyone? Greets Regards Hans
Re: shinjiru closed exit node acceptnolimits
On Thu, Jan 03, 2008 at 10:41:56PM +0300, accept no limits wrote: shinjiru explicitly allows anonymous hosting. how does anonymous money transfer work in this case? I got this question in personal mails after my posting, too. So here a (short) answer: They do not accept anonymous money, BUT the accept visa cards, and especially they accept virtual prepaid visa cards. So think out a name, address, etc. (just for the card) and you can get one e.g. at card444.com. How to pay card444.com anonymously? Take a look at their webpage and choose a method you think it's anonymous. And of course, use tor all the times ... === cut Somebody out there, PLEASE, to give some hints/answer to my ORIGINAL question? Original question?? Yes, my original question: Can somebody recommend a Non-US and Non-EU server provider (dedicated server) that has no problems if the server is used as tor exit node? Hi, just a possible provider, accoreding to their website you should even be able to do something like anonymous payments. Please take a look at : http://www.wrzhost.com The appear to have a mixed reputation about their reliability and speed, but this is completely untested, so not a recommendation but a hint. accept no limits Regards Hans
Re: shinjiru closed exit node acceptnolimits
On Thu, Jan 03, 2008 at 05:04:46PM +0300, accept no limits wrote: Hello, What about going the hard way? They have a contract with you. You paid for a service they refuse to fulfill without comment. I dont know the malaysian laws but I think you should do steps to force them to fulfil their contract. Sorry, I don't do it the german way: paying a lawer, going to court and after months or years having a result. And even if the judge says: OK you paid for another 3 months, they have to fulfil their contract for another 3 month., does this solve the problem? NO. After this 3 months I have to search for another hoster. The only difference: I paid a lawer, I paid the court, I lost month or years and not to forget I am no longer anonymous. [I know no lawer or court working for anonymous persons.] Even being of German nationality I do absolutely agree with you about the uselessness of deploying lawyers in such a case. Some years ago I made the experience (with renting a house) that some people need some kind of warn shot until they start respecting you. In my case I got a (german) Einstweilige Verf?gung and suddenly they spoke with me. Just to help out those who don't know German: (at least roughly) temporary injunction. All this takes months, if applicable with other countries' laws at all, the costs of such an attempt may be out of any scope. Thank you for helping out With a house (where you intend to live for years, you are not anonymous) that's another story. You repeatedly mentioned your absolute anonymity against the malaysian company your node was hosted on. Have you possibly taken it into your consideration that the so called 'Abuse' they are referring to might be exactly that and _not_ Tor? Bye Regards Hans
TLS errors
Hi, I do have a lot of reoccurring entries as following with Tor logging on debug level. This is Tor v0.2.0.15-alpha-dev (r13006) but same was happening before with lower versions. Here is an excerpt: %tail -f /usr/local/etc/tor/debug.log | grep error Jan 02 12:45:57.965 [info] TLS error: syscall error while writing (errno=1: Operation not permitted) Jan 02 12:45:57.965 [info] connection_handle_write(): tls error. breaking. Jan 02 12:45:57.965 [info] TLS error: syscall error while writing (errno=1: Operation not permitted) Jan 02 12:45:57.965 [info] connection_handle_write(): tls error. breaking. Jan 02 12:46:06.204 [debug] TLS error: syscall error while reading (errno=54: Connection reset by peer) Jan 02 12:46:06.204 [info] connection_read_to_buf(): tls error [connection reset]. breaking (nickname NoNickNode, address 111.112.113.114). Jan 02 12:46:14.711 [debug] crypto error while performing RSA decryption: oaep decoding error (in rsa routines:RSA_padding_check_PKCS1_OAEP) Jan 02 12:46:14.711 [debug] crypto error while performing RSA decryption: padding check failed (in rsa routines:RSA_EAY_PRIVATE_DECRYPT) Jan 02 12:46:14.746 [debug] TLS error: unexpected close while reading Jan 02 12:46:14.746 [info] connection_read_to_buf(): tls error [unexpected close]. breaking (nickname nevermind, address 011.211.311.411). Jan 02 12:46:18.716 [debug] TLS error: unexpected close while reading Jan 02 12:46:18.716 [info] connection_read_to_buf(): tls error [unexpected close]. breaking (nickname noneofmybusiness , address 167.102.266.121). Jan 02 12:46:21.011 [info] TLS error: syscall error while writing (errno=1: Operation not permitted) Jan 02 12:46:21.011 [info] connection_handle_write(): tls error. breaking. Jan 02 12:46:25.718 [debug] TLS error: syscall error while reading (errno=54: Connection reset by peer) Jan 02 12:46:25.718 [info] connection_read_to_buf(): tls error [connection reset]. breaking (nickname stclaus, address 123.321.213.312). Jan 02 12:46:47.523 [info] TLS error: syscall error while writing (errno=1: Operation not permitted) Jan 02 12:46:47.523 [info] connection_handle_write(): tls error. breaking. Jan 02 12:46:56.584 [debug] TLS error: unexpected close while reading and so on. Tor is running, but appears to be using only fractions of the bandwidth it is supposed to. Can someone please give a short explanation? (for a non-crypto-hacker) Regards Hans
Map of surveillance societies
just in case someone wishes to move servers around, see the map for where to avoid: http://www.privacyinternational.org/article.shtml?cmd%5B347%5D=x-347-559597 Interesting. I assume Germany is seen as before the new laws came into force. Regards Hans
Re: TLS errors
Thx for the fast replies, I wasn't really scared but rather curious about what the logs were saying. On Wed, Jan 02, 2008 at 05:22:36PM +0100, Csaba Kiraly wrote: Hi, As far as I can tell (I'm not a developer) the error message you see is normal behavior, just logged in a way that scares people ;) Of course it can also be something else, but you can find a possible explanation in my previous mail in the no traffic? thread: http://archives.seul.org/or/talk/Nov-2007/msg00038.html I read the message, and there is a simularity, mayber there is something about openssl with freebsd, as Scott Bennet lso runs a freebsd machine. Mine is running now with freebsd7, but the logs did show up also with fbsd6-stable. The cause is a housekeeping operation at the other side, which tears down your connection, but for some reason the TLS session is not closed nicely. Messages in the two logs should be similar to the following (say auth1 is your machine, auth2 is the other node): auth2 Nov 06 13:18:50.660 [info] run_connection_housekeeping(): Marking duplicate conn to 193.168.2.1:34066 obsolete (fd 16, 140 secs old). auth2 Nov 06 13:18:50.660 [info] run_connection_housekeeping(): Expiring non-used OR connection to fd 16 (193.168.2.1:34066) [Obsolete]. auth1 Nov 06 13:18:50.661 [info] connection_read_to_buf(): tls error. breaking (nickname auth2, address 193.168.2.2). All correct, the ones I cannot really understand are those: Jan 02 12:46:14.711 [debug] crypto error while performing RSA decryption: oaep decoding error (in rsa routines:RSA_padding_check_PKCS1_OAEP) Jan 02 12:46:14.711 [debug] crypto error while performing RSA decryption: padding check failed (in rsa routines:RSA_EAY_PRIVATE_DECRYPT) and the ones with: Jan 02 12:45:57.965 [info] TLS error: syscall error while writing (errno=1: Operation not permitted) Jan 02 12:45:57.965 [info] connection_handle_write(): tls error. breaking. Jan 02 12:45:57.965 [info] TLS error: syscall error while writing (errno=1: Operation not permitted) what should be not permitted ? strange... This does not justify bandwidth problems, so you might have to look for some other reason as well Csaba I reckon one reason for bandwidth behaviour is, the node runs with another secret-key, as I lost the original. It may take some time until it is 'named' again, so the 7 authorities handle the node differently. How long does it take nowadays for a registered name to expire and the name to be used for (in my case the same) new machine ? Alexander W. Janssen wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hans Schnehl wrote: Hi, Hi! Jan 02 12:46:06.204 [debug] TLS error: syscall error while reading (errno=54: Connection reset by peer) Jan 02 12:46:06.204 [info] connection_read_to_buf(): tls error [connection reset]. breaking (nickname NoNickNode, address 111.112.113.114). It looks like one of the nodes you have a connection too just kicked you out for some reason (connection reset by peer). This is pretty normal. Could be the remote node shutting down the software, rebooting and such. Jan 02 12:46:14.711 [debug] crypto error while performing RSA decryption: oaep decoding error (in rsa routines:RSA_padding_check_PKCS1_OAEP) Not sure about those, but it could be consecutive errors resulting from the encrypted connection (TLS) being shut down. Tor is running, but appears to be using only fractions of the bandwidth it is supposed to. Can someone please give a short explanation? No idea about that though. But it usually takes some time until everyone learned about your node - from my experience it takes up to 24 hours until the bandwidth is fully utilized. I'm just guessing from my generic experience :) I had with Tor 0.2.0.7 and ..06 a full utilizatiojn of bandwidth within roughly 2 to three hours after reconnection, but that was lost somewhere with the next -0.8- to todays -0.15. Regards Hans
Re: How are German Tor server people doing?
Hi, nothing really changes here in Germany yet. There are, as sufficiently discussed, some more or less promising attempts to stop the new law. But for the year 2008 there is no change for torizens yet, and actually some people including me do not believe there will be an obligation to log anything for us in the time after. If, then it might happen in one year from now, and in that case I will close my German node and move somewhere else. But that is, as mentioned, in one year from now. How are German Tor server people doing? I think Germany has the highest density of Tornodes in the world if you use the number of citizens and the number of nodes as parameters. At present the number of nodes (maybe also because of 24c3, which I missed) is increasing. It's still going... The raids on Tor operators are afaik not a part of a larger strategy against Tor, but a pretty sad picture of the local policeforce and their massive lack of adaptive capabilities. One side effect though is the diminishing number of exit-nodes here. Doesn't help those raided during the last year, but the vast majority here did not encounter any raids. I am hoping they having a good nice time, it must be 6am '08 there right now... Don't you worry, afaik most, here in Berlin (as of 15:00), are still not very responsive, yet. silent collusion. If it is indeed that, it's time to get seriously scared. Disagree. Not scared, but consequent ;) Last not least, there is no better occasion than now: Happy new year everyone.
