- tor-relays - lists.torproject.org

Tor relay dying in FreeBSD
by Farid Joubbi 14 Jul '17

14 Jul '17

Hello, I just installed a new relay in a fresh FreeBSD installation. The relay starts fine, except for a warning that I don't understand. Then it dies all of a sudden. The time before it dies is different every time. I have googled for the warnings but could not find anything. Does anyone here know what is going on? Tor 0.3.1.4-alpha (git-fab91a290ded3e74) running on FreeBSD with Libevent 2.1.8-stable, OpenSSL 1.0.2j-freebsd, Zlib 1.2.8, Liblzma N/A, and Libzstd N/A. Jul 12 23:44:24.672 [warn] You appear to lack permissions to change memory limits. Are you root? Jul 12 23:44:24.672 [warn] Unable to raise RLIMIT_MEMLOCK: Operation not permitted .... Jul 12 23:44:29.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Jul 12 23:44:30.000 [err] Out of memory on realloc(). Dying. It's the tor-devel version installed from ports. Thanks in advance.

3 3

Tor on FreeBSD: Failed to find node for hop 0 of our path. Discarding this circuit.
by neel＠neelc.org 14 Jul '17

14 Jul '17

Hi, I recently got a dedicated server from Joe's Datacenter running FreeBSD (it's for a Tor exit node) and when I try to start Tor, I get this error: Failed to find node for hop 0 of our path. Discarding this circuit. Other FreeBSD installations I have with Tor, on both VPS providers as well as personal machines I own do not have this issue. Do you know what could be causing this? -Neel Chauhan

2 1

no abuse complaints?
by Erik Winter 13 Jul '17

13 Jul '17

This might be a bit of a weird question, but I keep wondering about it, so I'll try it anyway. Since April I run an exit node, this one to be precise: 84FAA41C7A7E83EC18964683E1DBA4B6C9E63492 According to Atlas, it works as it should. I have an exit page and a whois, both with valid email adresses. There is some spam filtering, but I also check that folder. In those months, I have received no complaints at all. Not one mail was sent about the exit. Now, this is of course a good thing. We don't want complaints. But it is not what I expected and what I prepared for, so I keep wondering whether I'm doing something wrong. I live in The Netherlands and the level of education about Tor is supposed be high. That might keep authoroties from complaining, but I also heard about bots that send copyright violation notices. So far, they haven't been able to find me Any ideas? Erik Winter

2 2

keys.gnupg.net broken; can't add Debian Tor repo
by tor 12 Jul '17

12 Jul '17

I'm trying to follow the instructions here to install Tor from the official package repository: https://www.torproject.org/docs/debian.html.en On the steps to add the gpg signing key, it doesn't work. It seems something has changed with the keyserver at keys.gnupg.net: 1) http://keys.gnupg.net/pks/lookup returns a 404. 2) Trying to manually visit the root of the domain [http://keys.gnupg.net](http://keys.gnupg.net/pks/lookup) in a browser results in a redirect to https://keys.gnupg.net/wiki/. Here SSL is broken due to a cert mismatch. The cert is for "uz.sns.it". I'm not sure what's going on. Is [keys.gnupg.net](http://keys.gnupg.net/pks/lookup) hacked, or something more mundane? Anyone know how to work around this? Is the signing key available from any other trusted keyservers?

2 2

Re: [tor-relays] keys.gnupg.net broken; can't add Debian Tor repo
by paul＠paulfurley.com 11 Jul '17

11 Jul '17

On the SSL issue: keys.gnupg.net is an alias to the SKS keyserver pool, which is a number of public volunteer run servers: https://sks-keyservers.net/status/ My guess is you hit a misconfigured one that redirected you to TLS without checking what host you requested. For example I redirect http://keyserver.paulfurley.com to https://keyserver.paulfurley.com *only* if the requested host is keyserver.paulfurley.com. Otherwise I would serve a certificate with a mismatching domain. I'd recommend posting your finding to the sks-devel mailing list since it's probably something the pool should look out for and warn servers they're misconfigured. (I'll post it in the morning if you like.) Paul > > On Jul 10, 2017 at 10:58 pm, <tor (mailto:tor@anondroid.com)> wrote: > > > > Actually, the directions on https://www.torproject.org/docs/debian.html.en work okay. I was trying to automate things with Ansible, but the format changed at some point, from something like: > > > > apt_key: id=A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 url=http://keys.gnupg.net/pks/lookup?op=get&search=A3C4F0F979CAA22CDBA8F512… > > > > to: > > > > apt_key: id=A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 keyserver=keys.gnupg.net > > > > The URL at /pks/lookup no longer exists, so I saw a 404. Using the newer format with just the hostname of the keyserver it works okay. > > > > Regarding http://keys.gnupg.net I still don't know why there is a SSL mismatch in the browser, or why you can no longer access the web UI, but it's not as broken as it looked. > > >

2 1

Windows relay performance: svchost process
by Vort 10 Jul '17

10 Jul '17

Hello. Since connection count for my Windows 7 relay began to grow, I have started to notice unusual CPU load pattern. That's a periodical spikes every ~8 seconds. First I was thought that this spikes are generated only by tor.exe process, but then I have found that svchost.exe process have identical spikes (I guess they belong to NlaSvc system service). Do anyone know why this can happen? Here is the screenshot: https://s8.hostingkartinok.com/uploads/images/2017/07/6fe01ab8601548f95ba47… -- Vort

1 0

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 08 Jul '17

08 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