Re: [tor-relays] Politically correct?
torser...@datakanja.de: > From the information, i can gather on my own personal computer, i can > see, that almost every operating system sends out greetings to servers > in akamai's reach, a company that happens to have contracts with > microsoft and whatnot. > Reading about their business, i find every reason to believe, that the > time to fight for anonymity on the net is long gone, that security - > even from their perspective - needs more resources than any individual > will ever be able to have at its disposal. > Also, i am aware of the possibility to get tracked by the > telecommunication provider anytime and without me noticing it. The entire point of tor is that (in theory) anyone who can see who you are, can't see what you're doing, and anyone who can see what you're doing, won't know who you are. But: tor works at a routing level, and you can be deanonymized through applications leaking data; this is why things like Tor Browser exist, to mitigate a large portion of this leakage. tor as a network seems to do a good job, probably the best form of internet anonyminity, much focus is on deanonymization on the application layer, simply because it has a wider attack surface and is more likely to return a better idea of the user's identity, than say, a potential IP address. > My conclusion has been, that i am maybe 30 years too late in my activity > to support tor - as a simple relay -. And the companies that seem to > have most control over the internet (like google, akamai, and others) > are in the process to control more and more of it, and only for that > reason are fighting against malware like viruses and bots, and of course > also fighting tor (by using honeypots as well as intrusion into the > community to get as much information as possible about the people trying > to hide in anonymity). Facebook, Akamai, Google, and others have all helped tor in some manner. Again, their tracking takes place at an application layer, and Tor Browser takes steps to lower their ability to do so. > This seems to be so true to me, that i begin to feel _guilty of > nourishing false hopes_, that any individual could feel safe by using > tor, irrespective of where and how legitimate/needed their requests are > originating from. You seem to be suffering from "Privacy fatigue." > Seriously, i am beginning to think, that tor may be somewhat outdated > nowadays, basically operating on old assumptions, about how the net was > organised merely a decade ago. And not taking into account the reality > of today, where our little community may not be all too useful any > longer. Hard to hide some disappointment, as i used to be a developer > many years ago, and find that no one - apart from myself - refuses to > cooperate in the process of accumulating data, which provides the basis > for semi-automated analysis later, and help some authorities to excert > power and control over the population living on this planet. Push for the turn: Many are complaining modern webpages are bloated, causing everything from browser slowdowns, to unneeded data usage on mobile networks and spreading malware. If something like 'Flattr' can become popular as a way of supporting websites' income, it would pave the way to kick ads off. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Arm phantom keystroke issue.
Matt Helps: > Hello. > > The node we run is in our library and we have a raspberry pi SSH'ed into > the node and an LCD displaying the output from Arm. Arm is bugging out on a > random basis and appears to be receiving a C keystroke that I believe is > the clear log command. I ran the pi with no keyboard and I even used > another machine to display the ARM output from the SSH session and it did > the same thing. Has anyone else seen this and is there a solution? Yes, it's a known issue that has been in arm for a while, random clobbering of the output and even random 'xx' and 'cc' commands. > It's a > real bummer because we use this as a learning tool in our library and the > pretty graphs of incoming and outgoing traffic really get people > interested. When this phantom keystroke happens the graphs stop and > somebody has to press N on the keyboard to get the pretty graphs rolling > again. This can happen in 2-3 hours or upto 12 hours. See pic here. > http://imgur.com/a/wrMhT A nasty fix might be to send a fake esc or ^L keystroke every minute or so to restore normal output. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] I'm Running A Tor Exit Node And NEVER Initiated It
Does this happen to be "your" node? https://globe.torproject.org/#/relay/4544D4026D447CDA4F8E7F22ED73E8565CCA569E ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] TOR router install without access to root
Markus Koch: > possible or do I have to ask my hosting company for the install on a > shared server? I think it would not be recommended on a shared server for reasons ranging from less-private privkeys to a company that sells shared hosting probably wont be letting you run a relay in the first place. But yes, tor should be able to run fine without root. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] 130 "11BX1371" relays joined on 2015-10-30
tor-server-crea...@use.startmail.com: > should relays add some lines to torrc like reject *.fingerprint? The authorities should be rejecting the relays / dropping their traffic soon, I assume now they're trying to contact the operator before doing that. On another note, reject allows cidr notation, so something like ExcludeNodes 185.99.184.0/22,185.45.72.0/23 should work. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] 130 "11BX1371" relays joined on 2015-10-30
Tom van der Woerdt: > Should they actually be blocked though? > > I mean, it's a lot of relays, but they're also contributing actual exit > bandwidth and it's not like they're spread over hundreds of /16s. I was just about to write a bit of clarification actually: They shouldn't be in a position to be able to really de-anon anyone via sybil, the oldest relays seem to be 3 days old, so there's still at least another 4 until they can get Guard, and that will still take a while to get users on it. Not to mention tor doesn't build circuits with more than one node on the same /16 (although now this batch has taken on another range) Though, they could have already set up a number of guards prior to this that may not be obviously linkable to the same entity. Assuming this is not the case, for now they just have a better advantage at sniffing/injecting as an exit, but you should already be (trying to) use encryption as much as possible. With intentions and scenarios unknown, it could also be someone who wants to help, there /was/ a call for exits not too long ago, after all. So, If you're a relay, you shouldn't bother trying to filter these, the Authorities should figure it out. If you're a client, I guess that's up to you, there might not be a whole lot of benefit if you do. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] IPv6 vs IPv4 exit policies
If I recall correctly: Policies with '*' for the address count as both ipv4 and v6 policies, it is possible to use 0.0.0.0 for v4 and [::] (I think) for v6-specfic policies. spriver: Hi, I just activated IPv6 support for my two exit relays today, but I do not unterstand/misconfigured the exit policies. I just want to open certain ports at IPv4 (the common known reduced exit policy) and open all Ports at IPv6 except 25. How do I configure such a thing? Current sample config is: [snip] IPv6Exit 1 ExitPolicy accept6 *:* ExitPolicy reject6 *:25 [full reduced exitpolicies snipped out] ExitPolicy accept *:50002 # Electrum Bitcoin SSL ExitPolicy accept *:64738 # Mumble ExitPolicy reject *:* But at Globe only this is visible: https://globe.torproject.org/#/relay/F5B1FC9038A5A65FF16D6729AAB2AEDD67F D2F2A https://globe.torproject.org/#/relay/D9D7A9C203C99945D0DCBD545A20C0CB936 7C742 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] A bridge too far
jchase: Hello, Can anybody help me figure out why my bridge has stopped showing the flags fast, running and stable? Especially stable, I would love to get that flag back. I run two bridges, on two different Rasp Pi's, the one with a globe fingerprint of B08284109C72C81ACF5866A17A4CC64CE3E16499 . The other with a globe fingerprint of 1BCD3EBEFE17EEB86EEDE21D5E2DB8468E2864CF . The first bridge runs with obfs 3 4 on a Pi 2. It seems I lost the stable flag around the time I got obfs 4 up and running. The second bridge runs only with obfs 3 on an older Pi. I've read that the stable flag is quite handy. Any ideas about how I can get it back? Greetings, J Chase 1BCD3EBEFE17EEB86EEDE21D5E2DB8468E2864CF looks fine, B08284109C72C81ACF5866A17A4CC64CE3E16499 however doesn't even have the running flag, which seems odd. Just a guess: Has your bridge entered hibernation mode? Can you check its logs for anything suspicious? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] (n00b) Exit node question
Just a guess: iirc, putting an asterisk (*) for ExitPolicies, it's counted as AF_UNSPEC, thus adding the rule for both ipv6 and ipv4. Since policy rules are considered in the order they're listed (ie rules stated first override later rules), the ExitPolicy reject6 *:* being first, counts as rejecting *:* totally. Try setting both reject rules last, if that works maybe you can merge up rules for a simpler config And, thanks for running a relay. Hong, Yongmin: Hello, it's my first time running an exit. (Well, I'm n00b in running a relay too :p) I think I followed the guidelines correctly to be an exit (with some modification from reduced exit policy on trac), but atlas and globe reports that my exitpolicy is reject *:*. My configuration is at [1]. Please tell me what's wrong here. Thanks! [1]: https://phabricator.wikimedia.org/P740 -- Revi https://www.revi.pe.kr -- Sent from Android -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Leaseweb exit relay notice
blaatenator: * Port 25 * Port 194 * Port 465 * Port 587 * Port 994 * Port 6657 * Ports 6660-6670 * Port 6697 * Ports 7000-7005 * Port 7070 * Ports 8000-8004 * Port 9000 * Port 9001 * Port 9998 * Port Were you using the recommended reduced exit policy? It seems like it'd block most of the ports they're complaining about: https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy If you haven't, you might want to start now, and make sure it covers the extra ports they're mentioning, to make them happy. You may also want to see the other of tips for running an exit node with less harassment: https://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Please enable IPv6 on your relay!
Aaron Hopkins: I tried configuring this a while ago, but got confused by what appeared to be conflicting documentation for IPv6 exit policies. Is the ExitPolicy for IPv6 completely separate (only using accept6/reject6 lines) or does it also make use of lines like ExitPolicy accept *:80 which mention a port but not an IPv4 IP? Wildcard accept/reject policies seem to catch both IPv6 and v4 going from the comment (and code) in src/or/routerparse.c[1]: /** Parse the addr policy in the string bs/b and return it. If * assume_action is nonnegative, then insert its action (ADDR_POLICY_ACCEPT or * ADDR_POLICY_REJECT) for items that specify no action. * * The addr_policy_t returned by this function can have its address set to * AF_UNSPEC for '*'. Use policy_expand_unspec() to turn this into a pair * of AF_INET and AF_INET6 items. */ [1] https://gitweb.torproject.org/tor.git/tree/src/or/routerparse.c?id=tor-0.2.7.1-alpha#n3354 (Opening that link may hang tbb for a bit) ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
