- tor-relays - lists.torproject.org

increasing per IP tor instance limit (2 instances per one IPv4)
by nusenu 10 Jul '17

10 Jul '17

Roman Mamedov: > Another idea that I proposed some time ago is raising the > relay-per-IP limit is there a trac ticket for this already? AFAIR that limit primarily exists mainly to increase the price for Sybil attacks, but since they would be trivially detected (i.e. by OrNetRadar), I do not see why increasing that limit would hurt (much) on the other side: Is there an actual demand for increasing that per IP limit? If you have been impacted by that '2 instances per public IPv4'-limit and would benefit from an increase please speak up -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

3 2

Load balancing (with IPVS) multiple Tor daemons
by Clodo 09 Jul '17

09 Jul '17

The objective it's making a single Tor Relay and using on the machine many daemons on a multicore server. I hope someone can give me a feedback if this kind of configuration can be problematic for Tor network before test in a real environment. Many Tor daemon, with X from 0..n, binded on different port, all advertise the same ORPort/DirPort. An IPVS load balancing at kernel level. Tor Config: SocksPort 0 Nickname superrelay Address superrelay.net ORPort 443 NoListen ORPort 127.0.0.1:100X NoAdvertise DirPort 80 NoListen DirPort 127.0.0.1:200X NoAdvertise DataDirectory /var/lib/tor/childX All daemon have the same SocksPort, Nickname, Address, MyFamily. All daemon point to different DataDirectory, but each of them have the 'keys' directory identical. All daemon advertise the ORPort 443 and DirPort 80, but bind on other ports. IPVS configuration: # Clear ipvsadm -C # Add a virtual server (-A) for ORPort. ipvsadm -A -t superrelay.net:443 -s sh # Add a virtual server (-A) for DirPort. ipvsadm -A -t superrelay.net:80 -s sh # Add all real servers/daemons (-a) for ORPort ipvsadm -a -t superrelay.net:443 -r localhost:1000 -m ipvsadm -a -t superrelay.net:443 -r localhost:1001 -m ... ipvsadm -a -t superrelay.net:443 -r localhost:100X -m # Add all real servers/daemons (-a) for DirPort ipvsadm -A -t superrelay.net:80 -s sh ipvsadm -a -t superrelay.net:80 -r localhost:2000 -m ipvsadm -a -t superrelay.net:80 -r localhost:2001 -m ... ipvsadm -a -t superrelay.net:80 -r localhost:200X -m Note the scheduling method: sh - Source Hashing: assigns jobs to servers through looking up statically assigned hash table by their source IP addresses. Any source-ip will be always binded to the same daemon. I think 'Advertised Bandwidth' on onionoo/atlas can be inexact. I can experiment a relay like that, or can be problematic/unexpected for Tor network? Thanks for any feedback.

4 5

Wikileaks Unveils CIA Implants that Steal SSH Credentials from Windows & Linux PCs
by I 08 Jul '17

08 Jul '17

https://wikileaks.org/vault7/#BothanSpy

1 0

Re: [tor-relays] Exit flag and port 6667 vs 6697
by Igor Mitrofanov 05 Jul '17

05 Jul '17

> Port numbers and TLS ore orthogonal: port 443 can be used for cleartext, > and port 80 for encrypted traffic. In the case of IRC, it's quite common > for 6667 to be used with TLS. When a relay operator uses exit policies, I believe they express an intent to block certain types of applications, and not just ports those applications typically run on. They mean to block HTTP when they block port 80, and they mean to allow HTTPS when they allow port 443. Exit relay who use anything but "accept *:*" engage in application-level traffic censorship to balance their risk with their contribution (if this is not a form of censorship, what are exit policies really for?). Both port-based exit policies, designed when ports meant much more than they do today, and the definition of the exit flag, seem obsolete. Ports no longer allow Tor users or relay operators to manage their risks well, and the exit flag policy does not allow the Tor community to protect the network against P2P abuse and optimize it in any meaningful way. For example, as a Tor user, how can I express my desire to only use exit nodes that refuse to see any plaintext traffic - where's that checkbox in the Tor browser? As an exit relay operator, how can I minimize the abuse risks often associated with insecure protocols? As a member of the Tor community, how can I understand why making _historically_-plaintext traffic on port 6667 (as opposed to usually encrypted traffic on ports 993, 995, 587, 6697) part of the minimum contribution is optimal for the network? Long-term, I believe that Tor will need to move away from port-based policies to standard / verified / signed deep-packet-inspection plugins. I do have a short-term proposal though (below). > The current Exit flag requires 2 ports out of [80, 443, 6667]. > Can you clarify what the two options are that you are suggesting here? For starters, I would propose making it possible to run an Exit node without relaying traffic to ports designed to carry insecure protocols. That would mean a change as simple as "two ports from [80, 443, 6667-OR-6697]". Later, I would ask the Tor project to study the traffic (by port numbers) and re-examine the port-based exit policy system in general. > And the Exit operator would need to set up DNSCrypt or similar. > Otherwise Exit DNS requests are trivially monitorable. I am using dnsmasq with a large (65536) cache and several 1ms-latency upstream DNS servers it randomly picks from. I believe it should be sufficient to complicate the DNS-assisted timing attacks that I am aware of. Thanks - Igor > Message: 4 > Date: Wed, 5 Jul 2017 08:08:25 +1000 > From: teor <teor2345(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Exit flag and port 6667 vs 6697 > Message-ID: <F84DD3E5-F83F-4B13-A5CF-7A518687B719(a)gmail.com> > Content-Type: text/plain; charset="utf-8" > > >> On 5 Jul 2017, at 05:29, grarpamp <grarpamp(a)gmail.com> wrote: >> >>>> ... >>>> >>>> My current, rather paranoid, list of accepted ports looks like this: >>>> 20-21, 53, 443, 993, 995, 6667. I am not sure how useful this is to >>>> Tor, and whether I will actually avoid complaints, but I guess I can >>>> only wait and see. >>> >>> Most Tor traffic is HTTP or HTTPS, and the HTTPS proportion is growing. >>> So this is useful. >>> >>>> My question is about 6667 - should Tor's 'Exit flag policy' allow 6697 >>>> (IRC encrypted over SSL) as an alternative to 6667? I would rather >>>> support people using 6697, if I had the choice. >>> >>> Some IRC services allow or require SSL on 6667, others require it on >>> 6697. Why not enable both? > > I really do think this is a good way to tackle this issue: > we should encourage relay operators to enable *both* 6667 and 6697. > > The flag minimum requirement really is a minimum. > >>> So I can't see a strong case for switching to 6697, given that the Exit >>> flag is only a hint to relay operators about the minimum useful ports. >> >> 6667 cleartext is there because tor is old... it was widely prevailing then. >> 6697 TLS became widespread much later, especially post Snowden. >> >> What does survey of IRC nets regarding TLS capabilities look like today? >> Do users have some need to connect, out via exit, to [any particular] >> cleartext IRC services, for something that TLS IRC services do not provide? >> Do we continue endorsing cleartext upon operators who seek minimums >> and/or proffer to carry non-monitorable e2e traffic to avoid legal issues? > > Port numbers and TLS ore orthogonal: port 443 can be used for cleartext, > and port 80 for encrypted traffic. In the case of IRC, it's quite common > for 6667 to be used with TLS. > > And the Exit operator would need to set up DNSCrypt or similar. > Otherwise Exit DNS requests are trivially monitorable. > >> Does cleartext insistance therein funnel users into choosing possibly >> harmful cleartext transports due to better speed / latency / probability of >> successful exit paths? >> What are consensus bandwidth capacity and exit node counts for 6667:6697? >> What is the traffic ratio of 6667:6697 actually exiting the network? > > Good question. > We don't collect stats on individual ports, because it's hard to do > safely. > >> I suspect switching minimum to 6697 is fine, or at least making it >> logical OR. > > The current Exit flag requires 2 ports out of [80, 443, 6667]. > Can you clarify what the two options are that you are suggesting here? > > 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 > ------------------------------------------------------------------------ > > > >

2 1

IPv6 to IPv4 tor exit relays would fix many daily tor-problems
by Fof582 05 Jul '17

05 Jul '17

I have access to a fast internet connection. This connection only have ipv6 IP and i can access the IPv4 network over the ISPs 6to4 bridge. So there are already many users using one single IPv4 address at this ISP. Sadly its technical as far as i understood at the moment not possible to run a IPv6-only exit node. If i could run such, the people on the world that could access IPv6-adresses also would be able to connect to my IPv6 exit node. Then they can finally access over IPv4 all the webpages that normally block tor users, bother them with captchas, ... Such tor-users could also finally access freenode irc again. I would like to give such service-blocked tor users again access to all websites of the internet by providing such a 6to4-tor exit node. Is there any progress at this?

5 10

What is the right repo for Redhat/CentOS Tor?
by tor＠t-3.net 05 Jul '17

05 Jul '17

The files in the repo location we have configured have not changed recently, and I know that Tor's been updated. The repo we're configured for is based out of: https://deb.torproject.org/torproject.org/rpm/el/6/x86_64

2 1

Exit flag and port 6667 vs 6697
by Igor Mitrofanov 05 Jul '17

05 Jul '17

Hi, I am trying to run a few Exit relays on my 1 gbps connection. To keep donating the exit capacity to the Tor project I have to keep abuse reports to a minimum. In order to have the Exit flag I have read that I have to keep two of ports 80, 443 and 6667 open, plus allow exiting to at least one /8 network - is that still the Dir spec? Is it correct that without the Exit flag, no clients will choose the relay for their circuits - even if its Exit policy allows the port they need? For example, take a look at the "cry" relay (one of top 10) - it is not marked as "Exit" as it only allows ports 6660-6667 - does that mean it is only ever used as a middle relay? I have read that port 80 generates quite a bit of abuse complaints as it is used to tunnel non-HTTP traffic, by malware, etc. So, choosing ports 443 and 6667 to get the 'Exit' flag looks like the safest choice. I have also read that ports above 1024 are more likely to used by BitTorrent clients, so they are to be rejected in order to minimize abuse. My current, rather paranoid, list of accepted ports looks like this: 20-21, 53, 443, 993, 995, 6667. I am not sure how useful this is to Tor, and whether I will actually avoid complaints, but I guess I can only wait and see. My question is about 6667 - should Tor's 'Exit flag policy' allow 6697 (IRC encrypted over SSL) as an alternative to 6667? I would rather support people using 6697, if I had the choice. Thanks, Igor

3 3

Multiple relay instances, debian + systemd
by Paw Møller 04 Jul '17

04 Jul '17

Dear all, I run an exit node on debian strech, fingerprint 13E75F70220903A68BAF1F80B3DA9AB913961841 I would like to use more bandwidth, but I'm unsure how to do that with systemd. So, Lets say I want two exit nodes, each at 20MB/s. As per https://www.torservers.net/wiki/setup/server#high_bandwidth_tweaks_100_mbps, I am supposed to use tor-instance-create tor{1,2} [1] systemctl enable tor@tor1 etc. but what goes in the individual tor@tor1 torrc in /etc/tor/instances/tor1/torrc and what goes in the main instance in /etc/tor/torrc? Looking at the status for the new instance systemctl status tor@tor1 Process: 22722 ExecStartPre=/usr/bin/tor --defaults-torrc /var/run/tor-instances/tor1.defaults -f /etc/tor/instances/tor1/torrc --verify-config it seems the main torrc is not read, so maybe this is just an fancy way of doing the "old" /usr/sbin/tor -f /usr/local/etc/torrc1 /usr/sbin/tor -f /usr/local/etc/torrc2 ... with separate configurationfiles and datadir? I have a few extra ipv4 addresses. Should I allow each instance it's own IP or is sharing fine with one having (80,443) and the other (9091,9030) as (QR,DIR)port? I am aware that one IP can only be shared between two instances. Another question: Should I set the NumCPUs option to 2 or just leave it at 0(default)? https://www.torproject.org/docs/tor-manual.html.en#NumCPUs The processor is a bit old: Model name: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz pidstat 5 -p `pidof tor` Linux 4.9.0-3-amd64 (tiger) 2017-07-01 _x86_64_ (4 CPU) 23:38:33 UID PID %usr %system %guest %CPU CPU Command 23:38:38 127 10706 38,60 16,80 0,00 55,40 2 tor 23:38:43 127 10706 37,20 14,20 0,00 51,40 3 tor 23:38:48 127 10706 33,20 12,20 0,00 45,40 3 tor 23:38:53 127 10706 41,00 11,80 0,00 52,80 3 tor 23:38:58 127 10706 46,40 14,80 0,00 61,20 2 tor And finally: Do you change the number of maximum file descriptors? As of now, cat /proc/sys/fs/file-nr 9248 0 163085 where ls -l /proc/`echo $(pidof tor)`/fd | wc -l 5866 Best, Paw [1] http://manpages.ubuntu.com/manpages/zesty/man8/tor-instance-create.8.html

4 3

[warn] channelpadding_ and [warn] assign_
by Felix 03 Jul '17

03 Jul '17

Hi everybody On 3.1.3a there are quiet some log entries like 10 per day and relay, more cicuits - more entries: [warn] channelpadding_compute_time_until_pad_for_netflow: Bug: Channel padding timeout scheduled 212ms in the past. Did the monotonic clock just jump? (on Tor 0.3.1.3-alpha dc47d936d47ffc25) and [warn] assign_to_cpuworker failed. Ignoring. Seems without impact to performance. I just wonder. Switching to 3.1.4a might fix it ? 3.0.8 doesn't show it. [] Tor 0.3.1.3-alpha (git-dc47d936d47ffc25) running on FreeBSD with Libevent 2.1.8-stable, OpenSSL LibreSSL 2.4.3, Zlib 1.2.8, Liblzma 5.2.2, and Libzstd 1.2.0. -- Cheers, Felix

3 2

Reminder: Support for 0.2.4, 0.2.6, and 0.2.7 will end on 1 August 2017
by Nick Mathewson 03 Jul '17

03 Jul '17

Hi! This is a reminder that we will not be making new releases for the 0.2.4, 0.2.6, or 0.2.7 release series after 1 August 2017. If you are running one of those series, please make a plan to upgrade some time before then! 0.2.5 will still be supported until 1 May 2018. 0.2.9 support will continue until 1 Jan 2020 -- use that if you need a release that will be supported long-term. Versions 0.2.3 and earlier are not supported at all. Support for other releases (0.3.1 and 0.3.0) will continue according to the schedule at https://trac.torproject.org/projects/tor/wiki/org/teams/NetworkTeam/CoreTor… . I'll send out another message like this in early July. peace, -- Nick

1 1