- tor-relays - lists.torproject.org

100K circuit request per minute for hours killed my relay
by Felix 31 Jul '17

31 Jul '17

Hi everybody I observed two circuit bursts around July 19th. On a poor server Tor crashed, on a strong it didn't. The logs below are from the crashed one. I'm on FreeBSD. To my mind the circuit burst exhausts the nmbclusters (not memory, Inact tells). Strong servers have more. How long is more enough ? On FreeBSD nmbclusters is a boot tunable. The strong server took 140k circuits for several hours. Is it worth thinking about a Tor setting like MaxCircuitsPerTime ? MaxAdvertisedBandwidth won't help directly. 1) Normal operation kern.openfiles: 5516 Mem: 36M Active, 1288M Inact, 455M Wired, 1452K Cache, 425M Buf, 191M Free Swap: 3072M Total, 3072M Free USERNAME PRI NICE SIZE RES STATE TIME CPU COMMAND _tor 87 0 309M 283M RUN 125.7H 50.00% tor{tor} _tor 22 0 309M 283M uwait 167:32 3.96% tor{tor} 2) Last minute before crash: kern.openfiles: 5467 Mem: 296M Active, 935M Inact, 692M Wired, 21M Cache, 425M Buf, 27M Free Swap: 3072M Total, 1592K Used, 3070M Free USERNAME PRI NICE SIZE RES STATE TIME CPU COMMAND _tor 85 0 465M 438M RUN 126.8H 43.99% tor{tor} _tor 33 0 465M 438M uwait 186:39 15.97% tor{tor} 3) Crashed: kern.openfiles: 5455 Mem: 295M Active, 936M Inact, 699M Wired, 21M Cache, 425M Buf, 21M Free Swap: 3072M Total, 1592K Used, 3070M Free kernel: [zone: mbuf_cluster] kern.ipc.nmbclusters limit reached sysctl kern.ipc.nmbclusters 126138 Heartbeat: Tor's uptime is 15 days 16:00 hours, with 1611 circuits Heartbeat: Tor's uptime is 15 days 17:00 hours, with 40471 circuits Heartbeat: Tor's uptime is 15 days 18:00 hours, with 88052 circuits Heartbeat: Tor's uptime is 15 days 19:00 hours, with 78444 circuits [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. -- Cheers, Felix

3 2

100K circuit request per minute for hours killed my relay
by Pascal Terjan 31 Jul '17

31 Jul '17

Last night for 4h30 (until VPS provider shut it down) one of my middle relays seems to have got in a bad state where it was using 100% CPU continuously It was not using much bandwidth, about 4MB/s, but reading the logs it seems it was getting a lot of circuit requests (70K/minute initially, 100K at the end). Is there anything I can do about it? Jul 20 19:41:20.000 [notice] Heartbeat: Tor's uptime is 157 days 18:00 hours, with 4642 circuits open. I've sent 13916.64 GB and received 13502.43 GB. Jul 20 19:41:20.000 [notice] Average packaged cell fullness: 98.154% Jul 20 19:41:20.000 [notice] TLS write overhead: 2% Jul 20 19:41:20.000 [notice] Circuit handshake stats since last time: 8823/8823 TAP, 112411/112806 NTor. Jul 21 00:52:06.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [398 similar message(s) suppressed in last 60 seconds] Jul 21 00:53:06.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [46893 similar message(s) suppressed in last 60 seconds] Jul 21 00:54:06.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [66339 similar message(s) suppressed in last 60 seconds] Jul 21 00:55:06.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restrict ed exit policy. [69939 similar message(s) suppressed in last 60 seconds] Jul 21 00:56:06.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restrict ed exit policy. [73055 similar message(s) suppressed in last 60 seconds] [...] Jul 21 04:19:08.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [101856 similar message(s) suppressed in last 60 seconds] Jul 21 04:20:08.000 [warn] Your computer is too slow to handle this many circuit creation requests! Please consider using the MaxAdvertisedBandwidth config option or choosing a more restricted exit policy. [97494 similar message(s) suppressed in last 60 seconds]

8 11

Tor relay operators at DEF CON
by Joel Cretan 30 Jul '17

30 Jul '17

Hi relay operators, If anyone at DEF CON is interested in meeting up, perhaps we could set up a meeting time, maybe in/around the Crypto and Privacy Village. Of course we're all interested in anonymity, so no pressure to speak up. But if enough people tell me they're interested, I'll try to organize something. Hope to meet some of you. Joel

4 9

badexit 29378422C99074D06331D5700E47451610B0D20D
by eric gisse 30 Jul '17

30 Jul '17

it looks like i've found an exit node mitm-ing ssh, or at least giving it a shot. https://atlas.torproject.org/#details/29378422C99074D06331D5700E47451610B0D… that exit policy looks more like a wishlist than anything else, at this point. notice all 3 sites have different clear wire ssh keys (obviously) but all the same when connecting over tor. what a coincidence! module code: https://github.com/jowrjowr/exitmap/blob/master/src/modules/sshmitm.py # ./bin/exitmap sshmitm -e 29378422C99074D06331D5700E47451610B0D20D 2017-07-29 16:52:36,797 exitmap [INFO] Attempting to invoke Tor process in directory "/tmp/exitmap_tor_datadir-root". This might take a while. 2017-07-29 16:52:36,798 exitmap [INFO] No first hop given. Using randomly determined first hops for circuits. 2017-07-29 16:52:37,369 util [INFO] Tor Bootstrapped 0%: Starting 2017-07-29 16:52:41,942 util [INFO] Tor Bootstrapped 80%: Connecting to the Tor network 2017-07-29 16:52:41,943 exitmap [INFO] Successfully started Tor process (PID=31779). 2017-07-29 16:52:42,117 exitmap [INFO] Running module 'sshmitm'. 2017-07-29 16:52:42,269 modules.sshmitm [INFO] obtaining ssh key information for destinations 2017-07-29 16:52:42,269 modules.sshmitm [INFO] getting key for github.com 2017-07-29 16:52:42,643 modules.sshmitm [INFO] getting key for gitlab.com 2017-07-29 16:52:42,889 modules.sshmitm [INFO] getting key for bitbucket.com 2017-07-29 16:52:58,807 relayselector [INFO] 216 relays have non-empty exit policy but no exit flag. 2017-07-29 16:52:58,816 relayselector [INFO] 1 out of 1000 exit relays meet all filter conditions. 2017-07-29 16:52:59,080 exitmap [INFO] Scan is estimated to take around 0:00:03. 2017-07-29 16:52:59,080 exitmap [INFO] Beginning to trigger 1 circuit creation(s). 2017-07-29 16:53:02,018 exitmap [INFO] Done triggering circuit creations after 0:00:02.937566. 2017-07-29 16:53:04,169 modules.sshmitm [CRITICAL] tor ssh key mismatch for github.com:22 (192.30.253.112) over exit relay 29378422C99074D06331D5700E47451610B0D20D clear wire value: AAAAB3NzaC1yc2EAAAABIwAAAQEAq2A7hRGmdnm9tUDbO9IDSwBK6TbQa+PXYPCPy6rbTrTtw7PHkccKrpp0yVhp5HdEIcKr6pLlVDBfOLX9QUsyCOV0wzfjIJNlGEYsdlLJizHhbn2mUjvSAHQqZETYP81eFzLQNnPHt4EVVUh7VfDESU84KezmD5QlWpXLmvU31/yMf+Se8xhHTvKSCZIFImWwoG6mbUoWf9nzpIoaSjB+weqqUUmpaaasXVal72J+UX2B+2RPW3RcT0eOzQgqlJL3RKrTJvdsjE3JEAvGq3lGHSZXy28G3skua2SmVi/w4yCE6gbODqnTWlg7+wC604ydGXA8VJiS5ap43JXiUFFAaQ==, over tor value: AAAAB3NzaC1yc2EAAAADAQABAAABAQCDQ73fwBw1OOjBIrR1TGVVUFn3LCUdVD6Gv0A1Dj2dp235PlHL3qu/w1WPbhS9YcX+OMRVwFOnoWAyZH8XU1/DHx/h21n4HzaVGkgODRuPt3+Q/ytn7Ehb9W3OZLCWCnhoD1HGKATOwhxfv+lLBbi0d37YVnmN6NkUG9db63n74mcj0wySYB+EMVNeoIQBsPiNk6NYDuVukfEsUAxUBBVoA2q117LdmJgdPJojz7wMvCyQMEOm1Vf6aXsTrl7/waCEvYVAgQanBvQMCp0Lq/r8noav8M+o/JMn3JDGqukqmyUG9wMPRoLWRP/RiC3alqTCG09PuqB4GmyvWpvv5iIT 2017-07-29 16:53:05,573 modules.sshmitm [CRITICAL] tor ssh key name mismatch for gitlab.com:22 (52.167.219.168) over exit relay 29378422C99074D06331D5700E47451610B0D20D clear wire value: ssh-ed25519, over tor value: ssh-rsa 2017-07-29 16:53:05,574 modules.sshmitm [CRITICAL] tor ssh key mismatch for gitlab.com:22 (52.167.219.168) over exit relay 29378422C99074D06331D5700E47451610B0D20D clear wire value: AAAAC3NzaC1lZDI1NTE5AAAAIAfuCHKVTjquxvt6CM6tdG4SLp1Btn/nOeHHE5UOzRdf, over tor value: AAAAB3NzaC1yc2EAAAADAQABAAABAQCDQ73fwBw1OOjBIrR1TGVVUFn3LCUdVD6Gv0A1Dj2dp235PlHL3qu/w1WPbhS9YcX+OMRVwFOnoWAyZH8XU1/DHx/h21n4HzaVGkgODRuPt3+Q/ytn7Ehb9W3OZLCWCnhoD1HGKATOwhxfv+lLBbi0d37YVnmN6NkUG9db63n74mcj0wySYB+EMVNeoIQBsPiNk6NYDuVukfEsUAxUBBVoA2q117LdmJgdPJojz7wMvCyQMEOm1Vf6aXsTrl7/waCEvYVAgQanBvQMCp0Lq/r8noav8M+o/JMn3JDGqukqmyUG9wMPRoLWRP/RiC3alqTCG09PuqB4GmyvWpvv5iIT 2017-07-29 16:53:06,957 modules.sshmitm [CRITICAL] tor ssh key mismatch for bitbucket.com:22 (104.192.143.8) over exit relay 29378422C99074D06331D5700E47451610B0D20D clear wire value: AAAAB3NzaC1yc2EAAAABIwAAAQEAubiN81eDcafrgMeLzaFPsw2kNvEcqTKl/VqLat/MaB33pZy0y3rJZtnqwR2qOOvbwKZYKiEO1O6VqNEBxKvJJelCq0dTXWT5pbO2gDXC6h6QDXCaHo6pOHGPUy+YBaGQRGuSusMEASYiWunYN0vCAI8QaXnWMXNMdFP3jHAJH0eDsoiGnLPBlBp4TNm6rYI74nMzgz3B9IikW4WVK+dc8KZJZWYjAuORU3jc1c/NPskD2ASinf8v3xnfXeukU0sJ5N6m5E8VLjObPEO+mN2t/FZTMZLiFqPWc/ALSqnMnnhwrNi2rbfg/rd/IpL8Le3pSBne8+seeFVBoGqzHM9yXw==, over tor value: AAAAB3NzaC1yc2EAAAADAQABAAABAQCDQ73fwBw1OOjBIrR1TGVVUFn3LCUdVD6Gv0A1Dj2dp235PlHL3qu/w1WPbhS9YcX+OMRVwFOnoWAyZH8XU1/DHx/h21n4HzaVGkgODRuPt3+Q/ytn7Ehb9W3OZLCWCnhoD1HGKATOwhxfv+lLBbi0d37YVnmN6NkUG9db63n74mcj0wySYB+EMVNeoIQBsPiNk6NYDuVukfEsUAxUBBVoA2q117LdmJgdPJojz7wMvCyQMEOm1Vf6aXsTrl7/waCEvYVAgQanBvQMCp0Lq/r8noav8M+o/JMn3JDGqukqmyUG9wMPRoLWRP/RiC3alqTCG09PuqB4GmyvWpvv5iIT 2017-07-29 16:53:06,959 eventhandler [INFO] Ran 1 module(s) in 0:00:30.168619 and 0/1 circuits failed (0.00%).

2 2

Unable to get Tor exit relay to run - Ubuntu 16.04
by King Queen 28 Jul '17

28 Jul '17

I'd really appreciate some clueful suggestions or help please - thank you. I'm not new to Tor; I have an existing relay I run, https://atlas.torproject.org/#details/ECC3599DDCFE44C3F28AE0C9DC5DE92847D36… , but I am unable to get a new Tor relay up and running on an entirely different VPS. I am running on Ubuntu 16.04 Server on a VPS on https://box.cock.li/ . On first attempt I couldn't get a Tor relay running, so I started again from scratch, getting the VPS administrator to reprovision the VPS from scratch, to no avail. I SSHed in as root, created a user and made it a sudoer, added public key etc. and disabled root admin. Then I SSHed in as the user, installed ntp and ufw, added ports 80 and 443 to ufw, added the Tor respository and key as per https://www.torproject.org/docs/debian.html.en#ubuntu. I installed tor, deb.torproject.org-keyring and arm, and edited torrc such that it reads: SOCKSPort 0 RunAsDaemon 1 ORPort 443 Nickname kingqueencock ContactInfo ROT13 <xvatdhrra(a)ybirf.qvpxvauvfna.hf> DirPort 80 # what port to advertise for directory connections DirPortFrontPage /etc/tor/tor-exit-notice.html MyFamily ECC3599DDCFE44C3F28AE0C9DC5DE92847D3602B then the "alternative Reduced-Reduced ExitPolicy" from https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy then sudo service tor restart. For all I can gather, Tor isn't running. There are no files in /var/tor/log. ps aux | grep tor returns nothing other than the grep command. arm shows the "Welcome to the Tor network!" initial relay configuration screen, as does sudo -u debian-tor arm. sudo service tor status ● tor.service - Anonymizing overlay network for TCP (multi-instance-master) Loaded: loaded (/lib/systemd/system/tor.service; enabled; vendor preset: enabled) Active: active (exited) since Thu 2017-07-27 19:36:41 UTC; 3s ago Process: 9781 ExecStart=/bin/true (code=exited, status=0/SUCCESS) Main PID: 9781 (code=exited, status=0/SUCCESS) Tasks: 0 (limit: 512) CGroup: /system.slice/tor.service Jul 27 19:36:41 localhost systemd[1]: Starting Anonymizing overlay network for TCP (multi-instance-master)... Jul 27 19:36:41 localhost systemd[1]: Started Anonymizing overlay network for TCP (multi-instance-master). root@localhost:/var/log/tor# ls -al total 8 drwxr-s--- 2 debian-tor adm 4096 Jul 27 19:29 . drwxr-xr-x 7 root root 4096 Jul 27 19:29 .. The odd thing is if I reboot my VPS by sudo shutdown -r now and do ps aux | grep tor there is tor running as a root user. root 435 0.0 0.5 44760 5716 ? Ss 19:40 0:00 /usr/bin/tor --defaults-torrc /usr/share/tor/tor-service-defaults-torrc -f /etc/tor/torrc --RunAsDaemon 0 --verify-config I don't know where that has come from, or if it's a problem. I have had a poke around in init.d and systemd but I am not an expert in those. I am beginning to wonder or suspect the Ubuntu installation image on the VPS may not be entirely clean... If I try to run arm as root, the "new relay" configuration wizard appears and when I quit the tor process isn't running. I'm stuck. Any help very gratefully received. Cheers Doug

3 6

Best practices to move a Tor node?
by Isaac Grover, Aileron I.T. 28 Jul '17

28 Jul '17

Good morning from Wisconsin, What are the best practices with regards to moving a Tor node to a new server in a different country? Is it as simple as securely transferring files to the new server and restarting the Tor service, or are there other procedures to be followed? Thank you in advance. Make your day great, Isaac Grover, Senior I.T. Consultant Aileron I.T. - "Practical & Proactive I.T. Solutions" O: 715-377-0440, F:715-690-1029, W: www.aileronit.com

4 6

The Onion Box v4.0.0rc1
by theonionbox＠gmx.com 26 Jul '17

26 Jul '17

1 0

Tor fuzzying with AFL - issues with virt mem
by Toralf Förster 25 Jul '17

25 Jul '17

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I do fuzz test the Tor sources with AFL using the script in [1]. Today I was faced with the afl message : - - The current memory limit (47.7 TB) is too restrictive, causing the ... Therefore I re-run this: torproject@mr-fox ~ $ cd ~; for i in ./tor/src/test/fuzz/fuzz-*; do echo $(./recidivm-0.1.1/recidivm -v $i 2>&1 | tail -n 1) $i ; done | sort -n 140647294041983 ./tor/src/test/fuzz/fuzz-hsdescv2 210556434775808 ./tor/src/test/fuzz/fuzz-descriptor 211071855558638 ./tor/src/test/fuzz/fuzz-microdesc 230618232257983 ./tor/src/test/fuzz/fuzz-consensus 272676600806400 ./tor/src/test/fuzz/fuzz-http 275960232411072 ./tor/src/test/fuzz/fuzz-diff-apply 280371168541696 ./tor/src/test/fuzz/fuzz-vrs 281200098803455 ./tor/src/test/fuzz/fuzz-iptsv2 281298748667644 ./tor/src/test/fuzz/fuzz-extrainfo 281456722575360 ./tor/src/test/fuzz/fuzz-diff and was wondering about the bug numbers - a previous run few weeks ago gave me the numbers as seen in [1]: # 40880663 ./tor/src/test/fuzz/fuzz-iptsv2 # 40880757 ./tor/src/test/fuzz/fuzz-consensus # 40880890 ./tor/src/test/fuzz/fuzz-extrainfo # 40885159 ./tor/src/test/fuzz/fuzz-hsdescv2 # 40885224 ./tor/src/test/fuzz/fuzz-http # 40888156 ./tor/src/test/fuzz/fuzz-descriptor # 40897371 ./tor/src/test/fuzz/fuzz-microdesc # 40955570 ./tor/src/test/fuzz/fuzz-vrs Now I do wonder, if the new linux kernel, a new AFL (changed from 2.39b to 2.46b recently) or what else is causing this issue ? [1] https://github.com/toralf/torutils/blob/master/fuzz.sh - -- Toralf PGP C4EACDDE 0076E94E -----BEGIN PGP SIGNATURE----- iI0EAREIADUWIQQaN2+ZSp0CbxPiTc/E6s3eAHbpTgUCWXT0GhccdG9yYWxmLmZv ZXJzdGVyQGdteC5kZQAKCRDE6s3eAHbpTiIAAP9ELskbZFoCyr7Ph/unDdPscZtg YTPdO3S3Z/mLWFemUgD/a+zVQd2BV3ZTY+x92/WAQ741VN8h4DO9ee95X+hu3+w= =pFI9 -----END PGP SIGNATURE-----

2 2

PSA: Run a Tor node, lose access to Chinese IPs
by neel＠neelc.org 23 Jul '17

23 Jul '17

Today, I wanted to try to see how the Internet looks behind the Great Firewall of China. I used a public HTTP proxy list (http://spys.ru/free-proxy-list/CN/) listing Chinese proxy servers (meaning getting into Chinese censorship from the US, not bypassing it in China), and guess what? I was already blocked. Why? I suspect that I was running a Tor relay from my home connection (https://atlas.torproject.org/#details/A20840A16CB658024B0D3A0E3F19A9C0E34C8…) Some Chinese websites do load, but many of those who do usually have a CDN outside the Chinese firewall. For example, I can visit AliExpress from my home computer without Tor, but I can't visit 163.com or 2345.com. While I don't care at all for Chinese websites, there are people who do. If you want to access Chinese websites AND run a Tor relay on the same IP address, you may be screwed. Surprisingly, I can sometimes visit Chinese websites over Tor, but it's about as reliable as having Comcast as your home ISP. Proof: telnet 2345.com Optimum Online 100/35 in Westchester County, NY, home computer on same connection as Tor middle node (https://atlas.torproject.org/#details/A20840A16CB658024B0D3A0E3F19A9C0E34C8…) neel@megora:~ % telnet 2345.com 80 Trying 42.62.30.180... telnet: connect to address 42.62.30.180: Operation timed out telnet: Unable to connect to remote host neel@megora:~ % Verizon FiOS 50/50 in Brooklyn, NY, Tor middle node (https://atlas.torproject.org/#details/D5B8C38539C509380767D4DE20DE84CF84EE8…) (this connection isn't exclusive to Tor, it's used when I am in Brooklyn as well): neel@kat:~ % telnet 2345.com 80 Trying 42.62.30.180... telnet: connect to address 42.62.30.180: Operation timed out telnet: Unable to connect to remote host neel@kat:~ % Total Server Solutions in Los Angeles, CA (via an ITL VPS), Tor exit node (https://atlas.torproject.org/#details/0D8211D34F29F51D690303E319766E1B7C28B…) neel@us-west:~ % telnet 2345.com 80 Trying 42.62.30.180... telnet: connect to address 42.62.30.180: Operation timed out telnet: Unable to connect to remote host neel@us-west:~ % Vultr VPS in New Jersey, non-Tor IP used for this website: neel@newwww:~ % telnet 2345.com 80 Trying 42.62.30.180... Connected to 2345.com. Escape character is '^]'. ^] telnet> quit Connection closed. neel@newwww:~ % It seems that IP addresses used for Tor nodes are blocked by the Chinese firewall, even if the same IP address used for a Tor node is accessing a Chinese website outside of Tor. And the little bit of the Chinese Internet which can be accessed on the same IP address as a Tor node is usually on a CDN outside of the Great Firewall. Keep in mind that this article is also available on my website at this URL: https://www.neelc.org/psa-if-youre-running-a-tor-relay-and-are-accessing-a-… (https://www.neelc.org/psa-if-youre-running-a-tor-relay-and-are-accessing-a-…)

2 1

Traffic Confimration Attacks/ Bad Relays
by Kenan Sulayman 22 Jul '17

22 Jul '17

Thanks for your input, Tim. You are correct that I have not taken into account the IPs which are not in the consensus. My exit nodes are regularly attacked -- what caught my attention was not the fact that an extra gigabit of traffic was flowing in, but rather the way it was (*and still is*, on one node) flowing in. The patterns of the traffic seem unusual, because they are precisely timed windows of traffic: 30 seconds of a about gigabit of traffic, 5 minutes (exactly 302 ± 3 seconds, that is) pause, 15 seconds of a about gigabit of traffic, 3 minutes (181 ± 1 seconds) pause, 60 seconds of a gigabit of traffic, 10 minutes (604 ± 2 seconds). This went on for 8 hours on apx1, apx2 is seeing this still. I'm very sure that there is a reasonable explanation for this, but I can't see the reason any client would behave like this. -- Kenan > > On 22 Jul 2017, at 08:00, Matt Traudt <sirmatt at ksu.edu> wrote: > > > > Now, to my observations and the post that was referred to: > > > > /I clearly failed to clarify/ that the "suspicious" traffic which caught > > my interest was about non-Tor IPs entering the network through my exits. > How do you work out what a non-Tor IP is? > > As pastly nicely put it: /> will never be used as a guard by > > well-behaved tor clients./ > Exits won't be used as long-term Guards, but they will be used as > Entry nodes (or receive connections that look like client connections) > from: > * clients via bridges > * clients with UseEntryGuards disabled, including: > * Single Onion Services (to intro and rend nodes) > * Tor2web (to HSDir, intro and rend nodes) > * clients using them as directory guards or fallback directory mirrors, > * bandwidth authorities, > * Tor relays that aren't in the consensus(es) you're using to work out > what a "non-Tor IP" is, > * Tor relays that have an OutboundBindAddress* option, or a route, that > binds to an IP address they're not advertising in their descriptor. > (Some of these categories might be excluded by position weights, I > haven't checked them all in detail.) > > My observations were made using a utility I built using nDPI and sysdig > > (kernel module). > > > > That is, I have observed about a gigabit of traffic entering my exit > > nodes originating /from non-Tor IPs/, causing connections to be > > initiated to middle nodes. > The most likely scenarios responsible for this volume of traffic are: > * clients with UseEntryGuards disabled, including: > * Tor2web (to a rend node using Tor2webRendezvousPoints) > * Tor relays that aren't in the consensus(es) you're using to work out > what a "non-Tor IP" is, > * Tor relays that have an OutboundBindAddress* option, or a route, that > binds to an IP address they're not advertising in their descriptor. > > I have not claimed evidence to "prove" confirmation attacks. I have > > merely observed nearly a gigabit (on multiple nodes, that is) of inbound > > traffic entering the network through my exit nodes, which does not seem > > very reasonable to do unless the goal is attack hidden services. > Proving an attack would be hard: we'd have to rule out all the > exceptional cases I listed above one-by-one. And check the process used > to identify Tor and non-Tor IPs. > T > -- > Tim Wilson-Brown (teor) > teor2345 at gmail dot com > PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B > ricochet:ekmygaiu4rzgsk6n > xmpp: teor at torproject dot org > ------------------------------------------------------------------------

1 0