Re: [tor-relays] Bridge Location matter?
* Astroskis Lists: > I wonder because if, say for a censored country or an area where a > Bridge is required in the first place, would using an US IP not raise > a red flag? [...] Possibly. On the other hand, any bridge or other type of Tor node which is located outside of Censorland is probably harder to access, let alone seize, for Censorland authorities. Other than blocking the foreign IP addresses, there is little the local Big Brother can do. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] wrong country in METRICS
* tor-operator-sahara...@protonmail.com: > i was choose vps for tor node special in small country with small > quantity tor nodes. and METRICS put my node in Germany ))) where are > already a lot of relays. Your nodes' locations make no difference for middle relays. For exit- nodes, the location only has significance if the user who is initiating a Tor circuit explicitly states "I want an exit with country code XY". For the Tor Browser that would require manually changing an on-disk settings file, which I consider uncommon. I suggest you simply ignore what location the metrics page displays. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] wrong country in METRICS
* tor-operator-sahara...@protonmail.com: > How change contry in METRICS? You don't. The location seems to be determined via GeoIP, which is notoriously imprecise, because AS rent IPs to other AS and the location update can take months. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ContactInfo Information Sharing Specification Version 1 released
* Nick Mathewson: > I'd suggest that we should allow UTF-8 for values, at least. Indeed, that should work. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ContactInfo Information Sharing Specification Version 1 released
* nusenu: > https://github.com/nusenu/ContactInfo-Information-Sharing-Specification > This is an effort that started in 2017 as you can see on github. In section "Defined fields" you write: Non-ASCII characters are not supported. I'm not sure if this applies only to keys or also to values? With the availability of IDN (https://unicode.org/faq/idn.html) in email addresses, supporting only US-ASCII values is too limited. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Got my first abuse
* Volker Mink: > TOR needs brave people. Tor needs running nodes and exits. That can be achieved using smart or dumb setups. The latter do not imply "being courageous" in any way. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Wrong IP geolocation
* Mario Costa: > One of my relays is reporting a wrong country and AS Name/Number on > the Tor Metrics page. As you have suspected, this is not a Tor issue but caused by the Maxmind geolocation data. IP addresses change hands between AS and it can take weeks for the database to reflect this. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Got my first abuse
* Volker Mink: > I was running an exit at my home connection for close to one year. I > removed it because normal internet usage became absolutely anoying. > Capchas and DOS-Protections nearly everywhere. No streaming-portal > was running. And lots of complaints from my provider. Which fully confirms that running a Tor exit at home is usually a dumb move, police involvement or not. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Improving Relay IPv6 - RIPE Grant
* NOC: > I see a great benefit here, you could default to IPv6 for everything > and enable IPv4 only as fallback [...] Preferring IPv6 over IPv4 is not even remotely the same as your original call to "lets drop all IPv4 only relays from consensus 2020 finally", as you wrote in message <08fee42f-f45d-a8c4-d4e6-c83c05b4f...@afo-tm.org>. Dropping support for IPv4 nodes would be counterproductive and is not going to happen in the forseeable future, as was clarified here before by teor. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Improving Relay IPv6 - RIPE Grant
* NOC: > than lets drop all IPv4 only relays from consensus 2020 finally. Let's not. Availabiliy of IPv6 varies with country/territory/ISP. While I personally know people who simply don't want to use IPv6 (and I keep prodding them for it), there are others who simply don't have the option. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Improving Relay IPv6 - RIPE Grant
* t...@riseup.net: > I just wanted to let you know that RIPE has announced funding for The > Tor Project to improve IPv6 support on relays. That's great news, congratulations. My Tor nodes already use IPv6, so if you need help with testing updated Tor versions, please let me know. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] 10 Years Torservers.net: Death or Future?
* Moritz Bartl: > I send you and all the others who have been offering assistance > warm greetings and a thank-you, but we need someone to step up as > coordinator. As I wrote last year, I would be willing to help Torservers, but coordinator is not a role I want. > Maybe the better option is indeed to just celebrate its 10 years of > existence and kill it gracefully [...] Based on your description, that might be the best solution. The more complexity/ballast a project has accumulated, the harder it becomes to find somebody to take over. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] 10 Years Torservers.net: Death or Future?
* Moritz Bartl: > This is a call for help! I offered to help last year, but my email to your support address did not result in an answer, so I pretty much shrugged it off. I'm sure I can find that message and forward it to you. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Quoting spam considered harmful
* I.: > How do you block emails when they come from a list address? By not relying on the envelope sender address alone. Milters can inspect the complete message and signal the MTA to discard or reject it. For mailing lists, I use the former, so as not to generate bounces. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Quoting spam considered harmful
* Seby: > This dude just won't stop harassing us with masked advertising, > commercial offers and monetary asks. [...] My mail killfile is useful for discarding mail by specific senders, but quoting their posts negates that effect, so please don't. Thanks. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Spamcop question
* ylms: > smtp:>>smtp.efg.es,587,t...@efg.es,123456>> > [...] > ExitPolicy accept *:587 You allow TCP port 587 (submission). That should not be a problem unless the targeted server fails to enforce authentication for all email submitted via this port. If that is the case, it is a configuration error on the destination server. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor website overhaul -- who deserves punishment?
* Alison Macrina: > I agree with Matthew that your email was very rude. I don't. "Satire, artistic form, chiefly literary and dramatic, in which human or individual vices, follies, abuses, or shortcomings are held up to censure by means of ridicule, derision, burlesque, irony, parody, caricature, or other methods [...]" (From: https://www.britannica.com/art/satire) Oh, the pitfalls of nonverbal communication... > And finally, this is a mailing list for tor-relays. Please stay on > topic. Finally? :-D What nerve. No longer being able to easily access the Tor documentation and source code *is* on topic here. That's the reason I posted in the first place. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor website overhaul -- who deserves punishment?
* Matthew Finkel: > Please be respectful. The tone of this message is disrespectful of the > time, effort, and skill that went into launching the new website. It's > unfortunate you do not appreciate or like the new site, but that does > not excuse you. Disrespectful for you, maybe. I did not name names. Besides, I won't feign to care about time and effort spent when I consider the result not worth said time and effort. I don't hand out medals or diplomas for trying/participating. You probably get the gist. ;-) > This new website is significantly better and more welcoming for the > general population, rather than a small percentage of the population. I respect your right to have that opinion, although I disagree. What metrics you believe to support your "significantly better" I don't know. > If you have suggestions for improving the new design, then please let > us know. I suggest reverting to the previous website design. That design was, IMO, "welcoming for the general population" in the sense that it treated visitors as intelligent beings, capable of reading more than a few buzzwords. I find it alarming that a certain school of web designers these days seem to think their audience has the attention span of fruit flies. From where I am standing, *that* is disrespectful. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Tor website overhaul -- who deserves punishment?
Not sure if this is the right place to vent, but here goes: Whoever changed the Tor website's design seems to a) have a serious vision impairment and b) done his utmost to hide access to the Tor source code. I think the site feels dumbed down to cater only to those with the shortest attention spans (and bad eyesight) now. Also, as a relay and exit operator, I care most about the source code and documentation, not some management summary. Was there no QA process involved before rolling out the new website? Annoyed, Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] AS: "ColoCrossing" - 28 new relays
* Nathaniel Suchy: > It's scary to think there are bad people out there actively trying to > harm our community :( I take it as a compliment. Tor authors and relay operators are having enough of an effect that some entities out there try to undermine us. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Blutmagie retired
* Olaf Selke: > I'm just too lazy to renew the ssl certificate or to switch to > letsencrypt [...] It just has to be said: Creating a single-host Let's Encrypt cert is very easy on Debian Linux, which you seem to be using. Install Certbot, shutdown Apache, run Certbot, modify Apache's certificate path settings, start Apache. I'd offer to do it for you, but somehow I doubt you'll grant me root access to your server. ;-) No pressure. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Blutmagie retired
* starlight.201...@binnacle.cx: > The operator of Blutmagie Torstatus, Olaf Selke has retired the > service. I'm sorry to hear that the service is no longer available. My thanks to Olaf for his long-time work! -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Running an exit node from home
* teor: > I don't understand what you mean by "an exit". Do you mean "the Exit > flag" or "an exit policy that allows some ports"? I put "an exit" in quotes because I think there are different interpretations. I consider a Tor Exit to be a specialisation of a Tor Node which allows connections beyond the Tor network, based on exit rules, and which actually is utilised in that role, based on available bandwidth and consensus weight. > I agree, but each operator can make their own choice. Sure. Deciding to sell bycicles from an inflatable raft at Point Nemo is a choice one could make, but is it a *good* choice? ;-) -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Running an exit node from home
* teor: > If a client doesn't have a circuit to an exit that supports the port > it wants, it randomly chooses an exit that allows that port. Sure, but is the distinction of what is considered "an exit" reflected in the exit flag? And is it truly random, or does the consensus weight factor into it, the latter being what I thought to be the case? My point is that a Tor node not flagged as an exit is pretty much useless for that role, and removing all exit rules is appropriate in my opinion. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Running an exit node from home
* Isaac Grover: > You are correct in that I won't maintain the exit flag without ports > 80 and 443 open, *and* I lose my eligibility for a free t-shirt, *but* > I am not likely to attract attention at my home either. =) No exit flag means your relay will not be used as an exit, just as a regular relay. You can therefore get rid of all exit rules because they won't make any difference. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] exit operators: overall DNS failure rate above 5% - please check your DNS
On 20.10.18 10:33, Toralf Förster wrote: > What about diversity? Running unbound at every Tor relay sounds like > a bad idea. Tor exits benefit from a caching, DNSSEC-capable resolver that is able to handle the required load. Dnsmasq does not handle a high connection count well. BIND9 and Unbound work fine, the latter being easier to setup in a role that suits Tor. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Hetzner bandwidth terms update
On 01.10.2018 18:55, Roman Mamedov wrote: > It appears that Hetzner has changed their bandwidth terms from "20 TB > outgoing per month, then capped to 10 Mbit" to fully unmetered 1 Gbps > connection on most servers: > > https://wiki.hetzner.de/index.php/Traffic/en Thank you for the hint, I changed settings already. However, the website states "All *dedicated* servers have unlimited traffic." (emphasis added by me). Make sure to check the details for individual servers, e.g. using https://www.hetzner.com/dedicated-rootserver/matrix-ex Still, I tip my hat to Hetzner for this move, especially after Digital Ocean implemented their insane bandwidth price hike. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Jerk spammers on tor-relays
On 24.09.18 02:12, Dave Warren wrote: > I don't see anything obvious that addresses my approach (only the > approach of sending a message from a consistent address out slowly, > which has several obvious flaws). Messages are already uniquely identifiable, and your approach is just a variation of the method Andreas described. While it bundles spamtraps, it is still just as easily avoided using trigger address sets in the manner I mentioned before. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Jerk spammers on tor-relays
On 22.09.18 05:32, Dave Warren wrote: > Send a message through the list's outbound SMTP server that looks like > a list message [...] Why this won't work has already been discussed. Please check earlier messages in this thread. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Jerk spammers on tor-relays
On 21.09.18 19:50, Andreas Krey wrote:
> Create a dummy mail address. Make the list server send out mails from
> that address very slowly at random times to the recipients.
Ah, now you're changing the whole situation. We were talking about using
existing ("real") subscribers, and relying on them passing information
to the list admins. You wrote yourself: "Unfortunately that requires
that every spam addressee to respond quickly".
If you're changing the game, then let me put on my (purely fictional)
spammer hat to see where that gets us. :-) Let's imagine I'll subscribe
not only a single trigger account A, but a set A1-An. I only react to
list posts once a random subset of m <= n accounts (with m varying over
time) has received any particular message. Messages can be uniquely
identified after all. Also, I can add random delays before spamming,
and/or spam after collecting a randomly varying number of addresses
before sending out a batch of spam.
That's just what immediately comes to my mind, I'm sure there are more
effective methods of erasing one's tracks. The long and short of it is,
in my opinion, that all spam recipients need to implement their own spam
detection/prevention, and that the mailing list admins would have a very
hard time trying to identify spammers when the originating address is
not a list subscriber.
-Ralph
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Jerk spammers on tor-relays
On 21.09.18 17:43, Andreas Krey wrote: > On Fri, 21 Sep 2018 16:57:29 +0000, Ralph Seichter wrote: > > > How would the list admins ever be able to connect A to B? > > Traffic modulation and analysis. Unfortunately that requires that > every spam addressee to respond quickly [...] I'm not sure what type of spam you are referring to, but when I post to this mailing list I see spamming attempts that are directly targeting my MX, without using the mailing list infrastructure. The list admins would not be able to reliably correlate which subscribed address is "A" even if I shared my mail logs. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] IPv6 on DSL
On 20.09.18 16:54, Paul wrote: > Can Tor cope with a daily changing IPv6 Address? Based on your email domain and your question about a dynamic DSL link, I'm guessing you are considering running a Tor relay at home? As stated in https://www.torproject.org/docs/faq-abuse.html.en : "In general, it's advisable not to use your home internet connection to provide a Tor relay." -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] New Exit-Relay / First abuse issues
On 19.09.18 15:04, tor-markus wrote: > After a little search through my mails I found out that Contabo shuts > down all services within 24h if there is no reply. That kinda sucked > because I run some private services on this machine (different ip). No surprise there, see https://contabo.de/agb.html §5 (4). All ISPs I have had business dealings with do this to counter abuse, with Hetzner reducing the reaction time before shutdown depending on the number of abuse complaints, down to 4h. > Contabo's mail claimed that a 30€ fee would be due in order to cover > their work for disabling and enabling the server. Sounds like scare tactics to me, but like you wrote, that's nonsense. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] SSH login attempts
On 04.09.2018 14:44, Sean Brown wrote: > Using an obscure port only prevents attempts being logged, nothing > else. I cannot agree with that. What an sshd logs is not determined by the port number it is listening on, and the quantity of failed login attempts across my servers is measurably lower when using a non-standard port. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] 4 of Conrad Rockenhaus trial servers are in the top ten exit relays for Canada
On 01.09.18 01:11, Conrad Rockenhaus wrote: > You want me to stop talking about even the cool things we’re > accomplishing thing [...] because of these two, perhaps one yahoos? Ad hominem once again? Tut-tut Conrad, you keep disappointing me. Attempting to insult me because I decide not to do business with you, based on my personal experience, is such a Trumpish thing to do. Still, the person hiding behind a GMail address should man up, I'll give you that. The Tor mailing list is not a billboard, so if you feel the urge to repeatedly advertise and write about "accomplishing thing" [sic], I suggest you set up your own. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Abuse Complaints
On 30.08.18 22:07, Andrew Deason wrote: > For what it's worth, webiron has actually responded to my replies to > their reports before. I'm not saying it's a great use of time arguing > with them, but the replies are actually read by a human (at least, > sometimes). I've had a "discussion" with a WebIron employee once, where I patiently explained about Tor. It ended with him making stupid threats, and since that day I blacklisted W.I. on our mail servers. I think I posted about this experience here on the mailing list some years ago. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Abuse Complaints
On 29.08.2018 12:48, John Ricketts wrote: > For the non-automated emails I reply each time. Same here. At one time I had written a generator script that fills in details of the complaining party, like IP addresses, and adds general descriptions about what Tor is, with links to facilitate further reading. Only very rarely the generated reply was not enough to satisfy or at least placate the complaining party. Unfortunately I can't seem find my script any more. Automated complaints are a different matter. I don't feel the need to converse with Fail2ban or WebIron bots. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] 4 of Conrad Rockenhaus trial servers are in the top ten exit relays for Canada
On 27.08.18 19:11, zimmer linux wrote: > Well done to Conrad - I say. The more, the merrier. I disagree. My personal experience with the trial, or more specifically with Conrad's behaviour, made it clear to me that he is not the kind of person I want to have a business relationship with. The honeymoon phase was quickly over after I said I would not rent VMs for the rest of this year, and what followed convinced me that I definitely can NOT recommend GreyPony IT. Your mileage may vary. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor exit is running but persistently listed as offline by Relay Search
On 03.08.18 16:08, nusenu wrote: > maybe because it happened to re-key? What the heck? How did that happen? > DA61DDB384AA2242A1349C1BD97C970E33EE8CD6 Yeah, when using *this* fingerprint things look right to me. :-/ I guess I'll update MyFamily then... Meh. Thanks, nusenu. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Tor exit is running but persistently listed as offline by Relay Search
Folks, I can't figure out why Relay Search is listing the FreeBSD Tor exit node with fingerprint DB00AF98D21464157AF37BE071F858C56F5220F3 as offline. I have last rebooted the node approx. 24 hours ago, and according to the logs Tor is alive (and 'ps' shows Tor is consuming CPU cycles). I have verified IPv4 and IPv6 connectivity and cannot spot any trouble. Any ideas? The sister exit node (Debian) with near-identical config is chugging along fine. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] What is the different between Tor browser and Tor source code
On 10.06.18 13:53, dave` dave wrote: > First thing First- I'm running Tor-Nodes-Bridge,Guard and Exit. What's that got to do with anything? Many people rack up frequent flyer miles, but that does not imply all these people have the skills to pilot a plane. > i never used source-code and i don't know how it works- not tors > source code and not any other source code. No shame in that, but it defines your playing field for now. > ill ask again and again- its like this platform that you can learn and > people should answer and not thing they are the best! Speaking from long experience, people who know about a given subject should consider carefully how they go about teaching. If you want to learn programming, there are countless ways to do this which hold no risk of you having adverse effects on yourself or others. Novice carpenters don't start with powertools and bandsaws on day one either, no matter the degree of fascination, and it is expected of them to learn how to wield a hammer without hurting themselves or bystanders before moving on to more advanced subjects. > 100% im not agree with you. I can live with that, and thanks to email killfiles your messages won't bother me much from here on out. ;-) -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] What is the different between Tor browser and Tor source code
On 10.06.18 10:22, dave` dave wrote: > i have to change it because there is no other way to make it work the > way i want if i won't change the source code. Tor is a shared medium, and as such it is not about what you want. For weeks you have asked weird questions that convinced me, personally, that you don't understand fully how Tor works, that you apparently don't have the necessary skillset to make useful changes, and that you should therefore not be supported in connecting whatever it is you clobbered together to other Tor nodes. You may disagree with my assessment, but that's my personal take on this situation. Leaving Tor alone, to work as it is intended to work given its design, would be the best option as far as I am concerned. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor Software Update Question
On 24.05.18 08:17, Valter Jansons wrote: > I have not worked on macOS services, but as I understand it, executing > `sudo launchctl stop servicename && sudo launchctl stop servicename` > should do the job for restarting the service [...] That might not work as intended, depending on macOS version and service configuration details. Both "stop" and "start" are legacy subcommands aimed at on-demand services and older launchd implementations. > Maybe just restarting the box is an easier method of restarting the > Tor service. Probably. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] lets stop using central big DNS resolvers (Google, Level3, OpenDNS, Quad9, Cloudflare)
On 13.05.18 15:34, Paul wrote: > Unfortunately the /etc/resolv.conf gets overwritten on reboot. On > Linux I solved that with editing /etc/resolvconf/resolv.conf.d/base. A perhaps easier alternative to consider: # /etc/tor/torrc ServerDNSResolvConfFile /etc/tor/resolv.conf.local # /etc/tor/resolv.conf.local nameserver 127.0.0.1 That will work even if your hoster meddles with the settings, which I have seen happen with virtual/cloud servers. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Change Tor's security settings
On 13.05.18 15:24, dave` dave wrote: > There is a way to cancel/change Tor's security settings(which means > that i can't use same ip for two parts of the circuit-Guard/Bridge or > Middle or Exit) and set him to use the same ip for all his > circuit(Guard, middle and exit). and or instead of doing that can i > set a specific Middle-Relay? If I count correctly, that's the third time you ask basically the same questions using slightly different wording? Repetition won't change the answers you were given. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] lets stop using central big DNS resolvers (Google, Level3, OpenDNS, Quad9, Cloudflare)
On 11.05.18 13:55, Nathaniel Suchy (Lunorian) wrote: > My first thought is to use ISP DNS if it’s available - one of the best > things about Tor is the split of trust so why aren’t we doing that > with DNS? Another alternative is to use trusted recursive DNSCrypt > Resolvers (for example dnscrypt.ca - there are plenty of resolvers > like this so use a search engine of your choice to find them). Assuming you can install whatever software you like, I recommend running your own instance of Unbound on your exit node machines. Current Unbound versions support DNSSEC validation, QNAME minimisation, etc. While using your ISP's resolvers works as a fallback, a local resolver is better and easy enough to set up. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] DigitalOcean bandwidth billing changes
On 02.05.18 18:17, mick wrote: > Following this I went back to Rafael Rosa, the Product Manager at > DigitalOcean who originally sent the email about the changes seeking > clarification. I also had a back-and-forth with DigitalOcean support staff. Sadly, no revelations ensued, so I'll be closing my DO account at the end of this month. /me shrugs -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] control who can connect me
On 25.04.18 16:55, dave` dave wrote: > im running Exit-Relay and i want to control who can connect to my > Exit-Relay, is there a way to do that- though the Exit-Relay settings, > or the SSH settings? I assume by "who can connect" you mean "who can use my Tor node as an exit"? The computer/client who initiates the transfer never connects directly to an exit node, and the exit node never knows from what client request originates. That's a deliberate design decision. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Alternative hoster (Re: DigitalOcean bandwidth billing changes)
On 25.04.18 16:48, Tobias Sachs wrote: > The interesting thing about Hetzer is that only outgoing traffic is > counted towards the billing. D.O. does the same. Still, $0.01 per extra GB is theft in my book. > https://twitter.com/Knight1/status/988868691868749825 Unfortunately I beat your stats by quite a margin. :-P -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Alternative hoster (Re: DigitalOcean bandwidth billing changes)
On 25.04.18 15:38, Nagaev Boris wrote: > > Also, 20 GB monthly traffic allowance are Nice™. > > * 20 TB Argh! Of course I once again meant TB. :-) A word of caution for Tor exits, though: Hetzner allows exit nodes, but they are very strict when it comes to potential abuse. If one does not react quickly enough, network access is automatically suspended. For example, reaction time gets shorter with each repeated report of network scans originating from Hetzner IP addresses, down to only a few hours. If you happen to be asleep at the time: tough. ;-) -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Alternative hoster (Re: DigitalOcean bandwidth billing changes)
On 25.04.18 14:50, mick wrote: > I think I'm immensely lucky to get the service I do. Indeed. I guess DigitalOcean's loss will be Hetzner's gain as far as my business is concerned. See https://www.hetzner.com/cloud . I already use CX11 and CX21 models and they are seriously good, as is Hetzner's service. Also, 20 GB monthly traffic allowance are Nice™. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] DigitalOcean bandwidth billing changes
Oops, need to correct a typo of mine: > a meager 1GB for their smallest model [...] The current monthly bandwidth allowance for DigitalOcean's smallest Droplet is 1 TB, not 1 GB. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] DigitalOcean bandwidth billing changes
On 25.04.18 13:33, mick wrote: > I had an email from them saying that as one or the group > "grandfathered in" back in 2013 I could carry on regardless. Good on yer... DigitalOcean bills for outbound traffic, and with a price of $0.01/GB (sadly not GiB) every TB in excess of a Droplet's monthly allowance--a meager 1GB for their smallest model--will cost an extra 10 USD. Who has that kind of money? -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] DigitalOcean bandwidth billing changes
Looks like DigitalOcean has just begun measuring bandwidth usage "officially", starting yesterday: https://www.digitalocean.com/community/tutorials/digitalocean-bandwidth-billing-faq "Based on our analysis of the historical usage patterns of our customers, less than one percent of users will exceed their pooled allowance." I had heard of the One Percent, but never thought I'd become a part of that illustrious group... :-) -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Let's increase the amount of exit relays doing DNSSEC validation
On 12.04.18 13:05, Alexander Dietrich wrote: > Just to be safe, you could also check the rest of the dig output and > /etc/resolv.conf (or relevant resolver configuration on your system) > to make sure your BIND is being used. I have seen hosters where /etc/resolv.conf is overwritten whenever the system reboots, and in these cases I used the following: # Add this to /etc/tor/torrc ServerDNSResolvConfFile /etc/tor/resolv.conf # /etc/tor/resolv.conf nameserver 127.0.0.1 # IPv6 alternative #nameserver ::1 -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Let's increase the amount of exit relays doing DNSSEC validation
On 09.04.18 13:10, nusenu wrote: > I recommend a local caching unbound (https://unbound.net/) DNS > resolver without using an upstream DNS forwarder. No forwarders indeed. Additionally, I recommend the following settings in the unbound.conf of Tor exits: # Disable logging. log-queries: no log-replies: no # Sent minimum amount of information to upstream servers to enhance # privacy. Only sent minimum required labels of the QNAME and set # QTYPE to NS when possible. qname-minimisation: yes # If yes, Unbound doesn't insert authority/additional sections # into response messages when those sections are not required. minimal-responses: yes Logging might be disabled as a default depending on how your Unbound was built, but I like to make certain. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] How to post to this list
On 29.01.2018 09:44, list member "I" wrote: > Who set the etiquette? That would be the mailing list owner(s). E-mail netiquette, in various forms, has been around since at least the late 80s. A good portion of it can be found in RFC1855 (released 1995), or in texts like "Zen and the art of Internet" (1992). Graramp played fast with a rule himself by using a rather provocative tone, but I think he is correct in pointing out that some people have been rather lax or thoughtless in this list. Top-posting and full quotes definitely make my teeth itch. ;-) -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] >30% of the Tor network runs outdated version: Consider enabling auto-updates
On 12.01.2018 17:05, nusenu wrote: > The motivation for this is that there are a lot of relays (>3000) > running outdated tor releases. This reminds me that I wanted to ask about package updates: I compile Tor from the source code on my Gentoo based relays, so after the announcement of stable release 0.3.2.9 those relays were updated on the same day, just like earlier releases. However, some of my relays use Debian 8 "Jessie" with a limited package set (i.e. no compiler), and apt-get is not yet listing the new Tor release. Would it be possible for package maintainers to announce update availability via the tor-announce mailing list? -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay Search bandwidth graph update issue
On 25.12.2017 23:54, teor wrote: > It looks like you have encountered that gap, at least on the > higher-resolution graphs. You might want to check the > monthly or yearly graphs to see if they still work. I found that the "1 month" and "3 months" graphs have not been updated beyond December 13 or 17, respectively. Graphs "1 year" and "5 years" display more current data. https://trac.torproject.org/projects/tor/ticket/24155 is marked as an enhancement instead of a bug, which I assume means low priority, so I wonder when the monthly graphs might be back in working order again? -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay Search bandwidth graph update issue
On 25.12.2017 12:02, nusenu wrote: > depending on your tor version this might be > https://trac.torproject.org/projects/tor/ticket/24155 "In theory, this change shouldn't cause any trouble." ;-) Looks like bandwidth graphs for my nodes running Tor 0.3.2.8-rc are no longer updated in Relay Search, while nodes running 0.3.1.9 still show up with correct graphs. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Relay Search bandwidth graph update issue
Relay Search shows odd detail information for three of my nodes. The history graphs for bytes read/written per second shows no data beyond 2017-12-13 (one node) or 2017-12-17 (two nodes), respectively. The probability and consensus weight graphs appear correct. Other nodes of mine are shown with up-to-date information for all graph types. Is anybody else experiencing this as well? -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] SOLVED: Failing because we have 4063 connections already // Number of file descriptors
On 15.12.2017 11:12, Toralf Förster wrote: > # cat /etc/conf.d/tor > # > # Set the file limit > rc_ulimit="-n 3" Ah, thanks a lot! Limits were implied by openrc-run/start-stop-daemon, overriding my limits.conf entries. Turns out that /etc/conf.d/tor got deleted, although I have no idea how that happened. I built Tor from the official source tarball and created my own versions of /etc/init.d/tor and /etc/conf.d/tor (both files are part of Gentoo's net-vpn/tor package). I manually re-created /etc/conf.d/tor and verified that the max number of open file descriptors matches rc_ulimit. The relay has now been up for half an hour without logging errors. Thanks again, to both Toralf and r1610091651. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Failing because we have 4063 connections already // Number of file descriptors
On 15.12.2017 10:45, r1610091651 wrote: > could be that your tuning is not being picked up by the distro. Looks like you are right: # cat /proc/3534/limits Limit Soft Limit Hard Limit Units Max cpu time unlimited unlimited seconds Max file size unlimited unlimited bytes Max data size unlimited unlimited bytes Max stack size 8388608unlimited bytes Max core file size 0 unlimited bytes Max resident set unlimited unlimited bytes Max processes 3969 3969processes Max open files 4096 4096files Max locked memory 65536 65536 bytes Max address space unlimited unlimited bytes Max file locks unlimited unlimited locks Max pending signals3969 3969signals Max msgqueue size 819200 819200 bytes Max nice priority 0 0 Max realtime priority 0 0 Max realtime timeout unlimited unlimited us Only 4096 open files max. I did not expect that, because of tor $ ulimit -n 65535 tor $ cat /proc/sys/fs/file-max 101300 What part of the system's configuration could cause the 4096 open files limit, overriding the 65535 I specified in limits.conf? -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Failing because we have 4063 connections already // Number of file descriptors
Since a couple of days ago, one of my relay nodes keeps logging messages like this: Tor[3534]: Failing because we have 4063 connections already. Please read doc/TUNING for guidance. [over 1601 similar message(s) suppressed in last 21600 seconds] I found https://trac.torproject.org/projects/tor/ticket/16929 and an older mailing list thread (and doc/TUNING) that suggest increasing the maximum number of open file descriptors. I now use # /etc/security/limits.conf * - nofile 65535 to raise 'nofile' from 1024 to 65535, which does not seem to make any difference (the logged error message does not change). My relay uses Gentoo Linux kernel version 4.14.5 and Tor 0.3.2.6 alpha. I also tried older versions of the kernel and Tor 0.3.1.9, in several combinations, without success. I also other relays running just fine with the default number of file descriptors (1024). As I mentioned, the problems started a few days ago, around the time I upgraded from Gentoo system profile default/linux/amd64/13.0 to default/linux/amd64/17.0, rebuilding many system packages in the process. Unfortunately I cannot tell what exactly changed. Since the profile upgrade was deliberate and I cannot roll back, I wonder if I can overcome Tor's problems via configuration options only? -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ISP is aking me to send a selfie holding my identity card
> [...] It was fun while it lasted, and although I find it hilarious how upset you are, I am afraid I'll have to cut this short. Welcome to my killfile, and sorry I won't be able to play any further. ;-) -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ISP is aking me to send a selfie holding my identity card
On 08.12.2017 14:48, niftybunny wrote: > As a baby I pissed in a church. I was never in jail for this, thats > why it is legal to shit/piss in churches. Your logic. So now you're saying it is illegal for babies to have a wee in church, and they might be jailed for it? :-))) Also, if the difference between "legal" and "normal" eludes you, you may want to ask an adult. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ISP is aking me to send a selfie holding my identity card
On 08.12.2017 14:29, niftybunny wrote: > > > In Germany you have to send them a copy of your passport before > > > they even get you a server. Got this with Hetzner. > > > > No, you don't have to. What German law do you think would require it? > > http://www.gesetze-im-internet.de/tkg_2004/__95.html > This law. Read it, learn from it. How about you cut down on the attitude, kiddo? I asked my question as I genuinely wanted to know the particular law in question, and I don't see any reason for your incongruous snark. Also, the law states that the service provider *can* (not must!) ask for ID if it is necessary for verification. Like I said, I have never been asked, nor have my customers, so I still don't consider it normal. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ISP is aking me to send a selfie holding my identity card
Quoting myself, because of neurons firing slowly today:
> I have rented servers with several European hosters and have not once
> been asked for ID.
It just occurred to me that some hosters might have considered my credit
card information as an indirect proof of ID ("The credit card company
probably verified this guy") or simply not give a damn as long as they
have this data to make sure they get paid. Then again, there are other
hosters where I use different payment methods, and still nobody ever
asked me for ID.
-Ralph
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] ISP is aking me to send a selfie holding my identity card
On 08.12.2017 02:46, niftybunny wrote: > I do not think they will compromise and this is “normal” behaviour for > a ISP from Europe. I strongly disagree to that being "normal" in any shape or form. I have rented servers with several European hosters and have not once been asked for ID. > In Germany you have to send them a copy of your passport before they > even get you a server. Got this with Hetzner. No, you don't have to. What German law do you think would require it? If you made this experience, in contrast to anybody I know in the business, I would consider this extraordinary. As for Hetzner in particular, neither me nor any of my customers who work with Hetzner were ever asked for ID, let alone a photo. > So, nothing to worry about. I would worry about it! -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] So long and thanks for all the abuse complaints
Quoting myself: > I've had an ongoing debate with a hosting service over a fresh exit > node being abused for network scans (ports 80 and 443) almost hourly > for the last few days. I had the former exit node unlocked an ran it in relay mode for a day. Today I switched back to exit mode, and a few hours after the exit flag was reassigned, I already received the next complaint about an outgoing network scan. The logs sent to me clearly confirm scans taking place, this is not about the hoster being obstinate. Looks like I will have to shut down this particular exit for good if I cannot find a way to prevent it from being abused as network scan central. :-( -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] So long and thanks for all the abuse complaints
On 04.12.17 20:00, Iain Learmonth wrote: > I do wonder how much of this is related to the scarcity of IPv4 > address space, prevalence of reputation systems and fear of ending > up being labeled as "bad". I remember that last year I was notified by said hoster that the IP address of one of my exit nodes had ended up on a blacklist and that I was expected to get the address off that list. Turns out the exit had made connections to a sinkhole address not yet listed with tornull.org. This hoster obviously keeps track of the reputations of the IP addresses assigned to customers' servers. I imagine you are correct to assume that prohibiting outbound network scans has a similar motivation. Also, scans consume resources and hence cost money. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] So long and thanks for all the abuse complaints
On 04.12.17 11:59, James wrote: > As a private individual, after just receiving my 4th abuse complaint > in as many days it's time to stop running my exit node. I've had an ongoing debate with a hosting service over a fresh exit node being abused for network scans (ports 80 and 443) almost hourly for the last few days. I can understand that they are pissed off, and the whole thing resulted in this particular exit being shut down by the hoster. If I could detect and prevent these scans, it would go a long way to avoid having my exit nodes shut down by hosting services. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Atlas is now Relay Search!
On 14.11.17 17:54, Iain R. Learmonth wrote: > Graphs should now be scaling properly, although I'm not sure what I've > done will work in all browsers, if it's still broken please let me know. I see no more graphs outside their boxes in Chrome, Firefox and Safari. One thing that -- for me -- only works in Chrome and Firefox, but not Safari, is the timestamp info shown when moving the mouse pointer over the little circle icons in the graphs. Safari does not present any popup data, the other browsers do. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Atlas is now Relay Search!
https://imgur.com/a/VMJhE -- I see these "graph outside the container box" issues in Chrome, Firefox and Safari. I sure hope it does not just happen to me? -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Atlas is now Relay Search!
I have since removed all cookies and data tied to the torproject.org domain from my Safari 11 cache, and now Relay Search seems to work as designed. I'm glad, of course, but it still seems weird. At least I have screenshots to prove that I did not merely imagine the problems. ;-) -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Atlas is now Relay Search!
On 14.11.17 16:42, Artur Pedziwilk wrote: > Works OK on my Safari Version 11.0.1 (13604.3.5) and macOS 10.13.1 (17B48). Same versions here, but Relay Search does not work for me. URLs that are supposed to show node details don't work either, only the broken query page is shown. I tested this both with existing Atlas bookmarks and URLs copied over from Chrome. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Atlas is now Relay Search!
On 14.11.17 13:52, Iain R. Learmonth wrote: > You may notice that Atlas has a new look, and is no longer called Atlas. I also notice that the "new look" does not work in Safari 11 on macOS 10.13.1 (High Sierra). For shame! Has nobody tested this? Problem detail: When accessing https://atlas.torproject.org/ , the query box and explanatory text are missing in Safari. See screenshot at https://imgur.com/a/XnA9f . Searching works fine in Chrome and Firefox on macOS. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] New on relays and Tor
On 12.11.2017 16:37, Alfredo Bollati wrote: > Is there a way or some steps to follow in order to confirm that my > bandwidth is being used by the relay? https://www.torproject.org/docs/documentation.html.en is a good starting point. Once you have studied the available documentation and are able to ask specific questions, you will be more likely to get answers via this mailing list. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Nyx 2.0 Release
On 07.11.2017 00:41, Damian Johnson wrote: > Hi all, after years of being in the works I'm pleased to announce Nyx! > A long overdue modernization of arm. Thank you for all your work. It is good to have a TTY-only tool available again. > http://blog.atagar.com/nyx-release-2-0/ > https://nyx.torproject.org/ Either I am too tired to see it, or the new web shows no info about the installation process. Your blog mentions "pip install nyx" very briefly, but the web page apparently does not? Also, it might be worth mentioning alternatives to using pip. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
On 01.11.2017 19:45, Damian Johnson wrote: > > 'run_nyx --debug /path/to/log' writes staggering amounts of > > data. From what I see, both DEBUG and TRACE level entries are > > logged, is this deliberate? > > Yup, it's intentional for the debug log to log low level messages. > That's why it's useful. :P Lord give me patience, but make it fast... ;-) Let me rephrase: Is it deliberate that nyx logs both DEBUG and TRACE level messages when I use the --debug option? I would only expect debug level entries. > I'd just need the first minute or so of logs to see what's up with the > connection resolution attempts. That generates many MB of output data through which I'd rather not wade aimlessly, trying to identify what to anonymise/delete. Can I for example get rid of all TRACE entries for starters, or would that render the output useless to you? What other data would I need to remove so you don't get unnecessary insight into my nodes' details? I mentioned auth challenges already. -Ralph P.S.: Perhaps we should discuss this further off-list? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
On 31.10.17 19:05, Damian Johnson wrote: > I assume your user's able to read /proc/net/tcp'? I see the "unable to query connections..." notices on Gentoo and Debian Linux machines. On both platforms, the permissions are as follows: $ ls -l /proc/net/tcp -r--r--r-- 1 root root 0 Oct 31 19:33 /proc/net/tcp > If so then mind running 'nyx --debug' and sending me the log (minus > anything you consider private)? I'd like to help, alas 'run_nyx --debug /path/to/log' writes staggering amounts of data. From what I see, both DEBUG and TRACE level entries are logged, is this deliberate? I can see auth challenges and whatnot, so I am not exactly sure what I need to remove before sending logs to you. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Testers needed for Nyx beta release
Hi Damien, the current version of nyx still produces event notices like these when run as a user that is neither root nor the tor user ([sic] for the missing spaces): 10:33:26 [NYX_NOTICE] We were unable to use any of your system's resolvers to get tor's connections.This is fine, but means that the connections page will be empty. This isusually permissions related so if you would like to fix this then run nyx withthe same user as tor (ie, "sudo -u nyx"). 10:33:11 [NYX_NOTICE] Unable to query connections with netstat, trying lsof 10:32:53 [NYX_NOTICE] Unable to query connections with proc, trying netstat In a discussion here some weeks ago, it was pointed out to me that it is in fact *not* recommended to use "sudo " to run nyx. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Is AboveClouds still active?
Does anybody here know if AboveClouds https://aboveclouds.co.uk is still in business? Emails sent to their support address have been unanswered for a month now. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)
On 09.10.2017 16:25, jpmvtd...@laposte.net wrote: > You thought dnsmasq was a caching DNS resolver, but it is a caching > DNS forwarder Hold on: Now *you* are deciding what *I* supposedly thought? :-D Since you read my mind, you can see what I am going to think next, and I don't need to waste any more time trying to offer advice to you in this thread. /me tunes out -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] unbound and DNS-over-TLS (dnsmasq configuration for an exit relay (Debian))
On 08.10.2017 23:05, Santiago R.R. wrote: > I would also suggest to use DNS-over-TLS, so (exit) relays could be > able to encrypt their queries to a privacy-aware DNS resolver [...] I like SSL for the resulting cost increase in listening to a connection. However, the Unbound documentation states: ssl-upstream: Enabled (sic) or disable whether the upstream queries use SSL only for transport. Default is no. Useful in tunneling scenarios. Do you have any data on the percentage of queries that fail with SSL *only* because upstream nameservers don't support SSL? I imagine the majority of servers don't support it (my own authoritative nameservers among them). Also, manually adding forward-zone entries implies trusting specific servers beyond the regular root zone servers, which rubs me the wrong way. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)
On 08.10.17 22:40, teor wrote: > This is only true if your resolver implements QNAME minimisation [...] > Does the version of the recursive resolver you're using do this? Unbound implements this, and via qname-minimisation-strict one can even disable the default fallback of sending full QNAME data if the initial lookup with minimal QNAME fails. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)
On 08.10.17 21:40, jpmvtd...@laposte.net wrote: > Disclaimer : this is a (too) big email. Seriously? Can you really not answer to individual messages? ;-) > it is not necessarily better to ask directly to a root name server. Yes it is; for uncached lookups, one of the root zone servers must be involved anyway. As of today, that will be one of thirteen servers, and I'd be extremely surprised if an attacker could monitor them all. > who is aware of the query is not all that matters ; the apparent > origin of the query also matters, depending of the position of the > attacker. Sure, but keep in mind: Even if an attacker could gain access to all root zone servers, he could not see the necessary follow-up queries on TLD level (e.g. country domains, or .com, .net, etc.) and beyond. If I looked up host.somedomain.fr, a root zone snoop might show my interest in a French domain, but nothing else. > If the attacker can listen the traffic between the exit node and the > upstream resolver, I don't think contacting the upstream resolver > directly is better than contacting it indirectly. So what? If the attacker can hack your ISP's infrastructure to listen in, this whole discussion is academic. Otherwise, "the upstream resolver" varies with each individual query, unless one configures the upstream servers manually. Hence, leaving the local resolver to freely choose upstream servers is preferable. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)
On 08.10.17 21:23, Igor Mitrofanov wrote: > you seem to be more concerned with minimizing the number of hosts > involved in a DNS lookup, and you (correctly) believe that running a > recursive resolver yourself, as opposed to delegating it, decreases > that number. Yes, that's what I have been trying to communicate; I hope I was not too long-winded. Keeping the number of involved servers as low as possible is important for Tor nodes, and I'm happy to live with the small extra cost of running a caching resolver on my nodes to achieve this goal. Unfortunately both individuals and ISPs seem to recommend using Google's infamous 8.8.x.x servers, for convenience if for no other reason. If I can avoid it, I will personally not use servers located in Mountain View (that's where GeoIP tells me these machines are) or elsewhere in the US, where the hoster might be willing or even required to keep logs of DNS lookups that can be correlated to my hosts simply by the originating IP addresses. > I assume, however, that most of these ISPs have no technical > capability or business incentives to be engaged in Tor traffic > correlation. Quite. I choose ISPs in countries that, to the best of my knowledge, have laws that would make it difficult and time-consuming for the NSA, GCHQ or other intelligence services to get access to logs by legal means. > I am making an assumption that Tor relays sending DNS requests to a > large and diverse number of destinations can make practical DNS-assisted > traffic correlation prohibitively expensive. That's what I hope, and I am trying to do my part to increase that cost. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)
On 08.10.17 20:48, Igor Mitrofanov wrote: > Unbound's upstream requests can be intercepted and used in traffic > correlation just like any other. I thought I expressed myself clearly enough, but I'll try one more time. Unbound, or any other resolver, can either a) perform the recursive lookup or b) delegate the lookup. Case a) is preferable in regards to profiling because it does not involve additional third-party servers that have nothing to do with the query. Case b) involves third-party servers, so it offers more points where traffic can be analysed. Looking up host.somedomain.tld should, if no cached data is available, only involve one of the root zone servers, one server for the tld zone, and one server for the somedomain zone. It should not involve a resolver run by Google or other parties that have no business in knowing that my Tor node just looked up host.somedomain.tld. > Yes, Unbound follows the recursive protocol and works with the > hierarchy from the root DNS servers down, but your ISP can still > observe your entire DNS activity. I have explicitly stated "If the ISP hosting the Tor node has resolvers for their customers, these can be used as well, *since the ISP sees all outgoing traffic anyway*". Are you deliberately trying to misunderstand me? -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)
On 08.10.17 19:48, Igor Mitrofanov wrote: > My hosting provider runs no DNS servers and recommends using 8.8.x.x, > so I have to pick something. You don't have to pick, and this is not meant to be patronising. Install Unbound with the few lines of configuration I posted earlier in this thread, and set your /etc/resolv.conf to "nameserver 127.0.0.1". Unbound will contact upstream servers as required. You don't have to configure *any* upstream servers manually. See https://en.wikipedia.org/wiki/Domain_Name_System "Address resolution mechanism" for what will happen under the hood. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)
On 08.10.17 18:34, Igor Mitrofanov wrote: > Unless configured otherwise, Dnsmasq chooses a server from the list > randomly, so the more servers the operator specifies in dnsmasq.conf, > the less traffic each server gets. The "proper" way, meaning the way resulting in the smallest surface for behavioural analysis of the node outside the ISP hosting the node, is to not manually configure any upstream servers at all for the caching resolver running on the Tor node. That way, only upstream servers that are actually required to resolve individual queries are contacted. If the ISP hosting the Tor node has resolvers for their customers, these can be used as well, since the ISP sees all outgoing traffic anyway, but I can't think of any reason to use third-party resolvers (especially the infamous Google 8.8.x.x) beyond the hosting ISP. The historic notion of "don't contact upstream resolvers directly" from a time where traffic was expensive is no longer valid, especially for a Tor node where the key goal is to make it harder for third party actors to analyse what the node is doing. > I have not seen any research papers that would indicate that the cost > of running a full DNS server on an Exit relay is worthwhile and that > it improves anonymity substantially more compared to a lightweight > cache resolver. I don't know what you call "a full DNS server"? A caching resolver should, by its nature, contact all upstream nameservers as required, including the root zone servers. There is no need for Unbound, BIND or similar resolver software to delegate queries only to a manually configured and therefore limited list of nameservers. Just let these resolvers do their job. From what I see on my nodes, the cost of Unbound is negligible, compared to what Tor itself requires. Unless you can produce research papers that show it is *not* worth letting my resolvers contact upstream nameservers as they consider necessary, I'll stick to advocating what I wrote above. ;-) -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Unbound (Re: dnsmasq configuration for an exit relay (Debian))
On 08.10.17 11:46, Toralf Förster wrote: > May I asked, why you prefer unbound ? The OP was concerned than dnsmasq "could introduce vulnerabilities if not handled properly, because it provides more than just local DNS cache". In contrast, Unbound has a single purpose(*), and I found it to be a reliable, low-impact combination with my Tor nodes -- especially on nodes with scant resources -- that needs very little config data and was designed with security in mind. I did not mean to say Unbound is the only choice, just that I strongly prefer it over dnsmasq. For my authoritative nameservers I use BIND, but when a resolver suffices, as is the case for Tor nodes, I use Unbound. -Ralph (*) http://info.menandmice.com/blog/bid/37244/10-Reasons-to-use-Unbound-DNS is one example blog about Unbound. The DNSSEC config can be much simpler though, when using auto-trust-anchor-file. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)
On 08.10.17 09:47, Toralf Förster wrote: > IMO there's absolutely no advantage of using external DNS servers. "No advantage" is putting it too mildly. Manually specifying upstream servers runs contrary to the very reason to have a resolver on the Tor node in the first place, which is to only involve the necessary minimum set of servers for each query. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] dnsmasq configuration for an exit relay (Debian)
On 07.10.17 19:39, jpmvtd...@laposte.net wrote:
> It looks like this package could introduce vulnerabilities if not
> handled properly, because it provides more than just local DNS cache.
Unless you have a particular reason to use "dnsmasq", I strongly suggest
you use "unbound" (https://www.unbound.net) instead. It supports DNSSEC
and is very easy to configure. Here's a config file for a Tor node with
both IPv4 and IPv6 interfaces:
# /etc/unbound/unbound.conf
server:
interface: 127.0.0.1
interface: ::1
root-hints: "/etc/unbound/named.cache"
log-queries: no
verbosity: 0
Optional: If your node has multiple IP addresses and you want to use a
specific one (usually one not used for Tor) for outbound connections,
add the line "outgoing-interface: {your-ip-here}" to unbound.conf.
While "log-queries: no" is the default setting, I always add it anyway,
in case the unbound authors decide to change this in future releases,
however unlikely.
-Ralph
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] About relay size
On 29.09.2017 10:18, IPonU wrote: > http://www.digicube.fr/rapidserveurs DigiCube notes "Offre uniquement valable pour la France métropolitaine". Has anybody asked if non-French customers are also welcome? Have they agreed to hosting Tor nodes, especially exits? My French is rusty, and I could not find answers to these questions on their site, and I get only timeouts when trying to connect to the DigiCube forum. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Two-step abuse management?
On 13.09.17 18:48, Moritz Bartl wrote:
> Mind sharing that configuration, and maybe even the filters you
> already set up?
My method is highly Postfix-specific, but I can see that you use Postfix
as well. ;-) Here is an example for sender-based rejection (incomplete):
smtpd_sender_restrictions =
check_sender_access pcre:${config_directory}/sender_access
# pcre:sender_access
/abuse-reporting\.webiron\.com/ REJECT
That line alone catches most of the useless generated complaints. W.I.
holds a special place in my heart due to past misbehaviour, so I don't
even bother telling them how to contact me any more and flatly reject
all their robot messages.
Combine this with recipient-based checks (incomplete again):
smtpd_recipient_restrictions =
check_recipient_access pcre:${config_directory}/recipient_access
# pcre:recipient_access
/^abuse\@tordom\.tld$/ REJECT Please use https://foo/ to report abuse
I imagine you already have a (captcha-protected) ticket system in place.
Finally, sprinkle header- and/or body-based checks into the mix:
header_checks = pcre:${config_directory}/header_checks
# pcre:header_checks
/^Subject:.+fail2ban generated abuse report/ DISCARD
Not that I actually recommend using DISCARD, mind you, it is just another
example. Should you require more specific information about what Postfix
checks can do, contact me off-list. I'm guessing you know about these
very powerful checks already.
-Ralph
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Two-step abuse management?
On 13.09.17 15:49, Moritz Bartl wrote: > We're thinking about introducing an auto responder to abuse mail which > then requires clicking a link or replying to the mail again before the > complaint actually reaches a human. What do you think? For my exit nodes, I have tested rejecting obviously auto-generated complaints on arrival (SMTP code 5xx), with a customised text stating how a human can get in touch with me via a different, unpublished mail address. No human has yet used this second address, but my method sure saves me time by weeding out most robot-generated complaints. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] HOW-TO: Simple DNS resolver for tor exit operators
On 12.09.17 23:43, Roman Mamedov wrote: > > I take it you're being ironic? > > Guess I failed at doing that well, if you had to clarify. (Or maybe > you didn't read my entire message.) I did read it. Just the pitfalls of non-verbal communication, and I'm also not a native English speaker. ;-) > Running your own authoritative nameservers is laudable as well, but the > current discussion is about recursive resolvers. You know, the likes of > 8.8.8.8 and the ones your ISP runs for their clients "to reduce traffic". If you read *my* messages in this thread, you'll find that I am fully aware of this. I even mentioned Google's infamous resolver by IP. :-) I came across one ISP so far which does not provide resolvers for their customers but points resolv.conf to Google's servers. Not good. > Note that 'dnsmasq' won't do, that's just a caching proxy to a fixed > set of a few upstream DNS resolvers; you need 'unbound' which IS a full > independent DNS resolver itself. Yeah, I use Unbound and BIND myself, with the former of course being much more frugal in terms of resource requirements. Easy to set up, too. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] HOW-TO: Simple DNS resolver for tor exit operators
On 12.09.17 23:06, Roman Mamedov wrote: > Too bad DNS servers are not something a regular person can own, so we > have to be at mercy of those shady all-knowing uber-powerful Owners > of the DNS Servers. I take it you're being ironic? These days, if you want to get serious about controlling your own domains and not relying on other people's server infrastructure, all it takes to run a pair of nameservers (that's the minimum due to IP address range constraints) is the raw knowledge how to do it and about $10, or local currency equivalent, for two virtual servers. DNSSEC, key-based server synchronisation, the works. One might say that the more people run their own nameservers, the harder it gets for attackers to gather data or interfere with the DNS system. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] HOW-TO: Simple DNS resolver for tor exit operators
On 12.09.17 23:00, jpmvtd...@laposte.net wrote: > An attacker can try to find what websites a Tor user has visited, by > comparing : > - the timing of Tor user home connection traffic and > - the timing of DNS queries happening on DNS servers controlled by the > attacker I'm aware of that. With a caching resolver running on the exit node, the only "DNS servers controlled by the attacker" would have to be upstream, the ones required to resolve what the Tor client requested in the first place. Your idea of query noise does not mitigate the risk of upstream DNS servers being taken over or monitored by an attacker. I run redundant DNS servers which host all of my domains (which are DNSSEC signed), and caching resolvers on all my Tor nodes. That's tough to mess with. The problem is that people don't always run their own exit-node based resolvers, but forward to Google's infamous 8.8.8.8 et al. People should at the very least check if their respective ISP runs caching resolvers, which most do to reduce traffic. -Ralph ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
