Re: [tor-relays] Received botnet/drone abuse complaint
I received a botnet/drone complaint from shadowserver.org today If the complaint was sent directly to you, rather than to you via your ISP, it is unlikely you need to do anything. Unless you're concerned about possibly having your own IP space blacklisted (which is normally an ISP concern). If your ISP is bugging you, there are some abuse templates and general advice docs on the Tor project site that you may find useful. If I'm reading this correctly, they identify mebroot as the source of the That's probably the nasty that was sent, not necessarily the scan and injection platform in use. My DirPort is set to 80, which may explain that value in the complaint. No, that's more likely to be the 128:80 dest ip/port pair for the flow sourced from your 210:48586 pair. You might find the log format documented at Shadowserver or via google. They obviously didn't bother to include a complete definition of all the fields in the email. Any thoughts on what to do to avoid further complaints? Shadowserver addresses the topic of Tor exits here: Try blocking traffic to that IP or some suitable larger subnet of the afflicted IP as might be determined from whois or BGP, for a few months. It's seems to be just a probe, nothing a simple email or config change won't fix. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor relay system uptime requirements
With this set-up I see the Tor process consuming 2% of CPU, about 60MB of RAM (RSS) used 100 - 200 connections active at any given time. Seconded. It's not much. And irrespective of hardware, seconded also on using current OS, build libs and Tor. Some OS require setting kernel sysctl to enable extra cpu's or cpu features. BIOS too. But that intel-HT is not worth anything. My ISP currently provides me with ~ 800 kbps in upload ... 15 Mbps in download but I guess it is better to keep it symmetric It's bytes in/out of the closed circle that is your box/interfaces. Other than encapsulation differences, non-symmetric is not physically possible. You can set up OS rate limiting to let Tor freely use whatever when you are not using the pipe. But I don't know how to properly let Tor know you are doing that??? (other than telling Tor it's own rate limit should be the entire possible size of your pipe, as would be the case when Tor is allowed by OS to free run during your non usage. Tor would get squeezed otherwise, but that's probably not too bad.) I have also thought about using the PC of my parents as a bridge Not a good idea to subject anyone but yourself to the potential issues of being an exit :) So a non-exit or bridge is better. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] How to protect yourself from network scanning
I've thought about constructing iptables rules to limit the number of SYN packets for the same host per second or such Multiple flows to the same host don't really bother routers of any class. Old routers choke when looking up many hosts in the routing table. So your proposed rules against port-scanning single hosts wouldn't help. Unless each SYN to a host is generated from multiple Tor-based IP-scanner's, in which case your node or Tor would probably be underwater from the parallel scans anyways. Is there a known proper way to protect yourself from being used as a network scan relay? You can't really implement rules to block IP-scanning because you'll just take yourself offline. Which is exactly what ISP's do when their router falls over. The problem is fixed at the source, not the dest. In the TCP only case of Tor, best you can easily do is 'reject *:port' the ports being scanned, thus denying service to the scanner's Tor client and thus emitting no such traffic yourself. If it's well-known ports, such is life for your relay. I am hosting a 3-5MB/s tor exit relay ... does not want to route network scanning traffic since it is a severe load to their routers. If they can't deal with a single host doing IP-routing lookups, sounds like they need to replace their 10yr old Crisco routers or exit the biz. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Call for discussion: turning funding into more exit relays
Is there any justification for a low-bandwidth Tor node? Other than the diversity of having more nodes around... seems from discussions here that slower nodes see less users. Which means they're not as likely to be blocked by content providers for user misbehavior. This can be valuable for the legit users who manually pick slower nodes to see if they can get through. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Help the Tor Project by running a fast unpublished bridge
Sorry for exposing the internals of running a non-profit. But I think transparency is especially important here. :) I don't know why you feel sorry. Transparency is important for non-profit, at least for most I guess. Non-profit is just a tax and legal designation. After any necessary compliance with that, the degree of transparency, salaries paid, competitiveness, degree of being closely held, and indeed all other things... is completely variable. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Bad exit
Exit (one of these two I think, no guarantees): 109C56AC68DB55D16E79F832E19313E6C3E47363 67FD1D03F922975269F94EC7E4FD38C6D0E5E900 - torservers? It's not occurring now via them, but whatever exit it was generated these... Error: mail.google.com uses an invalid security certificate. The certificate is only valid for the following names: *.mywebdav.de , mywebdav.de (Error code: ssl_error_bad_cert_domain) Erroneous public key presented: aa 94 04 12 c4 32 2b c9 62 48 00 88 16 6f cd 8a 21 22 fe 6d 9d 51 63 6f 85 62 db 9c b5 3f e6 bf 1d 45 ca 51 57 3d 5f 83 97 73 b6 dd 99 86 d8 27 e5 07 71 94 cf d5 a4 92 a6 25 f8 06 fd 50 6c ad 70 2c 71 ca 66 38 1d 35 93 f1 c3 ff 52 6a 90 3d 54 fd 6f 69 34 9f 59 29 aa 05 59 91 95 33 53 8b e6 b6 cf 65 dc 02 1a 31 57 d8 f4 11 70 f5 68 46 13 af c1 dc f0 b0 ce 43 b3 13 61 8a 18 00 84 32 2b 9a 9c aa 49 f3 fc b6 a1 d2 a9 d9 bd b4 53 a0 60 46 e7 e9 22 9d 23 08 5c 91 32 89 e7 85 4e ec 18 b7 d0 b3 6b 74 fa b4 f3 08 11 1f 1b e1 55 e9 7b 90 f4 64 93 08 a2 58 70 e0 c6 41 f9 f9 d0 9c b1 3d e9 b6 ae b3 73 ac 11 d3 f6 91 9e 79 f2 b4 d7 7d 96 8a 83 30 b1 bf 40 6f 18 24 42 43 b7 b1 65 7e 3d 1f d2 47 e9 fb 2e 10 21 7c ce 20 a8 c3 35 f3 d8 91 d1 a6 a1 87 52 4b de 39 1e ec b9 4d ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Map of Tor Relays updated
quite useful for placing new nodes. thx moritz. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Deploy relays using hidden exit IP's?
Shouldn't some exit relays (funded or not) be deployed to use an exit IP that is different from it's advertised exit IP in order to prevent a simplistic form of blocking based on scraping the descriptor set? I think this can happen if the default route is out another interface or secondary address. Something of that nature. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Deploy relays using hidden exit IP's?
Also related, has anyone tried operating an exit behind a VPN/NAT/proxy service? As opposed to having secondary interfaces/routes on the local machine. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Prepared for [Raided for running a Tor exit node]?
Running an exit node from home DSL or Cable is bad idea. One must look for a Tor friendly ISP and have balls made of steel! ... ISP[/hoster] and[/or] have ... However, I do not believe it is that way in the United States What 'way'? Running an exit node at home, or elsewhere, would seem to come down to... a) Are you physically ready for a query / subpoena / search warrant / exigent raid? Are things segregated by room? Are your doors and machines labeled with the same sort of exit node notice you'd put on the TCP port and in DNS? Have you inventoried, photographed and documented your setup and property? Do you have offsite backups? Are private things encrypted? Are any co-habitants aware and similarly prepared? b) Are you mentally ready? Is your life and butt otherwise clean, legal, and organized? If you were to appear in court, how would you act and be perceived? How do you feel about being in the news and in public docs? Have you networked with other operators and entities? c) Are you legally, financially, and timewise ready? Have you consulted with and preselected a couple attorneys? Have you made arrangements for making bail? How will you make court required appearances? All these sorts of meta things, and surely more, come into play whether or not you're ever raided. I'd suggest making a wiki article for them. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Prepared for [Raided for running a Tor exit node]?
Only regarding home Wireless access in the US I was involved in a case with just this situation. According to my lawyer there is no consensus on who is responsible for wifi. Every State has different laws each one is just a vague. In NY, if your wireless is secured (pw protected) you are ok. In NH, you are responsible for all data that passes your wifi point secured or not. In MA(my state) there is no specific law Putting links to such laws on the Tor wiki would be useful for operators and users to know. It would seem hard to believe that there are 'must secure' laws [1] in the US or elsewhere. Even harder that anyone would be sentenced... regardless of whether their AP is open, 12345, or dR;$8w@G... merely for traffic traversing their AP/node that was not theirs, or that cannot be proven was theirs. Not that you wouldn't be questioned, charged or held before the case was dropped. [1] There are 'must secure' civil ISP contracts. They are only meant to 'secure' more revenue (no account/line sharing) for the ISP and save revenue from dealing with whatever headaches your open AP/node creates. And criminal 'theft of service' laws for the same reasons. you just need a good lawyer :) This (and links to the actual laws) are much easier to believe. Because if someone here took the NY example above literally and did illegal deeds via their secured wifi thinking that example was the law (and thus their immunity), they be jailed pretty quickly. And what does being forced to secure or responsible mean? If you hit a bug, exploit, or get cracked, and can show it, you're jailed? What if there is no proof either way but the existence of traffic, is the user then jailed by default? What if no evidence but crypted disk, or questions as to character/belief? In those crazy places even 100% lily white users would seem better off running an open AP/node and risking that lone lesser charge [2] than attempting to be rather secure, risking a crack, and being held responsible for some major crime. [2] If the major wasn't dropped, at least they'd be jailed with evidence the access was open, which looks a lot better than if it wasn't. The crazy is why you're supposed to visit, write, call and email your lawmakers, educate your executive, and hang your jury. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Prepared for [Raided for running a Tor exit node]?
In NH, you are responsible for all data that passes your wifi point secured or not. Where is this codified? NH - This is a Bill that has passed, but not signed into law... https://www.gencourt.state.nh.us/rsa/html/LXII/638/638-17.htm https://www.gencourt.state.nh.us/legislation/2003/HB0495.html Use the full text. This bill attempts to clarify/legalize using someone else's wifi when I(a)(1)-(3) are reasonable assumptions... commonly such as when the operator has not 'secured' their wifi... the it's open, so it must be ok defense. (Defense to a charge by an annoyed operator, a look, a user in their car! charge by the police, or an accessory charge to a greator crime of the defendant.) It tries to make 'know/belief' easy for the lay user to assume by using the word 'secure' and attempting to create some kind of obvious 'security' wall but it doesn't define what that boundary is. What about the day when there is some popular 'click here to go online' tool that does WEP guessing in the background behind a pretty GUI? Your belief may have just changed, and not in a good way. Next, note that 'shall be responsible for securing' does not mandate any given security level... be it open, at any other level, or by any given means. While you could seemingly document your 'security' choice as open, closed, or whatever (to satisfy whatever action this clause is trying to make you do)... the choice itself makes no difference to us because: It doesn't say anything about the operators culpability for what traverses their wifi/node. The context of that clause, and the bill and code as a whole, appears to be regarding users and is of no use or affect regarding operators. Which is what this list cares about and would like to know. That's one interpretation, call a lawyer and make your own. Other interpretations and background... http://www.wired.com/gadgets/wireless/news/2003/04/58651?currentPage=all In NY, if your wireless is secured (pw protected) you are ok. Where is this codified? Penal Code Section 156.05 Unauthorized use of a computer A person is guilty of unauthorized use of a computer when he knowingly uses or causes to be used a computer or computer service without authorization and the computer utilized is equipped or programmed with any device or coding system, a function of which is to prevent the unauthorized use of said computer or computer system. Again, this applies to the user. Every state has similar laws. I won't bother to link or pick at this one. Other than to laugh at how the operator's 'equipped' but disabled choice might make open access a crime. So if you're used to leeching in NH, stay the hell away from NY :) ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Traffic pattern on Tor relay
From time to time that the traffic oscillates with a period of about 14 seconds and the traffic doubles in the peaks. 1? Some buffer fill/pause/empty cycle somewhere during a large transfer. Try building a circuit through your node and transfer large to eliminate your node if cycle is not always present during this xfer. 2? Cyclic process[es] loading your node. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Are you looking for node diversity?
I'd prefer to stay away from the US. (That said, the 1st and 2nd place remain the same in this case.) Exit probability is interesting: 43% chance of exiting from a US-based node. Also, I feel for that poor guy in Chile. Try posting up on some of the lists/forums... isp-planet, datacenter, nanog, etc for service in South America, Africa, India, Mid-East, Hong Kong, Korea... wherever needed. For better prices, consider mentioning the capitol and/or cable landing cities by name. For legal separation, say that you're looking for a locally (in-country) owned/operated company, as opposed to some global biz. Subject: 'typeOFservice providers in place?' Also google: site:cc vps/dedicated/whatever hosting ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [tor-talk] On the Theory of Remailers
It is an interesting questions, if with a modern user interface, can they get to new life? I see no reason the state of the art from the legacy remailer types can't be combined and updated into a new service running on some of the same relay machines we have for Tor today. Even if only 10% ran them it would probably be more hosts than were ever behind the old remailer nets. And relay operators already have the abuse experience in place. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Ongoing denial of service attack against Tor relays by leased botnet in America and PRC (Nobistech, Datashack, Limestone, HE, Pegtech, WholeSale Interent, and Psychz VPS nodes, etc)
New to the list, I run a Tor exit node from my small cable modem connection in Honolulu, as well as for a short time on a few on VPS's to prove to Over the last several weeks, I have collected substantial evidence indicating that a botnet is degrading the Tor anonymity network in its entirety via a sustained denial of service attack. I believe it is made to blend in with all the other crazy packets that an exit node generates, but it is pretty easy to spot if you just look at the RST's or drops coming off your node, all from a static unused destination port. If you change the IP address of your node, it will take about 90 minutes before they identify your IP and you start getting attacked again. Do a whois lookup on a few of those VPS IP addresses and you will see the country involved. Wondering what other folks are seeing with their relays. UTC DATEUTC TIMEIP SRC-ISP SPT DST DST-ISP DPT Flags 2013-03-28 7:33:38 173.208.95.126 Nobis Technology Group, LLC 2571 66.8.214.196Road Runner 8118[S] I believe 8118 is polipo/privoxy gateway and that you are simple seeing usual internet 'bot' scans for that proxy and box is returning normal closed reset to syns. You may collate this flow data by ip and report the unwanted traffic to the arin netblock and ptr domain contacts. Or ignore it as waste of time if packet rate is acceptable loss to internet noise. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] BitTorrent complaint
tor could easily be made to efficiently use a similar mechanism, if it doesn't already in order to perform the lookups to compute the answer to What is the subset of exit nodes allowing exit to IP addr X on port Y? The answer may lie with the client polling some exits and computing the answer to its needs locally. I just posted a blurb about this to tor-dev. Anyone interested may want to follow up and add on over there. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] BitTorrent complaint
Bittorrent may be an exception to the above but the performance cost would be at the clients end and for one bittorrent is hardly a realtime protocol a little delay making each connection would not make much difference, two it performs poorly if you insist on running it over tor anyway and thirdly the average consumer desktop system is not exactly lacking spare CPU cycles due to the bursty nature of their workloads they statistically tend to spend the majority of their time idling. As opposed to torrenting via exits, I'm amazed more people haven't moved their torrenting to operate entirely within anonymous networks. The performance of I2P and Tor (and I guess Phantom during tests) is actually quite usable so long as the user excercises content selection and patience. And regarding this thread, the freedom of operators and users from complaints regarding takedown would be invaluable. I'm not sure if these networks could scale to handle the node count and chatter, but I think the bit about spare cycles is right and might even act as a natural limiter to that sort of traffic. For instance, my tests show that establishing connections to many onions in parallel is quite costly and prone to failure without available headroom. But once connected, things are ok. Perhaps torrenters simply can't put aside their 'must download it all right now' mentality which keeps them away from our nodes. Or there is a major influx waiting to happen upon some future enlightenment whether they're misguided or not. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [tor-talk] NPA to urge Internet providers to block users of hijacking software [Tor]
http://mainichi.jp/english/english/newsselect/news/20130418p2a00m0na013000c.html to voluntarily block communications if an anonymous software system ... is found abused online. The second ripline leaves some room but is without specifics. It seems they are blurring the line between recommending that websites refuse to answer connections from the Tor network, vs recommending that ISPs prevent their users from reaching the Tor network. The panel specifically recommends that communications be blocked when there is access from IP addresses publicly listed as those allocated to the third in a chain of computers that are used by Tor. This quote clears that up to be the former. However, it appears they also intend to ask network operators to block exits as well, not just websites: http://mainichi.jp/select/news/20130418ke040232000c.html Based on the recommendations, the National Police Agency to encourage voluntary efforts such as the industry of Internet connection operators. They don't seem to say whether non-exits (thus the EG's among them) would remain accessible or not. The Tor system was utilized by citizens in pro-democracy movements in the Middle East to escape government suppression, while Wikileaks also recommends Tor to information providers. The planned access restrictions are therefore expected to spark a backlash from the industry. 'Communication privacy is our lifeline. We won't be able to accept such a request,' said an industry insider. An NPA official said, 'We will make detailed explanations and seek their understanding.' http://mainichi.jp/select/news/20130124ke040166000c.html police were summarized for the strengthening of cyber crime investigation the 'emergency program' ... According to the National Police Agency, the police has been promoting public-private partnerships with such Internet-related companies so far, but pointed out that investigation and not keep up with the rapid advances in information and communication technology ... In the future, expanding the range to exchange personal level regardless of the occupation of the other party, and that improve the information collection... Emergency program, mentioned considerations and be entrusted to the private sector, the analysis of the modus operandi of education and other investigators It's a little unclear to what degree these groups are for enforcement or education, whether they attend public conferences, etc. Likely the usual mix. There could be some good opportunities there. Cracking, corp/finance, data theft, copyright that sort of deal is one thing. But these idiots making death/bomb threats and such are really getting old not just on its face but due to their tendency to make the news and piss people off, and against Tor, in a different sort of way. I presume exit operators in Japan could ask NPA/Mainichi for the full panel doc and would be very interested in following this issue ... cc'd. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] hardware
A10-6800K (4 x 4.1GHz) would be decent. It doesn't seem to support ECC It doesn't. And for those that recognize its importance, that's been an kind of weakness of AMD for some time. Actually for both AMD and Intel, it's treated as a price premium instead of just 8+n extra gates and logic. It's very silly to not specify ECC RAM for a server. It should be in all systems IMO too, even with crypto over circuits and ZFS on disk. But I not sure the CPU registers, or the rest of the gates on the die, have any such hardware protection beyond the lid on top and the fiberglass on the bottom... haven't looked into it. Or that the makeup of the Internet/services as a whole use ECC. Tor seems more weighted to pushing reproducible bits, than to first production and storage of your own valuable work product. like serial console BIOS support and It's nice if your model involves needing to go to BIOS, such as being tied to hardware raid there. 1U form factor The port stacks can be cut down / removed if need be. Another problem is finding low profile ram to go in non-angled slots. The 'enthusiast' influx to the ram market is annoying yet the unneeded 'heatsinks' (aka bling) can also be removed. the r8139 (iirc) chip/driver lacking interrupt coalescing features. Upgrading to an Intel e1000e fixed the problem. Yes, Intel has always had very good nics and supplies docs/code. I think a85x boards commonly have rt8111. The kind of ISPs that offer competitive pricing on bandwidth tend to prefer commercially integrated servers, preferably sourced from vendors they're familiar with. That means Intel, Dell, HP and the like. I'd hesitate to tie bandwidth price to what some techs want. It's more about how much the ISP buys, if you're small retail remote hands using or a large self-serve cage, and if it's in a neutral DC. That way when your server crashes and needs a reboot at 2AM, the tech in the data center doesn't This is a bit crossed. A true server board should have a hw watchdog that will autoreboot the OS. Similarly, with a good server, pulling the plug should be all a tech needs to do to clear all stuck cases short of hardware failure. You need a good OS/FS for that. Be careful, Intel likes to promote HT instead of full cores. That's a really funny claim Some of their retail marketing I've seen is not so clear, as in 'Here are 8 virtual things, footnote asterisk fine print - really backed by 4 real things'. Their server side online is better. a single thread can use nearly all of the resources on a core. HT is useful Sure, if your workload is not weighted to single threads/processes that you can itemize/count as being under the number of real cores. AMD Bulldozer, OTOH, claims to have [unit pairing/starvation] I do often forget that overall when considering some loads :( actual work done per watt on CPU intensive workloads. Intel often beats AMD on power, even if only due to die process size. Datacenters tend not to line item 1RU's for actual power used unless you're at 1/4 rack or more and they have metered managed outlets, the costs of which are passed on to you as well. As is wasted power. In the end, for small customers, the DC averages a single price to you into which you fit whatever box you want. A home or corporate DC is different because you can mind your power there to direct/immediate savings. AMD unfortunately doesn't seem to have a competitive server CPU these days. It's possible that Piledriver improves the situation, but the analysis I saw did not make me optimistic that it would be competitive with Ivy Bridge. I didn't mean to imply that such a system was true physical server class, but that it could serve the logical function of a decent server/host for the Tor application. Particularly considering the cost per node per megabit as opposed to maximum yield regardless of cost. Real server hardware tends to start well above $1kUSD. Factoring in the performance differences and passing on some features, distributing a lower cost box may be a win there. As a counter to that idea, It might also be useful to consider initial cost vs. megabits delivered over time... if you do not expect to be kicked from DC to DC thus eating multiple shipping costs as add-on capital. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Sitevalley is no longer Tor-friendly
I don't see anything specific regarding Tor or its capabilities in their AUP. But there are bits that could be extended to cover Tor. Which it appears they did, whether for bandwidth or cost of dealing with 'complaints'. They are in New Hampshire, perhaps you could let the FreeStateProject know (cc: SV) that they are perhaps not a company that FreeStater's should patronize. Also, asking a hosters via their support/sales staff if they permit Tor is not helpful. These droids do not have the authority to do anything other than take the sale and kick you later. You need to talk with someone higher up beforehand if you wish to secure better long term footing from any provider. Their AUP is ridiculous. Which is even more curious given they seem to be run by Russians and permit feedback reviews by hosted 'gaming' and 'teen-sex' sites on their front page. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Fwd: Computer requirements for a modest (15-20Mbs) relay?
On Tue, Jul 30, 2013 at 6:50 AM, Andy Isaacson a...@hexapodia.org wrote: On Mon, Jul 29, 2013 at 01:23:13PM -0400, Zack Weinberg wrote: On Mon, Jul 29, 2013 at 12:35 PM, Andy Isaacson a...@hexapodia.org wrote: Yes, there are cases of law enforcement seizing all computer gear from a house with a exit node -- not just the exit node computer. Most recently in Austria in a child porn investigation. We did some operational planning for this risk, in conjunction with the university legal and IT departments, when we set up the CMU Tor exit. Similarly for Noisebridge / Noisetor, we decided to host at a commercial facility separate from our production servers both for cost-per-bandwidth and separation-of-risk reasons. Physical standoff distance and preparation is certainly best. Similarly, has anyone ever put a Tor/EFF exit relay notice and contact info on their door? Let their neighbors and/or flatmates know? Consulted with agencies likely to service warrants? Not to stop such legal process, but to lessen through education some of the risks involved. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] VPN termination on relays
Mosh is great, but it still relies exclusively on UDP, right? So no over Tor... Somewhat related to things that don't work via exits... So who wants to offer VPN termination as part of their exit service? User tunnels VPN to you, you give back a bound port, or a natted 10 address, somethings of that sort. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Is it safe to run an exit node from a VPS provider?
I would like to propose that you take a look from a different perspective (and I thought from the mail subject the question will be about that) on this. To run an exit node from a VPS provider is not safer -- TO YOU -- than running an exit node from your personal home connection. This man[1] had his house raided and his computers confiscated because of a Tor Exit node that he was running **NOT EVEN AT HOME** but in a datacenter, in a different country, on a server that he was renting (of course in his name). From what I gather from discussions surrounding that incident, the only reasonably safe way (again - to you) to run an Exit Node, is to do so on an IP range that's SWIPed to an LLC or a similar company, and not just has one physical person (you) responsible for it. Some providers accept Bitcoin, cash, MO's and the like. Alternatively, companies in general (even small LLC's) often have lawyers, who have formal business offices, and will often let/encourage all business registration, whois, banking, etc... the use of that physical address while they are on retainer under concerns as to legitimate privacy, mobile convenience, and proper familiar and legal response to process of service. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Key files encryption methods.
There may be no better than pure ram, so this ticket may be of interest: https://trac.torproject.org/projects/tor/ticket/9478 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] new relays
This is why we need to implement extended exit flags for exits that want to run post-exit filtering/enhancement policies, say for example noporn that way we can get all the religious groups dumping their tithes into not just beaming reruns of the 700 club around the world, but a pile of uber fast exits too. What a disastrous notion; the exit policy system works because clients can predict in advance whether an exit will pass a given connection; it depends only on the destination host/port. It works because clients can reject some exits they figure they shouldn't waste their time on trying and can proceed trying matching ones. And because the matching ones have historically not been much problem. Predicting the future behavior of exits based on their past, or their current statements, is an odds game some wouldn't put much faith in. That could never be the case for any of these. As with dest ip:port, clients could similarly manage exits based on their postfilter flags. It could work for various purposes but it was more meant ... And how about novirus delivered by microsoft doublesyourcoins propped up by the donations of fools trusted run by legit governments Oh, please, do tell where you expect to find a 'legit' government and why one should 'trust' it? ... forthelols ... which would replace all web pages with (re-read as humor) proposals like this when tor-*@ is busy being too serious, flips the occaisional bird to each other in threads, etc ;) Hopefully all the plaintext protocols will die soon and some replacement for the CA cert model is agreed upon so that there isn't much left to bet on exitwise but the dest ip:port working. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Tor node was doing more traffic than its bandwidth is configured for
On 9/8/13, Roger Dingledine a...@mit.edu wrote: Are you sure you didn't confuse bits and bytes? Tor counts in bytes. (The arm monitor, if that's what you're using, counts in bits by default.) As with real networks and operators, if this is so, then big thank you to arm people for correctly counting network bandwidth in bps. No thanks on webhosters and isp's who convert their upstrream bandwidth contracts into transfer bytes and pass that on to their customers for their apache logs, thereby spoofing hosted network *bandwidth* apps like Tor into feeling some silly need to count bytes. Do wish Tor would speak properly in bits by default. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Traceroute measurement from Tor relays
On Wed, Oct 23, 2013 at 1:26 PM, Aaron Hopkins li...@die.net wrote: On Wed, 23 Oct 2013, Karsten Loesing wrote: Basically the experiment does traceroutes to three groups: all routable IP prefixes, all Tor relays, and then all /24 subnets. Based on my read of your input data, these will run traceroutes to 491762, 9058, and 13597431 IPs respectively, sending at least 100 million packets? This is a bigger ask than I think you made clear. I question the utility of scanning all /24s. By definition, all /24s in a BGP prefix take the same path to its origin AS; the only variation will be within that. If you are looking for chokepoints, you've already found it with the origin AS. Initially I didn't see the sense in this either, perhaps it's in the referenced docs. If the internal paths of a large aggregated AS were of interest it could be used for that. Though you might use the BGP table to reduce the /24 query set to just those matching the AS you reside in. Then again, there can be higher precedence side peerings that would not be found with that. Also, I'd merge in current BGP AS and GeoIP data for each hop of the trace. That could probably be done upon receipt of a submission if they happen daily. However on the client may be better since in order to test new routes over time they'll need to update BGP tables anyway. And for the Tor node... capture the IP, IP whois, DNS ptr, DNS ptr whois, BGP AS and prefix, and GeoIP. I can see this being useful for siting nodes in the future. They are uncommon from a Tor exit node, which already receives enough It's opt-in so I see no issue here. Which by default will try to keep 128 traceroute processes running all the time. This is potentially problematic for relays with limited RAM or CPU available. I'd recommend making this more clear. ...and more tuneable via config file. If looking for more network input and similar work, make a post to NANOG etc. There have been lots of traceroute projects. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Advice on dealing with ISP's response to DMCA takedown notice.
On Thu, Oct 24, 2013 at 11:45 PM, Roger Dingledine a...@mit.edu wrote: You might like the 'reduced exit policy': https://trac.torproject.org/projects/tor/wiki/doc/TorExitGuidelines But it sounds like it won't entirely solve your problem at this point, and it's time for either diplomacy and education, or some other ideas. I'll let others chime in with suggestions. As others have said: - Work together with your hoster to adjust the policy - Offer to handle their ticket issues for them by asking for the full email of the complaint with addresses you can reply to (as a service operator in the US that's pretty much your responsibility to field those directly, then that of your upstream if you don't). Then contact the complainer, send them the Tor docs, tell them your server has no data on it and get them to remove you from their lists and close their case. Keep your hoster informed and especially copy them on any case closed or delisting success. - Some relay operators opt to SWIP the address space to them and effectively become the ISP of record. - If those don't work, close your account yourself and tell them that based on your poor experience with them that you will let others know not to buy from them when the topic of hosting comes up. - Add an entry to the goodbadproviders wiki page and point them to it. Details for all of this are in the archives of this list. Thanks for relaying traffic :) ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] TCP: drop open request
On Fri, Oct 25, 2013 at 12:10 AM, Roger Dingledine a...@mit.edu wrote: On Fri, Oct 25, 2013 at 12:43:42PM +0900, mett wrote: Since yesterday, the kern.log of the relay I'm running is flooded with TCP: drop open request from. I first thought it was a kind of DDOS on our servers but it seems to be related to Tor (When I stop Tor, kernel doesn't complain anymore). if you're in BSD-land. It's a Linux message. Feed it to a search engine and you'll find several things to try depending on what the cause is. It shuts off either because Tor is attracting the syn's or the overall count is lower with Tor off, you'll have to tcpdump to see. Look into syn cookies, packet filter rules, and stack tuning. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Proper bandwidth units [was: Exit nodes on Gandi]
On Fri, Nov 15, 2013 at 3:47 PM, Eric van der Vlist v...@dyomedea.com wrote: Without bandwidth limitation that's true. OTH, I currently consume only ~ 50 Gbits/month and the limit is 500 Gbits. Would a relay limited to let's say 200 or 300 Gbits/month still be useful for the community? People, can we please mind using the proper units. I know Tor doesn't make it easy because Tor itself incorrectly uses Bytes. But Tor is a network application, and real network apps are measured in 'bits per second', not 'bytes transferred off disk', even if the latter is what silly hosters sell by... mostly due to their presumed need to tie in with their typical customers supposed Apache access_logs. But believe me, what hosters really care about is their upstream bill in bps rate, they're just converting that for access_log presentation to you. Your further mixing of 'giga bits per month' doesn't help *at all*. Please try to use 'bits per second' as the common denominator on this (network application) list. BTW, Gandi is historically a fairly progressive company. The right approach could have some good wins there. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Proper bandwidth units [was: Exit nodes on Gandi]
Why not just accept KB/sec, KiB/sec, GB/mo, GiB/mo in the config file? Because KB/sec would be rejected as not conforming to either SI or IEC prefix specs. Therefore the above proposed 'AND' would fail ;) ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Proper bandwidth units [was: Exit nodes on Gandi]
On Mon, Nov 25, 2013 at 1:29 PM, Gordon Morehouse gor...@morehouse.me wrote: Why not just accept KB/sec, KiB/sec, GB/mo, GiB/mo in the [1] https://bugs.torproject.org/9214 We now support gbits (127) and gbytes (130) in the torrc file, but we do not support gib. Or I think more correctly, we say gbytes for what you want us to call gibs, and if you want to say a billion bytes, you need to type all the zeros. I learned about the 'gib, kib' etc in wikipedia a while back - it'd be best if the config file were extremely liberal in accepting what people type, IMO. No. This kind of lazy acceptance is exactly why rockets crash, and rockets crashing are why one must use proper terms. 'gib, kib' are not cased correctly, thus people have no idea what you explicitly mean. They might presume your lazy casing means 'Gib, KiB' but then your rocket might crash. Reference and enforcement is the proper cure. https://en.wikipedia.org/wiki/Binary_prefix The little table in the upper right covers the decimal and binary prefixes and their long names. It should be documented as such and nothing else should be accepted. As far as units of bit and byte... https://en.wikipedia.org/wiki/IEEE_1541-2002 https://en.wikipedia.org/wiki/IEC_8-13 With the more international community seemingly lately moving the abbreviation for a bit from 'b' to 'bit'. And defining octet 'o' as the grouping of eight bits (perhaps still leaving the byte somewhat undecided as to its width in bits, and conflicting in abbreviation 'B' with the older and more cross-disciplined Bel.). https://en.wikipedia.org/wiki/Bit https://en.wikipedia.org/wiki/Byte https://en.wikipedia.org/wiki/International_System_of_Units ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] using Curve p25519 cryptography for type 2(Mixmaster) and type 3(mixminion) remailer blocks
On Tue, Jan 14, 2014 at 2:14 PM, gwen hastings g...@cypherpunks.to wrote: ... I am looking at resurrecting mixmaster, mixminion and nym.alias.net nymserver designs from the various code wastebaskets and retrofit them with some newer encryption technology based on curve25519 and poly-1305 libsodium based algorithms and routines. I believe there is sufficient demand to merit deployment of a good mix network. As well as perhaps web/other intake frontends due to the now prevalent a) dwindling free email b) demand by mail providers for phone authentication. As for operators, I'd reach out to the Tor, I2P, Bitcoin, etc operators. It's a shame that one of the hardest things to find these days is anonymous free speech in the simple form of the written word. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Considering setting up an exit, need advice
Schools are like work... either it's a free for all or requires permission and signoff. Especially for anything that can take heat, like an exit. To avoid issues, check with your administration... both the network people and the people you report to policy/class wise. Neither are hard to find or talk with. Thanks for running a relay. Also... https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays-universities ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [WARN] Your system clock just jumped 100 seconds forward; assuming established circuits no longer work.
Since you say it repeats you oppurtunity to check the system clock first: - configure tor to syslog - send an ntpdate -q pool to syslog every 5min, remove when solved. - send *.* to /var/log/all and see what you find around where the date lines start to slide or jump past each other. Graph it with rrd/gnuplot if you want. epoch format helps there. Your timekeeping is probably just broke somewhere, ie: your system has bad clock drift and also can't sync because there's a firewall blocking ntp, so off goes your time. Check that first. It's not your isp since you say you're using ntpd against external debian pool and odds are not someone stuffing you bogus timedata. Though your ntp cli query may not be the same as the ntp daemon query re: udp/tcp port they use, stateful firewall timeout, etc... ie: somehow ntp blocked. Or stale/unwriteable startup drift files on disk. If ntpdate is set, then under ntpd running for 15min+, if ntpq -np does not show one asterisk(*) in front of one of the nonlocal peers, you're not synced. And you'll be no luck until you are, fix that first. Not likely to be Tor or kernel, but you can then next - move the drive to another known good mobo/cpu box. - do the kernel event logging thing - bump tor's loglevel ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Exiting only port 8333
On Tue, Mar 18, 2014 at 4:20 PM, Mike Hearn m...@plan99.net wrote: +Roger, as I'm curious as to the rationale. There was a pretty big thread debate a couple years back about people only wanting to offer cleartext ports being seen as (whether falsely or not) doing it purely so they can cheaply steal content/tokens off the wire. I don't know if the current spec has any commit relation to that. Yes, and allowing people to exit only Bitcoin traffic seems beneficial in other ways: you're not likely to get abuse reports from just allowing port 8333, so the cost of being an exit for that is much lower. And it'd indeed take bandwidth pressure off other nodes. Good point regarding lowering potential headache cost for those not wanting that much of it. There's probably value in offering say all ports but 80/443/25/torrent and whatever else is left out of 'reduced'. The atlas graphs do show traffic for such nodes providing essentially just 8333. They're usable manually, just not automagically by the client I think. I forget how their traffic is picked up. The globe page for my node shows exit probability: 0 so I guess I'm indeed not being sent any. There are 850+ nodes allowing 8333. Have you considered running an onion:8333 seed node to both serve btcnet and keep traffic off the exits? Yes but it doesn't get any traffic for reasons I haven't bothered to figure Being an onion there'd be no tor mechanics preventing traffic. It may just be the proportion of IP vs. onion nodes the btc client sees is small so as not to make contact. You can 'setevents stream' and see btc contacting onions. And can -onlynet, -connect, etc the btc client to test. out yet. Anyway we can't run all of Bitcoin over Tor because it'd kill off our (admittedly quite weak) anti-sybil defences. In that you presumably have to pay for commercial node farms where tor nodes are free (and more bandwidth limited). On the other hand, abundant crime money will probably be paying for those farms anyway. So this could be mooot. My motivation comment was if you were doing publishable research or simply production for fun. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relays vulnerable to OpenSSL bug: Please upgrade
On Tue, Apr 8, 2014 at 4:34 PM, Roger Dingledine a...@mit.edu wrote: On Tue, Apr 08, 2014 at 04:35:39PM +0100, mick wrote: Moritz Bartl mor...@torservers.net allegedly wrote: Yes. You made it generate new keys, so it is a new relay as far as Tor is concerned. This is why not everybody should generate new keys immediately, especially larger relays. But don't worry too much, you'll get your flags back eventually. :) But Roger's blog post makes no mention of the advisability (or otherwise) of a mass re-generation of keys. All it says is that best practice states this would be a good idea. The first iteration of my blog post said something like if you run many fast and stable relays, consider spreading out your relay identity key replacement over the next week so we don't unbalance the network. But I removed that sentence a little while later, when it became clear that nobody knows for sure but quite possibly an attacker could have extracted key material from vulnerable relays. If that actually happened, I think we probably want new identity keys asap, *especially* from the big relays, and we'll be happier tolerating a couple of bumpy days while the network recovers. My reading, even without the PoC's and mmap docs that have since come out, is that it's always been: 1) simply connect to any vulnerable openssl 1.0.1 [START]TLS service port 2) get a nice 64k chunk of core returned to you (regardless of whether you posess any type of higher level token, onion key, user cert, etc.) I'm not so sure it's the 'big relays' that are priority (at least as far as the net as a whole is concerned). More likely just the largest number of nodes in the shortest time. And of course key meta points like the authorities and dirservs. I've been ad-hoc watching the resultant drop in cumulative node uptime since yesterday afternoon... we're down maybe 18% from an original ~14.1 gigasecs. And ~3000 descriptors have uptime newer than the release of openssl 1.0.1g tarball. Lots of caveats in these metrics for sure. Ps: I liked the idea of the two key transition proposals on tor-dev. Maybe at this point, if many auths are to swap keys, point releases may be easier than coding that for now. There's also probably merit in a new rcfile called toretcdir/authority_keys containing the data in src/or/config.c . Would make for quicker near-term updates by distributing a small rcfile than recompiling until the proposals develop. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relays vulnerable to OpenSSL bug: Please upgrade
On Tue, Apr 8, 2014 at 4:04 PM, Roger Dingledine a...@mit.edu wrote: Actually, I'd like us to take this opportunity to throw out the Named and Unnamed flags entirely. I think we've done pretty well at teaching users to use $fingerprints rather than nicknames in the few cases where they actually want to specify a particular relay. And only two-ish directory authorities still track and vote about Named Second the idea of completely tossing names internally in favor of fingerprints. It would be great to have somebody think through the implications of what exactly we'll lose by dropping them, so we can make a more informed decision. Maybe that could be one of you? :) I've felt the real benefit of nicknames has always and only been in operator participation (woot, other than dns and http on my OR IP, I can feel good by having this short name string), and moniker recognition (hey, look at this metrics widget, I can search/spot all kinds of human readable cool nodes... maybe I'll run one or keep running mine, etc). Nicknames, 'contact' and the like could be merged into new a formally structured user metadata descriptor field. Some fields of which might be used by applications such as onionoo to populate other empty fields. ie: 'udata nickname[16char]: email[32char]: uri[32char]: blurb[up to remaining n char limit]' ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Long-term effect of Heartbleed on Tor
TvdW * Should we consider every key that was created before Tuesday You'd need to also know the key was created by vulnerable openssl 1.0.1 versions, didn't already disable heartbeat, etc. That data isn't announced in the consensus. And those that weren't vulnerable may be happy continuing with their uptime/key. On Wed, Apr 9, 2014 at 2:51 PM, Paul Pearce pea...@cs.berkeley.edu wrote: I'd be interested in hearing people's thoughts on how to do such scanning ethically (and perhaps legally). That's an interesting dual-ish question, given we don't own them, often have no real contact means, and yet they're part of us in some voluntary fashion. I don't have any good suggestion on that other than collecting private data, as opposed to statistical surveys, is a problem area. If we knew which were subject to the bug, the long term goal should be to blacklist their fingerprints. Most uncontactable operaters will get the clue after a few rounds of that and/or visiting tpo for new releases due to consensus version deprecation. If you browse onions you may find some anonymous researchers who conduct their activities via exits, publish their results on onions, and announce them in various fora. I've not yet seen anyone cataloging this bug as it relates to Tor in that manner. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Strange Problem Browsing Blocked Websites
On Wed, Apr 9, 2014 at 3:21 PM, Ferdi GULER ferdigu...@outlook.com wrote: In order to anonymize my browsing traffic on my main windows PC, I configured Firefox to use my raspberry pi as proxy on port 9050. When I visit the page https://check.torproject.org/, it says my configuration is successful and I see different ip address. From that point I assume everything should work properly but if I try to browse web sites that are blocked in my country such as youtube it just does not connect. However if I use VPN I can see those blocked web sites. It is likely because the exit your client chose was blocked by either youtube or by someplace in its path to youtube. You may try 'signal NEWNYM' / 'new identity' controller function, or 'ExitNodes' configuration option as in the docs / search engine. Thanks for running a relay. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Atlas Entry
On Wed, Apr 9, 2014 at 10:33 AM, Tor Relay t...@microcephalic-endeavors.com wrote: My several attempts to update to TBB 3.5.4 (XP)unsuccessfully made Tor exit upon starting, so I fell back to 3.5.3. Atlas shows that my efforts hadn't gone unnoticed; OnionTorte now appears four times w/ my IP address. 0D50D43BAA728D6E0C4EB181AB79E5C1D7036D08 is the correct one but it somehow has my bandwidth as 489 KB when it should be 921.6 KB, reflecting my RelayBandwidthRate. Does anybody have a way of clearing the ghost entries and setting Atlas straight on my bandwidth? Tor doesn't have any revocation yet, and Tor automatically keeps its network overhead down and stability up by not adjusting things in sync with every minute some relay goes nuts. Just let it run and it will fix itself. While you're waiting you can search blog.torproject.org for 'relay lifecyle'. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Rejecting 380 vulnerable guard/exit keys
Updating a previous post full of measurement caveats (in particular not keying IP/FP to discard old descriptors)... now at: - 35% reduction in cumulative relay uptime from 14.1Gsec pre-hb. - 4400 out of 5835 descriptors with uptime less than hb-release and totaling 1.2Gsec among them. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Grouping cloud relays running within same provider
On Fri, Apr 18, 2014 at 4:21 PM, Paul Syverson paul.syver...@nrl.navy.mil wrote: Of those 15,000 paths, 163 (or ≈ 1.1%) contained an entry and exit node that resided in the same AS despite having an IP address from different /16 subnets. Out of those 163 paths, all but one also had a distinct /8 network address. There are two questions new operators ask: - What provider allows Tor [exit] nodes so that I can place my new node there? (This is a very common question and leads directly to duplication.) - Where are there no relays right now so that I can try putting one there? (This question is so rarely asked that I cannot recall seeing it.) Even though 1.1% is small it (AS/cidr) does not cover some relevant crossfields such as legal jurisdiction, I still think a project to research current relays would be useful (cidr block, AS, [upstream] hosting provider, physical/govt location, relay operator and location, funding source, etc). Then new operators could query an xor report of fields with - input their prospective new relay - get a top ten list of where we are already too heavy, do not host there - use our data to suggest new placements, ie: we have no relays in these countries, in these AS by size, etc... It would make some sense to have onionooo plugin to carry this extended db, particular since hoster and some other fields would require human researched/maintained input. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Exit node rejection of special IPv4 blocks
On Wed, Apr 23, 2014 at 6:26 PM, Roger Dingledine a...@mit.edu wrote: On Wed, Apr 23, 2014 at 03:12:36PM -0400, Zack Weinberg wrote: I'd like a sanity check on this list of special-purpose IPv4 blocks which I'm currently forbidding in the CMU exit node's policy. I'm Best practice is to only block addresses and destinations that you know you don't want to reach. When you block addresses where somebody tells you there should be nothing there, you're narrowing out the future. If the RFC changes tomorrow and you don't notice, suddenly you're blocking connections to a piece of Africa or whoever gets that IP space. Yes, a lot of BGP people did/do that, blocking not just the thou shalt not route stuff, but also just plain unallocated stuff, leading to partial blackouts and weird routing for ages after allocation till everyone updated their silly filters. Search bogons. And if indeed nobody is using it, why block it? Everything is pretty well collated and described here... https://www.iana.org/numbers 6to4 appears global. Multicast won't work over Tor. Yet that huge swath of space would seem ripe for better management/assignment someday. Nanog would have that thread. For shalt not... it probably doesn't matter if you block the whole non-global special purpose lot. A couple reasons should be obvious: - To protect yourself and nearby lan/wan systems from remote access via selective use of you as the exit towards those addresses. Obvious example is rfc1918 to gratuitously reconfigure your modem/router for you. - To stop building and wasting circuits for users who dump/leak packets with those destinations into Tor, such packet dests would not be forwarded/accepted by your ISP's routers anyways. It would not be difficult for some relays to run a report on what is seen trying to exit them. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] SSH scans from Tor exit
On Mon, Apr 28, 2014 at 11:23 PM, Michael Wolf mikew...@riseup.net wrote: On 4/28/2014 10:04 PM, Zack Weinberg wrote: For what it's worth, after complaints from campus IT we also wound up blocking SSH in the CMU Tor exit's policy. Sounds like IT is conflicted and sans balls... permits relay service, but well, doesn't. Good that you can run one, but if they're whacking you for denied stuff, plan on moving soon when they get real complaints. people do sysadmin stuff and whatnot anonymously Not just for anonymous... the value to real sysadmins daily of a TCP enabled IP for testing from anywhere in the world is huge. I think if a server is so threatened by a port scan that it invokes a human response, that server probably shouldn't be online. /rant The servers aren't the one's that shouldn't be online, it's their idiot operators who think SSH's DEFAULT SCREAMING ABOUT DENIED HACK ATTEMPTS in the logs is some kind of important, and then go reporting it to every place they can think of, each of those places staffed by more clueless idiots, etc. Grow up people, quit whining about ssh and learn to admin. Meanwhile, Theo laughs heartily at everyone. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] SSH scans from Tor exit
On Tue, Apr 29, 2014 at 5:26 PM, Nicolas Christin nicol...@andrew.cmu.edu wrote: The level of intelligence of the people that receive these complaints is irrelevant. It is, in fact, entirely relevant. Clueless recipients (and their upstream) leads directly to improper kneejerk responses, such as pull the project. Whereas if people had a clue they'd realize this particular issue is nothing but background noise and file it in the bin. However competent you may be, if you get oodles of complaints every single day, for something that you are doing as a favor to somebody else, you will throw in the towel. once again, have been really good to us, what would you pick? I've been party to large environments (RE included) where boilerplate complaints resulted in automated canned responses, or were simply filed in the archive to be expired later. A few hours of existing work-study student time to process a days lot, fully supported by high ups. It comes down to volume, severity, tools, responsibility and clue. If you don't have any of the latter four, sure, any amount of the first will kill you. Being in a good environment for such things also helps too. Unfortunately that is probably not the majority of them. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] SSH scans from Tor exit
On Wed, Apr 30, 2014 at 2:14 PM, Delton Barnes delton.bar...@mail.ru wrote: I'd suggest the problem is administrators treating a Tor exit node the same as a compromised machine. Sure, and it's part of the sometimes improper administrivia kneejerk response. And the SCREAMING involved with this one certainly incites an unbalanced response upon the less experienced/knowledgeable. these attacks, so administrators should have to just accept them. The operator of agnostic midpoint carriage services / relay is different than the ISP of the following two machines, and different than the targeted machine, or the attacking machine. Each has different rules of play available to them, with the midpoint carrier likely having least duty among them to do anything. It's not as if blocking exit:22 to the reporter's machine is going to do anything useful on their end given the rest of the internet they're open to, but if you want to appease them and your upstream, feel free. I wouldn't, but to each their own relay policy :) ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Ops request: Deploy OpenVPN terminators
Ops request: Deploy OpenVPN terminators We are ops because we want to allow people to avoid censorship and speak freely. But are we doing all we can? It is well known that all relays, exit or non-exit are added to a variety of blocklists. Primarily through scraping the consensus. And those blocklists are then used to indiscriminately deny legitimate users/people access to sites, regardless of their 'behaviour', which more often than not has simply not been determined yet. So we need to augment what we're doing in order to be effective in our mission. Here's how... We already run Tor on an IP, that IP is blackballed as noted above, so using another port on it as a vpn terminator is pointless. Yet our hosting packages often offer other IP's in the same range, or we already have them to use as part of the deal (or, failing that, we can forward the openvpn TCP port on our bad relay IP to another clean non-bulk-blocked IP we control). We obviously cannot publish this new openvpn 'exit/termination' IP anywhere, such as in the comment field of the consensus as it will be banned. *But we can bind to it and let users find it with their own openvpn scans close to (one up or down from) our OR IP.* Just use the standard openvpn TCP port on it. There is no bandwidth cost to us to do this because all the traffic is moved between the exit IP and the openvpn termination IP over localhost. (Well, unless you are forwarding openvpn port on OR IP to another termination real IP off your box.) At minimum we should allow TCP transport out from the vpn to the world, aka the usual nat, so as to make websurfing work for our users. Bonus for allowing nattable outbound UDP, ICMP, etc. Further bonus for allowing inbound binds on whatever port on the IP that is available to be bound to. Obviously sine the IP is scarce to us, we can't allow full unnatted use of the IP. The point is, we already own these extra IP's, and legitimate people are being blocked from services for no reason other than kneejerk or blind reactions to Tor via blocking services. Ahem, cloudflare, et al and other blocking 'services' well known to us. So to the extent we have other IP's available to us, we should set them up to be unpublished openvpn nodes and let users find us by trying to terminate their vpn connections on us at that IP and openvpn port. Yes, blocklists could try the 'one IP up/down' scan method and list this project of ours too, but it's more work for them and they're unlikely to do it in any sort of global fashion. Especially since they can't prove it's part of Tor (because we don't publish the IP's as such). If we wish to make an announcement that we are running such terminators, obviously it should not be made from addresses related to our OR IP's. [FWIW, there is another openvpn terminator project out there. Unlike ours would be, its nodes are public, and even with that detriment (though possibly only because it is lesser known) it obtains more freedom from blocklisting than Tor. However its termination points perform poorly/unreliably whereas ours would be both nonpublished and better managed.] ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Ops request: Deploy OpenVPN terminators
On Tue, May 13, 2014 at 5:48 PM, Jeroen Massar jer...@massar.ch wrote: Thank you for suggesting the GFW folks now scan and/or directly block these IP addresses too. The gfw is going to do what the gfw does. And many times that is dedicated to blocking access to tor, not access from tor, obviously, as once you have access, the exit is out of reach of gfw. If you don't want to be blocked by gfw, don't run this openvpn extension service on your node/ip. You are mixing the difference between an operator of a site selecting who their viewers are and a man-in-the-middle selecting that for both the user and the server. Don't mix those up. No I'm not. I'm combining them. Whether site op blocks an IP in its Apache/ipfw or subscribes to a service to do the same is immaterial to this countermeasure of ours. We see them blocking legit users who complain about it, so we act to allow them alternative access. They can then move to account based and other finer grained user management models. It is no different than us deploying tor network to give users ability to avoid blocks in first place. It is simply evolution of making such tools available to users. You don't have to run described openvpn extension if you don't want. I am pretty-much-completely pro-Tor as there are good uses, but for controlling who logs in and who abuses you, Tor is a bad thing as you don't know what the source is. As an operator of a (server) site, being able to say sorry, we do not accept connections from Tor is a good thing, as there are situations where that is needed. You just stated [users] who 'log in' to sites, therefore you already have the tools you need... block the abusive account. Tor has nothing to do with it. Yes, blocklists could try the 'one IP up/down' scan method and list this project of ours too As it can be done automatically, it is not more work for them. I beg to you that it will be substantial work such certain subsets of them will not engage in it. Furthermore, they are bound to certain legalities which may prevent them from doing such scanning/testing. Either way, it is an advance of the art on our part. You do not need to participate if you do not wish. And actually, they are likely already scanning every IP in the /24 where No, what would they [gfw] scan for if they already have the consensus. And we are not talking bridges here, they can already poll for those. This scanning /24 topic is all moot, might as well scan for open 8080, etc. Again we are not talking about gfw or access to tor. Instead of doing OpenVPN (which Wireshark knows and thus is easily detected by port number but also protocol itself), look at the variety of Pluggable Transports[1] people have been developing and deploy these. Umm, blocklists and/or site ops don't have access to your localhost to sniff it. PT is irrelevant on localhost as well. You do not understand the model to deploy here... user - ovpn - torcli -- exit torrelay or_ip - localhost - ovpn_ip -- world Of course, using BridgeDB is a good thing there to publish these details, or you could invent some new method of passing details to people (puzzle game solving ala captchas being a good start though defeatable by having slaving-away people getting paid for solving them). In OP I suggest with reason not publishing them at all, the whole point is to *not* let the openvpn ip's be easily scraped like OR_IP are, as a countermeasure, so let users scan for these new termination points. But absolutely yes, if you feel some reason to have to DB them do not ever publish them in something dumb and easy scrapeable like consensus or website list. Other relay ops will not even inform such DB that they are running them, exactly so they can't be scraped and must be scanned for. You do not have to run this, other relay ops will see value and will. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Ops request: Deploy OpenVPN terminators
On Tue, May 13, 2014 at 8:40 PM, Andy Isaacson a...@hexapodia.org wrote: Anecdotally, the GFW blocks OpenVPN endpoints as well. You need to specify context... access *to* ovpn nodes?, which is moot because that is not the deployment specified here in diagram... you already guaranteed access via the localhost exit you can already reach, (or via the exit op's clear forward path to their off exit box ovpn node). Or *from* ovpn nodes?... well as before, if your node is in gfw area trying to get out, or is outside trying to get in, it really doesn't matter, gfw will block exit or ovpn as it will. So, this is not about such gfw things. It's about enabling quite some other users other means to get around silly ip based blocklists derived from the consensus, the tor dns query thing, or poor management models by the site the user wishes to access, etc. We provide tor exits exact so users can get around stuff, so adding in an ovpn on a spare ip is no philosophical difference there. Yes, it is a fuck you to old way of playing nice by saying here's all our public nodes, block us, and it might cost $few more a month for the ip, and eat some cpu on localhost, but that's about it. If it helps some users it's worth doing, to each operators own desire. Same goes for binding/routing your tor exit out a different ip than your OR ip. Except that using OpenVPN can permit other protocols for help of user than only TCP. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Ops request: Deploy OpenVPN terminators
On Tue, May 13, 2014 at 8:27 PM, Tom Ritter t...@ritter.vg wrote: This seems very similar to the idea of having private exit nodes: https://www.torproject.org/docs/faq#HideExits Tor daemon must of course know its exit OR ip's+ports via some mechanism (currently, distributed consensus), or Tor would not work. There is no such thing as private exits in that context. Every anon protocol learns its own peers somehow. Running OpenVPN terminators on your exit box on a different ip than your tor exit is unrelated to Tor itself. It is an extra/enhanced service relay operators would choose to provide on their own. It's also easy to enumerate Exit IPs not by scanning up/down, by just building a circuit through every exit node to a server you control, and looking at the originating IP. Given that very few exit relays exit via an IP not in the consensus, enemies of tor do not have to scan or build, they can just look at the consensus. This is not relevant to the context of this proposal. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Fwd: [tor-talk] Fwd: Ops request: Deploy OpenVPN terminators
to list, not me. -- Forwarded message -- From: Mirimir miri...@riseup.net Date: Wed, May 14, 2014 at 11:58 PM Subject: Re: [tor-talk] Fwd: [tor-relays] Ops request: Deploy OpenVPN terminators On 05/14/2014 09:07 PM, grarpamp wrote: On Tue, May 13, 2014 at 5:48 PM, Jeroen Massar jer...@massar.ch wrote: SNIP user - ovpn - torcli -- exit torrelay or_ip - localhost - ovpn_ip -- world That ovpn part on the left is easily detected by any party in the middle doing No. Understand the diagram. It is not detectable by anyone between torcli and torrelay, because that is just normal tor. Note that you are running IP over TCP over Tor (which is over TCP). Of course. Unless of course, as suggested before, some operators choose the method of binding/routing their exit over an ip different from their OR_IP, then it would just be native tor and native TCP. The performance of that will be very bad. Tor network is already overloaded enough as it is. No it won't, I've tested it, it works just fine. The only issue is the exit ip may change. So the exit operator is expected to block access to ovpn_ip from anything other than their associated or_ip, and the user is expected to config their client to use only the associated exit per whatever 'world' usage session they have in mind. It's not supposed to be point-click easy, only possible. That's a very cool idea :) Using $5/mo VPS, there could be a large pool of exit IPs for each Tor exit. SNIP -- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Usefulness of very limited exit policy nodes?
Opinions please - is it worthwhile running an exit node on a home DSL Nodes are nice to have around. potential abuse from exit traffic more so than limited bandwidth. I've only That's up to you. If you don't mind the odds of the queens best afp waking you up and borrowing all your stuff for a while till they figure out it probably wasn't you who posted that crap on the web... then you're fine. Letting your ISP know you're running an exit would probably also help you there. had it up for a few days and the bandwidth is being used. That answers that part of your usage question, some people get no traffic thus do other things. running as a relay? Depends on you mostly. You could also be a bridge, obfsproxy, maintain the wiki, fix bugs, etc. would make this node more useful, while not greatly increasing the risk of abuse reports coming my way? Most abuse comes from http/s web cretins and sometimes filesharing. Though the infocalypse horsemen are always a threat. Specific authenticated and encrypted protocols like ssh, imaps, pop3s, submission, xmpp, and so on tend to be quiet. Just read through the archives of this list, other answers are all there. Exit boilerplate and complaint templates, exonerator, and so on. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Running exits from home, posting exit-notice
In some threads people are running exits from home for principle, economy, management, etc. Some threads question risk. Just as you put exit-relay-notice on your IP to obtain advantage of chance of reading it first before interacting with you, you may consider literally posting it on your doors. Also, even paid hosting location could have advantage from this. https://gitweb.torproject.org/tor.git/blob_plain/HEAD:/contrib/operator-tools/tor-exit-notice.html Btw, the link to that at the bottom of here is 404: https://www.torproject.org/docs/tor-doc-relay.html.en ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Unblocking blacklisted exits [was: suspicious]
But it's also listed on http://cbl.abuseat.org/lookup.cgi?ip=5.104.224.5 as If you find exits on blacklists, you could try to contact the operator via their descriptor contact, exit http banner, etc so that they can try to have it removed. Usually a few clicks on an assertion of ownership/cleanliness and an email ack is all that's needed for removal. Since ownership of IP's is always in flux from perspective of BL's such that any 'real' owner could always do it too, absent exit contact info, many users could probably submit removal for them without issues. There's a project covering this on the wiki: https://trac.torproject.org/projects/tor/wiki/org/projects/DontBlockMe ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Fwd: Running relays at consortia networks [was: JANET/edu]
C, there is also a tor-relays-universities list. Forwarding there to keep the initial chat primed. Once you have buy in from legal, chairs, security, upstream, etc this can be a very strong position, often better than pay 'contract' of random ISP host. I have seen such 'outside' nets used for these not strictly mission things, such I suggest it in this thread. Different approach depends on if you can find and house a legitimate paper producing research purpose, or if you simply will run it for supporting freedom point of view. Worth mention is that both internet2 and nanog have mailing lists where queries and propositions could be sent. Cold contacts at regionals are not hard to find. -- Forwarded message -- From: Cristóbal Palmer cmpal...@ibiblio.org Date: Mon, Jun 9, 2014 at 5:56 PM Subject: Re: [tor-relays] Running relays at consortia networks [was: JANET/edu] To: tor-relays@lists.torproject.org On Jun 7, 2014 3:27 PM, grarpamp grarp...@gmail.com wrote: Has anyone tried approaching these networks themselves to see about running relays there? Their bandwidth for sponsored things is often free. In the US you might try internet2.edu and all its various connecting regional networks. I'm at a member institution for Internet2, and the buy-in process put us in a research VLAN outside the university network. I'd be very interested in hearing from people at other member institutions about coordinating management of risk such that our service is more supportable and robust. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Sinkhole IPs to block for Cryptolocker and Gameover Zeus
On Wed, Jun 11, 2014 at 4:17 AM, Adam Brenner a...@aeb.io wrote: I have complied a list of Sinkholes from CBL for both Cryptolocker and Gameover Zeus. Consider adding these IPs to your ExitPolicy reject list. Here are lists of other useless bad' stuff on the clearnet for which exit operator might receive a complaint for contacting: ... ... ... Has anyone evaluated the network [dirdata, client] cost of bloating 1200+ exits worth of 1000+ line exitpolicies, versus [circuit] cost blocking them with external packet filters. And the classic issue of when those IP's are eventually cleared and used for good' stuff, but laziness tends not to delist them, so exit becomes less useful and traffic skews. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Torservers herngaard issues
Seems to be consistently delivering random length web pages (if they are artificially slowed such as https://berlin.craigslist.org/) and its bandwidth is tanking on globe.tpo. 3B486DEC5A22694C0960B4A97A3665C617C89B1C ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Ops request: Deploy OpenVPN terminators
On Thu, May 15, 2014 at 9:36 AM, Jeroen Massar jer...@massar.ch wrote: the proposed setup breaks all anonymity (OpenVPN sends Raw IP packets) thus 1:1 mapping for the few people who will use it. No, it does not break any anonymity. And it doesn't matter what OpvenVPN sends because it all happens over the users already secured Tor circuit '--'. You just don't understand the model. Here it is again. '' is a single computer, there are two computers pictured. Packets travel through the listed processes and computers from left to right. '++' is the usual clearnet beyond the exit box. A) user - ovpncli - torcli -- tor_exit_relay_or_ip - ovpn_term_ip ++ world B) user - torcli -- tor_exit_relay_exit_via_non_or_ip ++ world This other suggested model is: swap ovpn above with choosing exits that bind/route/nat their tor exit traffic out a different IP than their published OR_IP. ie: the exit IP is not scrapable off the consensus because it is not the OR IP. Of these two ways for users to utilize IP's that do not appear in the consensus... A) OpenVPN is more useful for end users by potentially allowing other-than-TCP and/or even possibly inbound connections. All of which are chooseable and configurable by the volunteer operator to suit their needs. B) Non_OR_IP_exits are limited to TCP. And are fully integrated with tor's accept/reject exit policies. [OpenVPN method 'A' would require additional host/ovpn rules to achieve pseudo exit policies, and the user would not know ahead of time what they are (not in the consensus). However, a survey of existing exit policies shows the user would be likely to reach their desired destination simply by trying any other ovpn enhanced exit, particularly in the case of typical HTTP[S] websurfing, because almost all exit operators permit that anyway.] Running Ovpn directly on the relay box is not necessarily required, though not doing so would cost external bandwidth (such as to reach Mirmir's suggested disposable VPS IP's). Traffic off the box to those IP's could be further rate limited in that case to reduce cost if usage of these methods becomes nontrivial. Also, if the operator doesn't have nearby one-IP-up/down IP's available to them, the standard user clue to 'check for OpenVPN port 1194 one IP up/down from the OR_IP' would not work for the users. In that case, the operator must publish/leak the IP+port on the wiki, the list, or elsewhere. few users will ever use this, few random exits will support it, Typical negativity some people say regarding anything new. I hear people are trying to move to PFS suites, use secure messaging on phones and all sorts of new things these days. Feel free to downtalk them too. Only reason why this is being asked: circumvent site policies Absolutely correct. Yet you are not realizing that Tor *itself* is exactly such a circumvention tool, particularly against services and other things that don't try, or fail, to block all of Tor. If you are opposed to circumvention tech for innocents, you want nice happy cooperation with whatever [web] services want, then you should not run this proposal, or even run a Tor relay. Because they are both circum-tech. And circum-tech should be listed, along with usage as liberation tech, here: https://www.torproject.org/about/torusers.html.en But that'll probably never happen because it's too 'hot' or hard to understand. It is also useful for other things besides defeating dumb site policies... - Getting around blocklists that sites blindly install by default without realizing what they are blocking, why, or even being given the chance to consider Tor users and agree with blocking them or not. - Making Tor a better network diagnostic tool for admins at work because OVPN can transport more protocols to test things with. - Similarly, allowing more Tor users to 'torify' more apps than just TCP ones. Tor users and other proxies defying their access policy. Cue and stir the tired debate about whether Tor users are good/bad or whether services really need to implement fine grained, intelligent management of users based on their *account*, not their *apparent ip*. I believe Tor users are good, and that better management models should be encouraged to evolve. If we are the ones to do that, by whatever means, outreach, this tech or otherwise, so be it. please detail how exactly you handle abusive users I delete their account per ToS. Point, click, gone, easy. ask them to reconsider I do this too. Yet it is the other innocent users that can't make headway, up against services that won't give enough thought, that this is really meant for. I support those users. Note that that is there to reduce the amount of abuse, and thus the global and full blocking of Tor. As in other threads, prove that the incidence of abuse via tor is greater than the incidence via clearnet. You mean because people are trying to circumvent the policies of a site? No, as I said before... ... A thousand Tor exits,
Re: [tor-relays] Ops request: Deploy OpenVPN terminators
On Mon, Jun 16, 2014 at 12:59 PM, Bogglesnatch Candycrush bogglesna...@yahoo.com wrote: On Monday, June 16, 2014 2:29 AM, grarpamp grarp...@gmail.com wrote: No, it does not break any anonymity. And it doesn't matter what OpvenVPN sends because it all happens over the users already secured Tor circuit '--'. You just don't understand the model. Here it is again. '' is a single computer, there are two computers pictured. Packets travel through the listed processes and computers from left to right. '++' is the usual clearnet beyond the exit box. A) user - ovpncli - torcli -- tor_exit_relay_or_ip - ovpn_term_ip ++ world It seems to me in this case the OpenVPN endpoint would know who the user is, based on their OpenVPN client certificate or shared secret. Even absent those, they might be able to do packet fingerprinting, since the packets won't be scrubbed. 'know who the user is' ... you need to precisely define that. know their location [real ip]? - No, Tor protects them from that. know it's the same recurring OVPN nym? - Not if OVPN is setup to use ephemeral keying or a single shared secret posted on the wiki. know their name? - Any exit can sniff users at the tor daemon, OVPN or not. know their traffic? - Any exit can sniff users at the tor daemon, OVPN or not. scrubbing? - There is some visibility to the 'raw' tunneled packets from the user's stack. Similar to OnionCat, or to how browsers 'Panopticlick'... we should document that so that users can make their own choices, we provide an openvpn config file, etc. Ultimately, this essentially brings what would otherwise be third party OpenVPN service to pair with Tor via the exit relay operators model everyone is familiar with today. Other than that it is an external bolt-on after Tor, and it is improper to compare it with the expectations/capabilities of Tor as if it were Tor... they are two completely separate things. It is optional for operators to run one. And optional for users to use one. Another aspect... the consensus is scraped and imported into blocklists because Tor makes no restrictions on such use. And they are unlikely to do so because TPO wants to play nice. Now since maybe only a third of these independantly operated OVPN IP's might be published on the wiki (the die roll thing), the other two thirds must be found by scanning and then used to see if the shared access token works. This OVPN service could be ToS'd as being only for Tor users and not blacklists. Thus any appearance of an unpublished OVPN IP on a BL could be challenged as to its listing source... one such successful case of illlegal access to computer against ToS would send a strong message to BL's not to do that. A rather thin defensive tactic, but it is worth noting how the consensus and OVPN differ in this regard. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Operating system diversity?
On Tue, Jun 17, 2014 at 10:38 AM, Jonathan D. Proulx j...@csail.mit.edu wrote: I'm not sure if this was meant as a technical or aesthetic preference, but I am curious. Is there any technical benefit to rounning a more diverse set of opensource oprating systems for tor nodes? I discount closed source as we don't know what's going on in there. Would that present significantly different attack surfaces? I can imagine a vulnerability in the TCP stack or other kernel functionality in Linux would not be the saem in FreeBSD or vice versa... My nodes are currently Ubuntu but if there's a reason to do so I coould possibly switch OS to FreeBSD (or hurd does tor run on hurd :)) These surface differences result in real world immunities. If all you're running is one thing, and that one thing gets cracked, it's over. This happens all the time. And it's not just the kernel, it's also the differences in libraries, etc. So yes, for that purpose regarding the Tor network, don't pick Linux or Windows. If you want to play and learn something new and not closed source, pick one of the BSD's... free, open, dfly, net. FreeBSD is the obvious general choice, the others will subject you to more specific challenges. 4796 Linux 1650 Windows 294 FreeBSD 75 Darwin 35 OpenBSD 9 NetBSD 4 Bitrig 2 SunOS 2 GNU/kFreeBSD 2 DragonFly ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] bitcoin adopt a node idea
On Thu, Jun 26, 2014 at 10:44 AM, David Hill dh...@mindcry.org wrote: On Thu, Jun 26, 2014 at 12:35:00AM -0500, Scott Bennett wrote: ja...@icetor.is wrote: http://www.coindesk.com/adopt-node-project-aims-bolster-bitcoin-network-security/ Assuming that the relevant bitcoin programs could be taught to talk SOCKS, then it seems that tor hidden services would, in principle if not in performance, be an ideal solution. Running those bitcoin full nodes as hidden services might well make them less vulnerable to being shut bitcoind works fine with tor and has some onion full nodes. Performance of hidden services, however, are severely constrained by the hidden services protocol, which can slow connection times enough to make one consider USnail as a possible alternative, and the need for circuits of 2n-1 relays, which makes access even slower than normal tor circuits of n relays. Performance of hidden services is actually rather good. ymmv. I am using btcd, an alternative full-node implementation written in golang. Find it at https://github.com/conformal/btcd. It has built in proxy support. The wallet, btcwallet, is separate. It also has proxy support, so that you may connect to btcd over tor or as a tor hidden service. That can be found at https://github.com/conformal/btcwallet. bitcoind nodes are a nice target to look for wallets. But with btcd, I run that at home while btcwallet runs on my encrypted laptop which connects to btcd over tor. There is no wallet on my btcd node machine. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Spam
Spammers subscribe to mailing lists. You post to mailing lists. Have fun. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] optimize performance of a relay running on a VM
On Tue, Jul 1, 2014 at 3:24 PM, s7r s...@sky-ip.org wrote: dedicated RAM - 2.6 Ghz 1 core CPU dedicated - OS: FreeBSD 10.0 Release amd64 - DO NOT KNOW IF I HAVE AES-NI SUPPORT OR HOW TO ACTIVATE IT (?) It does not return anything. I have the proc folder, but there is no cpuinfo file in it. Here: root@tor:/ # cat /proc/cpuinfo | grep aes cat: /proc/cpuinfo: No such file or directory That's because FreeBSD is not Linux, its proc is limited to procfs(5) with non process info/knobs in sysctl(8), nor is it really necessary to mount proc. Also, 'aes' is presented in CAPS. That single core might be old enough to not have it. Check: /var/run/dmesg.boot http://svnweb.freebsd.org/ports/head/misc/cpuid/ [also available via ftp package] openssl speed aes ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Running tor in VPS - keep away snooping eyes
On Wed, Jul 2, 2014 at 7:46 AM, Kali Tor kalito...@yahoo.com wrote: I have done all that, so covered on that aspect. Was wondering if disk encryption and use of something like TRESOR would be useful? The private keys for the node are sensitive, and even the .tor/state file for the guard nodes could be if the attacker does not already have that info, same for any non default node selection stuff in torrc. Tor presumably validates the disk consensus files against its static keys on startup so that's probably ok yet all easily under .tor anyway. There was a thread on this some time ago you can find. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Oubound Ports
On Sat, Jul 12, 2014 at 11:32 AM, krishna e bera k...@cyblings.on.ca wrote: the destination. The process on the local computer will use a random numbered source port (from 1 to 65535) on leaving the local computer. No, it may source from any unused port, assigned hopefully at random, or by successful self selection, hopefully from 49152-65535, and usually not from 0-1023 without priviledge. See ip(4). Your OS may differ. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] badexit D9B6E8F3DC60095F25252A1986E90932454C24D3
Breaks TLS on check.torproject.org, etc. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [tor-dev] Hidden service policies
On Sun, Jul 20, 2014 at 9:57 PM, Thomas White thomaswh...@riseup.net wrote: Mike Hearn, Simple. If you start filtering anything at all, regardless of what it is ... then I will block any connection of your relays to mine ... Freedom isn't free unless it is totally free and a selective reading policy through Tor is not just a bad idea as stated below, I find it outright insulting to me and everyone else who cares about the free and open internet. The fact somebody has the audacity to come to a project like Tor and propose blacklisting mechanisms is jaw-dropping. ... As I recall, you are also the person who raised the idea of coin tinting or a similar concept in the bitcoin community to identify suspect coins and that backfired spectacularly on you. Yes, that is the person. Though the term is known as 'taint'. One of many discussions from that suggestion is here: https://bitcointalk.org/index.php?topic=333824.0 so while you are reading this, let me know if you run any relays so I can avoid them. router riker 207.12.89.16 9001 0 0 fingerprint 8657 6CF6 AA84 496F 62C0 5AFE 9F26 8962 A5F0 B2BD contact Mike Hearn m...@plan99.net accept *:8333 reject *:* Normally I would thank exits for passing BTC traffic, but now I'm unsure of this one (and a few others), especially given that's the only exit policy of the above node. To identify anon (Tor) coins for marking and tracking? ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Finding relay Sybils / Groups [re: relay_early/blackhat]
As a project then to production development, someone should go back through the entire history of descriptors and look for groups coming online... dates, IP's, contacts, tor/OS versions, nicknames, ISP's, geoip, numbers coming online over sliding timeframes, correlation to 'news events', etc. There may be more questionable relays to be found. We were talking about such influxes around july 4 09, ironically, or not. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Learn Linux free for beginners
On Sat, Aug 2, 2014 at 1:51 AM, I beatthebasta...@inbox.com wrote: A free online course from The Linux Foundation for beginners begins today. A free online course from The FreeBSD Foundation for beginners began years ago.. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Time information
On Thu, Sep 4, 2014 at 7:04 PM, Roger Dingledine a...@mit.edu wrote: I wonder how to get them to notice more consistently? Simple, either mail their contact (if any) and they fix it, or blacklist their fingerprints. There is no reason any relay should not be able to sync time. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Good hosting location for exit relay
finding the best country and provider. Tired of people asking here what's the most best/friendly provider. Do people think saturating popular names like Amazon AWS, OVH, Dreamhost, Rackspace, Lowendbox, Hurricane, Digitalocean, etc with nodes is helping Tor's physical, logical or legal diversity? Or is that helping small independant businesses that just might have crazy ideas like say... anonymity and privacy... prosper? https://www.google.com/search?q=vps+provider+in+chile https://www.google.com/search?q=vps+provider+in+taiwan https://www.google.com/search?q=vps+provider+in+ukraine https://www.google.com/search?q=vps+provider+in+india https://www.google.com/search?q=vps+provider+in+south+africa https://www.google.com/search?q=vps+provider+in+uae https://www.google.com/search?q=vps+provider+in+greece https://www.google.com/search?q=vps+provider+in+latvia http://en.wikipedia.org/wiki/List_of_urban_areas_by_population Just pick some third or second world country, or random city with 1M pop or more and start looking with credit card in hand. Pay monthly, document it on the wiki, and move on to another if they suck. The place/provider that will keep the node, move a useful amount of bandwidth, and that no one else has picked... that's the best place. And having not been picked before, you won't find it by asking this list :) ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Anonbox Project
On Fri, Oct 17, 2014 at 3:36 PM, Colin Mahns colinma...@riseup.net wrote: It looks like Kickstarter has suspended the project. Some of this thread seems a bit silly. Tor does one thing, it anonymizes your IP address. These boxes push everything through that, which is generally exactly what you want... no leaks. So great, go sell a million of them. But some of this thread bashes the boxes for doing simply that. I say NO. If you want a teacher to handhold and teach you anything safe beyond how to be an anon IP address (which Tor and boxen already provide) ... such as system administration, session management, how to actually be contextually, network, and datawise anon... go kickstart a companion book on that. Don't just bash the boxen about not including such a book if you are not also willing to write the book... as the boxen exist to sell 'IP address anonymizers', not books. Chinese lookalikes, and best interaction with Tor network, are also separate subjects. To the latter which is relavent, Tor is becoming very popular, its fundamental design and ops need planned to be able to scale to many millions of clients, like yesterday perhaps. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Platform diversity in Tor network [was: OpenBSD doc/TUNING]
On Tue, Nov 4, 2014 at 12:25 PM, Libertas liber...@mykolab.com wrote: I think it would be a good idea to add OpenBSD to doc/TUNING because [...] promoting OpenBSD relays benefits the Tor network's security. Absolutely. Not just due to OpenBSD's security positioning, but moreso from network diversity. Windows is its own world. But if you're a Unix admin there's no reason Linux should be deployed 20x more often than [Free/Open]BSD. It's ridiculously counter to meeting diversity goals, especially with bandwith weighting if one platform is getting grossly disproportionate traffic than another. Just pick one of the two BSD's and run it instead. FreeBSD in particular is well suited to the OS and network needs of Tor. And knowing how to admin more Unixes will serve any admin well. 5950 Linux 1593 Windows 173 FreeBSD 55 Darwin 44 OpenBSD 7 NetBSD 6 SunOS 4 Bitrig 2 GNU/kFreeBSD 1 DragonFly ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [tor-talk] Platform diversity in Tor network [was: OpenBSD doc/TUNING]
I'd agree simply because Windows presents a much larger attack surface. The amount of code running on a minimal Unix installation plus Tor is a lot less than a Windows system, especially network facing code. ... Running code, or network accessible code? Either way I don't see how you came to that calculation. 'Minimal' Unix + Tor + SSH restricted by SSH Key vs 'Minimal' Windows + Tor + RDP restricted by Client Certificate. I also don't know what you mean by 'minimal' as very few ... I think a Windows Server, properly configured, is roughly as secure as a properly configured Linux Server. ... I think there have been more bugs that result in RCE on production Linux servers running SSH and a webserver in the past 4 years than there have been in production Windows servers running RDP and IIS. ... I think if you're pointing fingers at China and the NSA, you should assume they have RCE in both Windows and Linux. ... I think running relays on Windows Servers is no worse than running relays on Linux Servers, and therefore it is good to do, because it adds diversity to the network. Attack surface on a well adminned relay comes down to three things: - Network stack itself (kernel) - Daemon software itself (tor + remote admin) - Their respective use of other kernel/library/shell provided resources. I might suggest the current proportion of Windows to Linux is roughly ideal. This is primarily because, all other things set equal at 'minimal' (= tor + remote admin), good adminning, and good control of corporate secrets (or moles)... Windows still has one huge strategic weakness at that point... the magic packet. It's the whole binary vs. opensource argument. So essentially, the correct ratio of the two might be the odds you place that a binary OS has a magic packet. Today's node count shows 73% to opensource platforms. I'd suspect 73% is about where a lot of analysts might bet on Windows being magical, whether by/for the NSA, or any other reason or source. (Remember this... https://en.wikipedia.org/wiki/NSAKEY That was just from running 'strings'. Good luck trolling all of Windows with a disassembler... a nice fat payoff if you do. And the number of disassembling vs. opensource auditors is probably even more heavily skewed. And Windows is 'trusted' by buyers, nor can you replicate their binaries from any 'source code sharing agreements'. Then it's Patch Tuesday again... so it could be no one has or ever will disassemble audit it. So odds end up being pitched instead. And for many applications, that's good enough.) The real problem below is the 96% allocation of opensource to Linux and 4% to Other opensource. That's something that should be fixed. For these purposes, it doesn't matter which BSD/Other you pick... once you get the security odds there back towards say 50:50 Linux:Other, then you can debate userland and relative security amongst them all you want. Here's some links to get you started, including two other main branches of the Unix Kernel family tree at the bottom... 5939 Linux 1591 Windows 173 FreeBSD http://www.freebsd.org/ 56 Darwin 44 OpenBSD http://www.openbsd.org/ 7 NetBSD http://netbsd.org/ 6 SunOS 4 Bitrig https://www.bitrig.org/ 2 GNU/kFreeBSD https://www.debian.org/ports/kfreebsd-gnu/ 2 DragonFly http://www.dragonflybsd.org/ 0 Illumos (OpenSolaris) http://wiki.illumos.org/display/illumos/Distributions 0 Minix http://www.minix3.org/ Official metrics... https://metrics.torproject.org/network.html Someone should really do an analysis of platform vs. exit bandwidth as well. Anyone? Also, isn't there some project out there that is counting the historical number of kernel bugs+severity per OS over time? [To cpunks to cover all the other volunteer node based networks out there that could benefit from tuning their platform ratios.] ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Platform diversity in Tor network [was: OpenBSD doc/TUNING]
On Wed, Nov 5, 2014 at 11:20 AM, Niklas Kielblock nik...@spiderschwe.in wrote: Is there much of a difference between setting up Tor on OpenBSD vs. Linux or other Unix(like) systems? Tor itself? ... https://dist.torproject.org/ tar -xzf torball.tar.gz cd tor ; ./configure ; make ; cd src ; ./tor Nope, absolutely no difference whatsoever ;) Pity the fool who endeavours to learn any system dependant packages/ports system before such Unix basics, lest ye cast your lot as a poor and dependant admin forever. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] [tor-talk] Platform diversity in Tor network [was: OpenBSD doc/TUNING]
On Thu, Nov 6, 2014 at 2:43 AM, David Serrano t...@dserrano5.es wrote: On 2014-11-05 23:58:43 (-0500), grarpamp wrote: The real problem below is the 96% allocation of opensource to Linux and 4% to Other opensource. Someone should really do an analysis of platform vs. exit bandwidth as well. Anyone? Here ya go. Observed bandwidth per OS in relays having the exit flag: 93.62% 4459816582 Linux 4.51% 214639363 FreeBSD 1.25% 59672066 Windows 0.25% 11754598 Darwin 0.17%7896687 Bitrig 0.15%6964863 OpenBSD 0.06%3091495 SunOS This excessive Linux dominance in both node count and bandwidth really should be balanced out, like why not? I'd expect if some of the big relays switch to any other OS that would flatten out the bandwidth part pretty easily. You'd have to check say the top 10, 25, 50 or so relays to see to what extent they are part of this mess, I'm sure it's similar. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] FreeBSD's global IP ID (was: Platform diversity in Tor network)
On Thu, Nov 6, 2014 at 8:52 AM, Philipp Winter p...@nymity.ch wrote: On Wed, Nov 05, 2014 at 04:04:41AM -0500, grarpamp wrote: 173 FreeBSD FreeBSD still seems to use globally incrementing IP IDs by default. That's an issue as it leaks fine-grained information about how many packets a relay's networking stack processes. (However, nobody investigated the exact impact on Tor relays so far, which makes this a FUD-heavy topic.) It looks like approximately 50 out of the 131 FreeBSD relays I tested (38%) use global IP IDs. There's a sysctl variable called net.inet.ip.random_id which makes a FreeBSD's IP ID behaviour random. FreeBSD relay operators should set this to 1. Note that this issue was already discussed earlier this year in a thread called Lots of tor relays send out sequential IP IDs; please fix that!. It's been default off since before it was a sysctl over a decade ago. Anyone know what the deal is with that? Some objection, or forgotten flag day, or oversight that really should be set to 1? https://svnweb.freebsd.org/base?view=revisionrevision=133720 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Node Operators Web Of Trust
Is it not time to establish a node operator web of trust? Look at all the nodes out there with or without 'contact' info, do you really know who runs them? Have you talked with them? What are their motivations? Are they your friends? Do you know where they work, such as you see them every day stocking grocery store, or in some building with a badge on it? Does their story jive? Are they active in the community/spaces we are? Etc. This is huge potential problem. NOWoT participation is optional, it is of course infiltratable, and what it proves may be arguable, but it seems a necessary thing to try as a test of that and to develop a good model. Many operators know each other in person. And the node density per geographic region supports getting out to meet operators even if only for the sole purpose of attesting 'I met this blob of flesh who proved ownership of node[s] x'. That's a big start, even against the sybil agents they'd surely send out to meet you. Many know exactly who the other is in the active community such that they can attest at that level. And so on down the line of different classes of trust that may be developed and asserted over each claimed operator. Assuming a NOWoT that actually says something can be established, is traffic then routable by the user over nodes via trust metrics in addition to the usual metrics and randomness? WoT's are an ancient subject... now what are the possibilities and issues when asserting them over physical nodes, not just over virtual nodes such as an email address found in your pubkey? And what about identities that exist only anonymously yet can prove control over various unique resources? If such WoT's cannot be proven to have non-value, then it seems worth doing. This doesn't just apply to Tor, but to any node based system. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] FreeBSD's global IP ID (was: Platform diversity in Tor network)
On Fri, Nov 7, 2014 at 11:31 AM, Adrian Chadd adr...@freebsd.org wrote: ... that's .. odd. Let's poke the freebsd crypto and network stack people and ask. I can't imagine why this is a problem anymore and we should default to it being on. I don't think there's a crypto@ list, though security@ might represent. The other thing you could do is have the tor port require it be turned on before tor runs. That would not cover people who compile and use upstream Tor. Ideally, the Tor client could check for any system parameters it feels are critical before running, or simply delegate them and/or any parameters of lesser importance to platform specific guides on the Tor wiki. On 7 November 2014 00:20, grarpamp grarp...@gmail.com wrote: On Thu, Nov 6, 2014 at 8:52 AM, Philipp Winter p...@nymity.ch wrote: FreeBSD still seems to use globally incrementing IP IDs by default. That's an issue as it leaks fine-grained information about how many packets a relay's networking stack processes. (However, nobody investigated the exact impact on Tor relays so far, which makes this a FUD-heavy topic.) It looks like approximately 50 out of the 131 FreeBSD relays I tested (38%) use global IP IDs. There's a sysctl variable called net.inet.ip.random_id which makes a FreeBSD's IP ID behaviour random. FreeBSD relay operators should set this to 1. Note that this issue was already discussed earlier this year in a thread called Lots of tor relays send out sequential IP IDs; please fix that!. It's been default off since before it was a sysctl over a decade ago. Anyone know what the deal is with that? Some objection, or forgotten flag day, or oversight that really should be set to 1? https://svnweb.freebsd.org/base?view=revisionrevision=133720 ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Node Operators Web Of Trust
On Mon, Nov 10, 2014 at 5:58 AM, Gareth Llewellyn gar...@networksaremadeofstring.co.uk wrote: I had an idea for this a little while ago; https://tortbv.link/ using the published GPG signature in the contact info to sign the node fingerprint, if you trust the GPG key then you can _possibly_ trust that the node is run by the named operator. As an operator you would either - sign with your key a statement of node fingerprint into a notary service - create a subkey of your key holding said statement in comment - sign your key by node key if security of node key was better https://trac.torproject.org/projects/tor/ticket/9478 But since the trust desired is from the [real]world down into and over the nodes, this one isn't really useful. You then still have to use your key to form [real]world WOT among operators. Tying nodes to some [nym] identities is the first part... in a way, making sybil harder. Then users opting to route paths through tor via trust metrics need to configure their client with whichever various trusted wot/root keys they like or subscribe to, which then uses them to score fingerprints for pathing. Doing this with them is second part. Degree of freedom from some crossing of trusted key people is probably sufficient to score things. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Node Operators Web Of Trust
On Mon, Nov 10, 2014 at 8:36 AM, Julien ROBIN julien.robi...@free.fr wrote: I'm interested but, we must agree on that, it probably shouldn't be used for adding privilege to people in this list. It's up to the user to use or trust any assertions and/or the wot, there is not force there. Though yes, I'd never blacklist nodes in the directories just for nodes not being part of the wot. If one successfully got an invitation code, an evil attacker The user is evaluating and doing the inviting as they see fit. For example, I might be inclined to route my traffic only over nodes run by those posting to this list, as opposed to also over the thousands of nodes that are nothing to me but an IP address. The closest analogy is subscribing to adblocker subscriptions. If they subscribe to one that blocks torproject.org, that's their problem. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Website no longer available from Tor
In your opinion why is not it more accessible? You asked four times. We can't see your systems or your exits so we don't know. Run your own restricted exits on your own various computers, starting with those you can reach it with via clearnet, then route all your traffic out those exits and do more testing, beginning with tcpdump or some form of log/traffic analysis on both the exit and webserver. There's obviously blocking or misconfiguration involved. Let us know what you find. https://www.torproject.org/docs/documentation.html.en ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Colocated relay pricing
What are you seeing as prices to colocate, in terms of: 1RU - rent, power, etc IP's - a few (3, or up to a /29 ie 8-3=5) Bandwidth - In terms of $US/Mbit Colocation Country/State. Company. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Someone broke the tor-relay speed record?
On Wed, Dec 31, 2014 at 4:11 AM, Justaguy justa...@riseup.net wrote: https://globe.thecthulhu.com/#/relay/F528DED21EACD2E4E9301EC0AABD370EDCAD2C47 Someone just got 149.08 MB/s on a non-exit relay. This is amazing! Would you mind saying what kind of hardware you use for this? Ipredator used https://ipredator.se/guide/torserver to get to 101MB/s. So your setup should be even more extreme. Not within any definition of sane expenditure... The i7-4790k is Intel's highest clocked processor, ever. It's also Intel's current highest single thread performer. i7-4790k 4 x 4.0ghz cores = 1600 8mb 32gb ddr3-1600 88w $340 tsx-ni (1960 as OC'd by IPredator.) IPredator put a 10gbps nic in there and is moving only 800mbps OC'd (or 655mbps stock. Which is 165mbps/core, or 220mbps/core if isolcpus=1,2,3). Assume for moment this is cpu saturation. To do better you have to buy more core x ghz results like: i7-5930k 6 x 3.5ghz cores = 2100 15mb 64gb ddr4-2133 140w $580 So that's 1155mbps using all 6. Plus the more cache and much faster ram. And with good tor and os optimizations, you could probably hit 1250mbps. i7-5820k 6 x 3.3ghz cores = 1980 15mb 64gb ddr4-2133 140w $390 So that's 1090mbps plus. (ram for the above two: $420 32gb 4x8 ddr4-2133, non-OC) e5-2697v3 14 x 2.6ghz cores = 3640 35mb 768gb ddr4-2133 145w $2800 would fill 2000mbps plus. If you only need to fill 1000mbps, or however much bandwidth under that you're buying, just find the cheapest core x ghz that does that. While IPredator and their build may be cool, it fails to ROI, thus it's completely pointless to build. They wasted... https://www.google.com/finance?q=EURUSD Capital cost: - Water cooling to get 22.5% clock over stock. (More common/free OC gains are the low end of 5-18%.) You could simply pay $240 more for the i7-5930k and get more core x ghz performance than they did, without overclocking. (Overclocking is also by definition a risk to data/lifetime). Or pay $50 more and still get more. (Both assuming ram and other resources aren't used up due to two more core of tor instances). $1110 radiator (IPredator quoted $1570) $55 flow meter (IPredator qooted $50) $30 connectors, estimated qty 2 x $15 $100 coolant, qty 5 x $20 (IPredator quoted $120) $25 tubing coil $5 clamps, estimated qty 10 $95 waterblock $15 paste (IPredator quoted $25) wasted: $1435 low to $1920 high - Ram $1000 32gb 4x8 ddr3-2800, equivalent brand (IPredator quoted $1550) $280 32gb 4x8 ddr3-1600, non-OC wasted: $720 low to $1270 high - Case $730 5u case (IPredator quoted $660, saved $70) $300 1u case wasted: $360 low to $430 high - Motherboard $25 estimated economy vs. enthusiast savings wasted: $25 total capital wasted: $2540 low to $3645 high net performance gain vs. other capital options: zero or less $760 10G-PCIE2-8C2-2S (IPredator quoted $660, saved $100) $440 E10G42BTDA is it comparable? if so that's another $320 wasted (Total cost IPredator quoted: $5420) Ongoing rent cost: - 4u on the chassis (1u required + 4u wasted) - 3u on the radiator wasted: 7u Enthusias[m|t] is great, Tor could use some, and I've no want to diminish that... but back in the real world away from the show... if you just ran the i7-5930k stock in a barebones 1U, you'd have enough capital left to buy 2 more servers and enough rent to feed them at least some internet. (IPredator failed to quote in their review the amount of bandwidth purchased, the price/megabit, and thier cpu load at a given megabit. This makes it harder to fully analyze. Please post cpu load @ mbps data.) Moral: Operators... please don't waste your Tor budget on silly enthusiast crap. I'd also suggest testing FreeBSD. If you want to run real Tor contests, try for... - most bandwidth per node cost (depth, as above) - most usable nodes per cost (breadth) - etc And if you want me to win them, or this saved you $$$, donate here :-) btc 1BbEqMvEdsKiPuRT75HGrjZP8zqquamBPn ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Someone broke the tor-relay speed record?
Since people aren't going to like paying the 10g switchport fee, nor the price of small bandwidth over 1gbps on it, the fastest real world box for individual tor nodes is probably going to be that i7-5820k off a gig port for $1235 or less. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] High speed exit question
On Fri, Jan 2, 2015 at 10:48 AM, Kura k...@kura.io wrote: Hey guys, I recently decided to get myself an 8 core, 16 GB RAM machine to use for running an exit relay and was wondering, Tor only works on one core, even setting NumCPUs to 2 doesn't do a whole lot so, how is it even possible to get more than maybe, 300Mbps or so from one relay? What cpu model and cpu load percentages at what bandwidth is that? https://lists.torproject.org/pipermail/tor-relays/2015-January/006041.html ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] Stats [was: freenode]
On Sat, Jan 24, 2015 at 3:16 PM, cacahuatl cacahu...@autistici.org wrote: Most of the network is under-utilised guards and middle nodes, hidden services don't stress exits, which are the limited resource. Exits can and do serve in all the other node roles too. I don't think there has yet been a study to determine the actual unused capacity of the relays as grouped by flag permutations. Nor has compass been enhanced to support that selection matrix. Triples? A HS doubles vs exit. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Relay operators: help improve this hardening document?
On Thu, Feb 5, 2015 at 11:15 PM, Nick Mathewson ni...@freehaven.net wrote: The idea is that Tor could ship with some basic recommendations, and links to places to find more advice? If it's a question that can be answered by searching how do i secure and run my unix server, including anything other than links to such answers would seem redundant. Sure, noobs are out there, but it isn't efficient for application projects to formally provide general computer training. If it's a question of how do i make tor/unix run happy together on my server, ie: file descriptor shortages, that's a specific known interaction with tor itself, and thus a different situation. The only thing I'd ship with tor are links... to two community maintained wiki pages, one for each class of question above. From there the community can write whatever faq help desired independant of the release process and considering external developments. If there wasn't a community or wiki, then shipping any critical runtime dependency notes on the second class of question would be reasonable. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] MiB/s / metrics
On Mon, Jan 19, 2015 at 5:55 AM, Sebastian Urbach sebast...@urbach.org wrote: I opened a ticket recently with the intention to use a more common unit than MiB/s for metrics. Karsten basically agrees but is waiting for more input. https://trac.torproject.org/projects/tor/ticket/14257 Tor is at its core a network application, an interface to the network, a router. In the real ISP world therein everyone speaks in mega bits per second 10^n (and now with 100Gbps links, in Gbps). Only the downstream hosting world speaks in mega bytes 2^n, per whatever time unit they dream up. This comes from attempts by hosters to appease people pushing their disk files MiB's over the net at link rate, not spread over bandwidth rate. In fact, the hosters have to convert that appeasement on their backend to aggregated Mbps so they can talk to their real ISP's. I've suggested before that Tor project should use Mbit/s (or Mbps or Mbit[s] where the slash presents a problem) as its primary default representation for Tor client and all related projects that refer to bandwidth. Tor is a bandwidth app, especially at the relay level. There is no disk or instantaneous link rate transfer need applying to Tor relay. (As opposed to user level which is more of a mashup of rate usage contexts and interests similar to bittorrent/webserving.) Then if people want MiB's or MB's so they can continue perpetuating and interfacing with hosters who do the same, you could add a few global prefix, unit and time options to switch all representations over at once. (Tor client has recently added per stanza Mbps configs which is a fine alternative to global. Yet again, the manpage and even maybe the code still uses nonsense in regards to capitalization, base 2 vs 10, crossed contexts, etc...) Start here, use the table in the upper right, ignore jedec, and pick and apply 10^n or 2^n representations consistantly. https://en.wikipedia.org/wiki/Binary_prefix BandwidthRate N bytes|KBytes|MBytes|GBytes|KBits|MBits|GBits A token bucket limits the average incoming bandwidth usage on this node to the specified number of bytes per second, and the average outgoing bandwidth usage to that same value. If you want to run a relay in the public network, this needs to be at the very least 30 KBytes (that is, 30720 bytes). (Default: 1 GByte) Notably, KBytes can also be written as kilobytes or kb; No, KBytes is invalid, there is no capital K, only k (SI) and Ki (binary). Nor is b ever a byte, nor is Bit[s] ever capitalized. True network applications should also not be crossing network-like prefixes with disk-like objects or vice versa, ie: Gibit[s] (non-network binary and single bit), or the GBytes (network SI and binary multiples of bit) above. If you cross it up or make errors in context in one place that throws all your docs and configs into question. Even I still mess it up sometimes. it's easy to forget that B means bytes, not bits. Nope :) Abbr B means byte (now formally of width eight bits as in octet/o, and still unfortunately caveat bel/B as in dB), and abbr bit means bit, (and b is now just nothing but informal efficient shorthand for bit if I recall). https://en.wikipedia.org/wiki/IEC_8-13 https://en.wikipedia.org/wiki/Byte https://en.wikipedia.org/wiki/Octet_(computing) https://en.wikipedia.org/wiki/Bit Anyway, tor relay is network not disk, so I'd suggest megabits, or kilo/giga as scale appropriate. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] entry guard interference?
You obviously can't disclose your nodes for others to test or be telling us what you're going to do over clearnet when. Yet during the time of an outage, you might try to leave the old tor running and - copy over old tor .tor and torrc to a new tor instance, start it and see if it works over the guards. That may point some state jam inside the old tor and a good clearnet path. - run a new tor with no .tor and default torrc and try to telnet to the old guards OR ports over that, then they seem to be up. - put a TransPort in that new default torrc config, put packet filter in front of old tor, hup the new one, see if old tor works over this tor... to point to your clearnet path to the guards being specifically bad to tor. - turn on old tor debug log and see where it is repeatedly stalling. A script could determine this in a couple minutes. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] IP addresses as false positives?
On Mon, Jan 5, 2015 at 4:11 AM, Kura k...@kura.io wrote: On a semi-related note, I run a fair number of exit and middle/guard relays that I can guarantee do not try to do anything naughty to content, feel free to test your Tor against them to see if you still get the same virus warnings, OP. I prefer the ones that replace all advertisements with kittens. And mine just sniff for passwords so don't use them ;) ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] IP addresses as false positives?
On Mon, Jan 5, 2015 at 3:33 AM, Kura k...@kura.io wrote: I would say that maybe it's a possibility that traffic gets flagged as such too? ... antivirus [...] one that does traffic inspection Oh, well that could be too. Tor traffic is crypted/obfuscated and thus could generate a random hit that AV points at the Tor binary as responsible for. But the OP is getting URL's from AV so it may be watching his localhost SOCKS for http streams. What's weird is OP's Object is https://, which is not terminated to plaintext anywhere but in the browser or tor. Perhaps not enough info. machine, AVG reported that tor.exe was a possible virus and removed it, this also happened when we tested the Tor Vidalia bundle. This was simply a filesystem check though, rather than packet/traffic inspection. It was also very recent, within the last week. Gratuitous listing by AVG perhaps? On Mon, Jan 5, 2015 at 2:30 AM, eliaz wrote: The antivirus program on a machine running a bridge occasionally reports like so: Object: https:// Infection: URL:Mal [sic] Process: ... \tor.exe ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] IP addresses as false positives?
On Mon, Jan 5, 2015 at 2:30 AM, eliaz el...@riseup.net wrote: The antivirus program on a machine running a bridge occasionally reports like so: Object: https://some IP address Infection: URL:Mal [sic] Process: ... \tor.exe When I track down the addresses I find they are tor nodes (sometimes bridges, sometimes guards, sometimes exits. Are the flagged nodes in some ways miss-configured, or can I consider these to be false positives? Is there anything to worry about here? Detail: The tor and standalone vidalia folders have been flagged as exceptions (i.e. excluded) in the virus scanner. The scanner's web module is picking up the IP addresses from the port traffic. Thanks for any enlightenment - eliaz Since the internet is known to be an infected wasteland, and exits are known to MITM your streams, I'd suggest either compartmentalizing all your surfing in a disposable VM (which should probably be done anyways), or excluding web traffic from your scanner. Additionally, if you are able to isolate and confirm that a specific exit is MITM'ing you (vs the malware/virus being on the original clearnet site itself) feel free to post its fingerprint here so that the workers can double check and dirauths can give it the bad exit flag. Unfortunately Tor doesn't have simple logging format that you can watch in real time alongside your scanner. I'm finishing a spec ticket for that soon though. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Reminder: exit nodes probably shouldn't be using Google's DNS servers
On Sat, Jan 10, 2015 at 10:58 PM, Richard Johnson rd...@river.com wrote: It is especially a good idea to have your own local DNS resolver if you run Tor exits at an institution that's required to otherwise log DNS queries. Tor needs a separate (and non-logging) DNS resolution system to prevent the institution from being presumed aware of Tor users' lookups. That this also protects Tor users from having their DNS queries logged is good as well, but that isn't necessarily the driver for the institution. ;) Do not presume that pointing dns locally prevents passive monitors anywhere along your network graph of clearnet hops from seeing your dns queries there. And ultimately, exit IP can be observed and correlated from the roots down with increasing difficulty. That said, yes, local is still better, and often more performant, than pointing to a privacy joke like google. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Reminder: don't run transparent proxies at exits
On Fri, Jan 9, 2015 at 10:26 PM, Drake Wilson dr...@dasyatidae.net wrote: eric gisse wrote: Plus the logic starts to get warped when you wonder So do you BadExit every node that runs on an ISP that caches traffic? What about ISP's (and openDNS) that NXDOMAIN trap to insert advertising? These, I think, are more general points that have not adequately been resolved anywhere, though I think the vague consensus has been that the latter merits a BadExit at the moment. Indeed the basic idea of exits An external NX ad trap is a bit tertiary since the exit is truly representing its view of the net. As far as http caching, it would be relatively fine IF the cache truly did good practice, and IF the site truly did good design for the cache to follow. However those two necessary truths are often false, whether by AND or XOR context. So to be true, a cache shouldn't be deployed, but in the interest of bandwidth they are, more commonly at small end-tier user access ISPs (including exits) for that purpose. I'd suggest best practice is for - users to use https to bypass - caches to insert their tagline in http headers so users can bitch to the owner. - Tor exits? Well, they're volunteer paid diversity, so which is more valuable to you? The IF's above, or TCP truth at potential cost to diversity? I prefer TCP truth, but if I was a constrained operator I'd do my best research into setting up a quality cache. Provided caching images of ill repute on disk were not an overriding concern. Last, the badexit projects should probably try to assess the current state of caching quality in order to further suggest practices for operators. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
[tor-relays] badexit 03F84EA2E09CF427A519C65479DC0BF0D72886A6
router Tansam 79.143.87.234 443 0 0 03F84EA2E09CF427A519C65479DC0BF0D72886A6 Appears to be having trouble with, or is doing something with, http versions of https en.wikipedia.org articles. They're either blank or stripped of framework. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] IP addresses as false positives?
On Tue, Jan 6, 2015 at 5:34 AM, eliaz el...@riseup.net wrote: for three different IP addresses. I'm not panicked about this don't Those IP's are exits, no idea why they're being called out by avg. What are the malware/virus id's, the same all the time, different? Try a unix like freebsd or linux someday, tends to be more secure anyway. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Someone broke the tor-relay speed record?
On Sat, Jan 3, 2015 at 9:20 AM, usprey usp...@gmail.com wrote: A8-5600K bought for a cheap private server 1,5 years ago https://en.wikipedia.org/wiki/List_of_AMD_accelerated_processing_unit_microprocessors That could probably deliver 1/3 of an i7-5820k at 1/4 the price... a better deal if targeting its lower possible bandwidth. I can set up system stats if you want proper figures, but far from full load with 250Mbps average bidirectional traffic. Relative performance is mostly a benchmark thing, so the model lineup I gave can be found anywhere and is pretty solid. To be able to better predict/pick the megabits a model could deliver I'd need a handful of better report samples/graphs: - cpu model - graph of total system load % vs each cpu load % vs bandwidth - test environment statement, how many tors running, SMT, other system uses, bandwidth/nic config, OS... Most reports seen on this list are useless to establish that... oh, i'm running an i3 and moving 60Mbps blah blah... so don't take my megabit estimates as anything yet. ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
