- tor-relays - lists.torproject.org

How to block IP address on exit node relay
by Piotrkowska 30 Aug '13

30 Aug '13

I am running an exit node under reduced exit policy on a VPS. My provider requested that I block a specific IP address due to spam issues. I'm guessing I should add a line in the torrc file. Can anyone tell me the exact line I have to add to the torrc file to block the address? Something like: "reject 12.34.567.89" ?

4 3

Tor exit notice
by Pascal 29 Aug '13

29 Aug '13

The Tor exit notice at https://gitweb.torproject.org/tor.git/blob_plain/HEAD:/contrib/tor-exit-not… contains the word "server" exactly once. It should probably be changed to "router" to match the rest of the document and avoid the common assumption that servers host data. -Pascal

2 1

tor-bridge life cycle
by Trigger Happy 28 Aug '13

28 Aug '13

Hi list, Greetings from Poland, i have a question about tor bridge life cycle. 1) I'm running a bridge 2) Someone from china gets bridge id 3) Bridge gets banned 4) what now ? do i receive an email about it , so i could change tor-bridge to tor-relay ? or change tor-bride ip ? Thanks in advance -- Trigger Happy jabber: triggerhappy(a)jabber.ccc.de otr: BD0E1860 569B3888 657BC5C1 517532A3 A83EA214

1 0

Hello List
by Kevin C. Krinke 28 Aug '13

28 Aug '13

Hi Everyone, I've just gone through most of the steps outlined in https://blog.torproject.org/running-exit-node over the last week, though I couldn't get the SWIP setup I did manage to get the reverse DNS configured for me by my ISP. It's taken me a while to decide to run a Tor Exit Node and part of the reason for hesitation is that I wanted to research it well and do it right. So, there's basically a few things: First, I'd like to say that my ISP is TekSavvy (Ontario, Canada); they are absolutely great and have been immensely helpful throughout this whole process. I would highly highly recommend their VDSL service to anyone in Ontario, Canada who's looking for an ISP that does all it can to protect the privacy of it's subscribers. Not to mention that they do offer unlimited bandwidth plans. Second, my Tor Exit Node is permanently located at tor-proxy-readme.onest8.ca (206.248.189.157). That's a static IP and I plan on running this service for as long as I possibly can. Pretty much the only reason I'd shut it down is if either A) TekSavvy changes their AUP and requests that I shut it down (highly unlikely) or B) I'm forced by legal means (again unlikely because I've followed the Tor guide and use the recommended Exit Policies). Third, and probably the most relevant part of this email for the list… I want to help more. What services (other than Tor) can I host? What else is needed in the general community? Thanks! My best, Kevin

4 6

Re: [tor-relays] new relays
by tor＠t-3.net 27 Aug '13

27 Aug '13

A mechanism which empowers detecting and stopping what you and I consider to be 'evil' could be harnessed and used to target non-evil things, and that's where the problem is. Let's pretend that tomorrow, Tor gained the ability to filter out evil images. Shortly thereafter, governments might start making demands upon the Tor designers to utilize the underlying technical components of that system according to their own designs and demands. Such a scenario could be dangerous for everyone, including the designers personally. What happens to them if/when they refuse a demand like that, or potentially do a Lavabit? What if the existence of such a function can be corrupted and used in a rogue sort of relay to track things it wasn't intended to? Not to mention, at the point where anyone becomes able to note or affect the content, the question of who is in control of and responsible for it comes into play. Assuming Tor could exist in such a state, you may personally choose to filter CP, but then your government or ISP demands that you also filter activists X, Y, and Z, and list of topics A. Your line at 'evil' would be forceably drawn by other people, just like it is on the public internet today. Btw our exit node blocks random unknown ports ('bittorrent') to aid the node's longevity. It wasn't a moral stand. On Tuesday 27/08/2013 at 12:09 pm, Jon Gardner wrote: > On Aug 22, 2013, at 11:56 AM, mick <mbm(a)rlogin.net> wrote: > >> >>> >>> The other thing that I am weighing is just a moral question regarding >>> misuse of the Tor network for despicable things like child porn. I >>> understand that of all the traffic it is a small percentage and that >>> ISPs essentially face the same dilemma, but I wonder if more can be >>> done to make Tor resistant to evil usage. >>> >> Tor is neutral. You and I may agree that certain usage is unwelcome, >> even abhorrent, but we cannot dictate how others may use an >> anonymising >> service we agree to provide. If you have a problem with that, you >> probably should not be running a tor node. > > Then why have exit policies? Exit nodes regularly block "unwelcome" > traffic like bittorrent, and there's only a slight functional > difference between that and using a filter in front of the node to > block things like porn (which, come to think of it, also tends to be a > bandwidth hog like bittorrent--so it doesn't have to be just a moral > question). If someone has a problem with exit nodes blocking things > like porn (or bittorrent, or...), then they probably should not be > using Tor. > > The very idea of Tor is based on moral convictions (e.g., that > personal privacy is a good thing, that human rights violations and > abuse of power are bad things, etc.). So Tor is most definitely not > neutral, nor can it be--because, if it is to exist and flourish, those > moral convictions must remain at its foundation. One cannot on the one > hand claim that human rights violations are "wrong" while on the other > hand claiming that pornography (especially child porn) is "right." If > one wants further proof that Tor has a moral component, one has only > to visit http://www.torproject.org, click the "About Tor" link, and > notice the discussion points. I doubt that anyone could convince the > Tor team to add "...for unfettered access to pornography..." as a > bullet point under "Why we need Tor." > > The Tor devs go to great lengths to try to keep "evil" governments > from using Tor against itself. Why not devote some effort toward > keeping "evil" traffic off of Tor? Given the fact that "we need more > relays" is the common mantra, it seems to me that if the Tor community > could come up with a technical answer to address at least some of the > most egregious abuses of Tor--things like child porn, or even porn in > general, that either have nothing to do with Tor's foundational > mission, or (like child porn) are antithetical to it--the result would > be greater public support for the technology, and a wider deployment > base. > > It's worth discussion. > > Jon > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

Re: [tor-relays] Store key files in RAM
by tor＠t-3.net 27 Aug '13

27 Aug '13

If you can execute shell commands directly from the ram folder (ssh, sftp) and therefore pull files straight into it with sftp, this seems exactly right. It sounds like you'll only need the secure connection on an occasional/rare basis. Imo don't try for an always-on connection for that such as a vpn. Whichever way you do, you'll want to pay attention to where the important encryption keys reside. At least in general (and maybe even specifically), we know that encrypted data is being snatched off the wire and retained. In the case of sshd, you would want your sshd daemon keys to live on the machine with the more-secure storage medium and use the vserver as the client. For a vpn or similar you'd need to look at exactly how it works and decide if there is a right way and if so, what it is. Hopefully the only thing you feel there is a need to protect from is improper read access. If someone can write to your vserver as root, that would be a Very Bad Thing (TM). Sorry about the strange/disjointed line feeds in my first email btw, not sure why that happens. I'm trying short lines now, seeing if it works better. If you add linefeeds to what I wrote before where it makes sense, it may be easier to read. On Tuesday 27/08/2013 at 12:38 am, Tony Xue wrote: > > > Thanks for the instructions. > So what if I set up an L2TP VPN connection from my server to my > computer at home which stores the keys and I download the file > directly into the RAM folder? > > The purpose is to avoid storing the file or let the file passing > through the local normal storage system on my vserver which could be > extremely insecure in this situation. > > So will any of these techniques you have described or I stated above > let my data passing through the local ROM storage system of the > vserver? > > > >> >> >> Date: Tue, 27 Aug 2013 00:14:36 -0400 >> From: tor(a)t-3.net >> To: <tor-relays(a)lists.torproject.org> >> Subject: Re: [tor-relays] Store key files in RAM >> Message-ID: <521c27ac.570.f998d700.49849df(a)t-3.net> >> Content-Type: text/plain; charset="us-ascii"; Format="flowed" >> >> IMO cut and paste in the situation you're describing is not the >> perfect way. Better way would be: >> >> Have a secure linux machine running an sshd at your home (or another >> physically-controlled location?). >> Close off iptables and ip6tables for inbound sshd except for your >> vserver's IP >> (hint: "ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_4096_key -b 4096" >> (don't put a password when it asks)) >> and edit sshd_config to point it to the new key. Also in the config, >> force your local sshd >> server to insist upon only using these 2 ciphers ("Ciphers >> aes256-ctr,aes256-cbc"). >> Restart the local sshd (maybe "service sshd restart") and verify that >> you can NOT connect >> from the vserver to the home box using a different cipher (ssh -l >> someuser -c aes128-ctr your.home.ip.here). >> A test ssh connection without the "-c aes128-ctr" should work, the one >> with it should fail. >> >> You would do transfers of important files to and from the vserver via >> an 'sftp' session which you start >> from your vserver, and you are connecting into your home machine (sftp >> someuser(a)your.home.ip.here) >> Don't make the connection in the reverse direction, you can push and >> pull files with the one. And don't >> let anyone steal your ssh_host_rsa_4096_key off the home box. (could >> even shred/delete/regenerate it >> now and then). In general, turn off the home sshd when you aren't >> using it. >> >> The above setup should be pretty good in terms of the network transfer >> if the data hasn't already been >> compromised, of course. The certainty that it hasn't been is not >> necessarily guaranteed if it's already >> been thrown through a network card in a less-solid way, such as the >> contents having been viewed >> via 'cat', 'nano', etc. via a connection in the 'wrong' direction. >> >> If you are deleting files from your vserver's hard drive after copying >> them out for backup, try doing >> "shred" on the file first, and then "rm". It may help do the deletion >> better, depending upon how your vserver >> hosting is set up. >> >> >> >> >> >> On Monday 26/08/2013 at 10:53 pm, Tony Xue wrote: >>> >>> >>> >>> >>> >>> >>> Hi, >>> >>> I have been discovering simple and secure way of protecting the Tor >> > key files recently, in order to achieve the safety of the keys on >> VPS. >>> >> > So I created a folder on Linux called /tor and it is stored in the >> RAM >>> file system. I put my key file into that folder and link it back to >>> the data directory folder of Tor. I also backed up the key files in >> > case my server need to be restarted and the RAM would be cleaned up. >> I >>> left the key in RAM for some undesired failures, errors or >>> configuration which need to restart the Tor software. >>> >> > If the server gets down, I would probably do the simple cut and >> paste >> > in the SSH client to restore my key files. Or in a higher level way >> if >>> cut&paste is not safe enough. >>> >> > I am not sure whether this is a good way to protect my key files on >> a >>> VPS. Does anyone have any comment on that or a better way? >>> >>> >>> Tony >>> _______________________________________________ >>> tor-relays mailing list >>> tor-relays(a)lists.torproject.org >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>> >> > > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >

1 0

Re: [tor-relays] What if my favorite online store websiteblacklists all Tor Relay IP addresses?
by tor＠t-3.net 27 Aug '13

27 Aug '13

Likely someone was doing credit card fraud/hacking type stuff and choosing Tor as the way to connect for it. That stuff is a pain in the ass for online stores when it happens. Not surprised that outfits handling online payments don't want Tor connections, and I can't blame them tbh. It shouldn't be hard to find a workaround if your purchases are infrequent and anonymity in that particular connection isn't an issue (cell phones have internet these days, 'net from a friend's house, whatever). Not sure where you live but, I read that these days, USA is photographing the fronts of all postal mail. So, mailed merchandise isn't exactly a win on privacy anyway. On Sunday 25/08/2013 at 4:23 pm, David Carlson wrote: > > > On 8/25/2013 2:41 PM, Dave Lahr wrote: > >> >> I'm in the same boat: for example yelp.com and TDBank North >> are blocking us. >> >> >> On Sun, Aug 25, 2013 at 2:30 PM, David Carlson >> <david.carlson.417(a)gmail.com> wrote: >> >>> It seems that at least two 'normal' online store websites >>> that I visit >>> from time to time have apparently decided to block my IP >>> address which I >>> am also using for a non-exit Tor relay. I have had extended >>> discussions >>> with one of them and they considered unblocking my IP >>> address to be a >>> risk greater than the lost income (US $160/year revenue) was >>> worth. >>> They suggested switching to a different IP address, which >>> was like >>> pulling hens' teeth from my ISP. To do that, I had to have >>> a technician >>> visit my house and install a new modem because they do not >>> have a person >>> who understands tech talk available for ordinary users, and >>> I couldn't >>> get sufficiently elevated in their support hierarchy. The >>> supposedly >>> dynamic IP address that I get from them hardly ever changes, >>> probably >>> because I am buying U-verse television service from them. >>> Now, after a couple of months, the "new" IP address is also >>> blocked. >>> >>> My question is this. What if it becomes common practice for >>> commercial >>> entities such as online stores to block all IP addresses >>> that they find >>> on lists of Tor relays such as <https://www.dan.me.uk/tornodes> >>> or the >>> official Tor metrics data? >>> That list is updated every half hour, includes all nodes, >>> and is not >>> limited to exit nodes. It currently lists 4438 nodes. That >>> is a >>> manageable size for a blacklist, but it could represent tens >>> or hundreds >>> of thousands of clients. >>> >>> Wouldn't this eventually either cripple the Tor network or >>> generally >>> discourage Tor clients that can no longer buy products >>> online from store >>> XYZ through the Tor network? >>> >>> David C >>> _______________________________________________ >>> tor-relays mailing list >>> tor-relays(a)lists.torproject.org >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>> >> >> >> >> _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays In the short term, it is possible to to circumvent these practices by using one or more of several different methods, but informing the online store that they are shooting themselves in the foot is not one of them. After all, they are experts and we are just ignoramuses, even if we know what an IP address is. > Also, client tactics like going to a public hotspot is either not an > option for someone who wants the Tor anonymity, or problematic at > best if all or nearly all Tor node IP addresses are blocked at the > vendor end. > > That is why I asked the general question. > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >

5 4

efficiency and reachability
by That Guy 27 Aug '13

27 Aug '13

Please excuse any poor wording, networking is not my strong suit;) i understand my ??'s are basic but it wont take me long & I'll be sharing any knowledge I gain here. 1) have 4 extra unused devices, 2 android & 2 older laptops running Xubuntu & Lubuntu that can run full time & my 2 primary machines(android tab and Debian laptop). With only so much bandwidth, what helps best in that situation? a. fewer(1-2) devices offering more BW each, or b. more(4-7) devices each offering less BW to the network. 2) Reachability: The only way I was able to any of the relays I tried to setup to be reachable from the outside was to log into my router(D-link dir-615) & put the device in the DMZ. I don't know how to solve the issue the right way(Port-Forwarding?, etc.) or other means. I'm not worried about my extra devices as I don't use them, but, **I don't know what the security implications are to *users of a relay or bridge sitting in such a vulnerable place & to my network & the box's I do care about. Currently just left one non-exit relay in the DMZ until I can find better solution. Running great. Sorry so long & for anyone who replied to my last post, I had set up a new email and created a new keypair & not paying attention included the wrong key info. thank you all. grep(a)gmx.us -- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.10 (GNU/Linux) mQINBFIaewoBEADTG92hLWpKPhcScBe8VPqSFd+pKWgJ2318AQW1SVJlAbcEOmj7 /lwIKL5lq+cduNMfsFcVreHqGdGLRKuBEyJU0JJsjP07/qO9Iq9mZqBz8VMrtq1R 7GKabb+G+f2uDob1PQvpJmFrttMLzTQeVG0hNrzziIYACj//VZRaheiv/rh8ZBfC 3T5UgMo+Z8ClYvBrThJBLjrchMuKxu14hptcSiCTGWKK4wl7TPvFVvu1mNxIU2iJ Xp9KT+plp1OFbelRzFFH1LHqoaWcpm6ABjtS/FF1XzDFfOf4zf8WScbGm4jU5rXQ ONO90U6fTCuVjbd7Vq0P4XX4wRdpC1NKGMudpqEPAh+0dYT494EmG/yRDSyUKlrR 7MSW1oz1C14sUb4A82ypfC0yRkcrj8cS7RRSGhVIhrrSPECL+Wdt3gKOMu9EnwHW ls+WOJm5eVVG0SbV0TLgnZ723FdlFFZsZSKEVduxbq9wLZu3aCm8nh9UY+STYM5T whAJL4+v5b9zJWtY+YMcH//YWLmxgQjLrMLOKUERRfRJUsC73DRiCvbnVSMelkZk ZnLfFPkq2C1XcAi8zk5oBI0O+iIcNn/1EK9u49ngz/V1NQXj0qHYTN4EsECCihXz r3bB1KyHZmu7yoRsN5m1UPmEXiCm2amuRLMcDKff1SA20rApCbgBvWSOjQARAQAB tCdreWxlIGJ5cm5lcyAoUHJpbWFyeSBrZXkpIDxncmVwQGdteC51cz6JAj4EEwEC ACgFAlIaewoCGwMFCQlmWTYGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEGPr 8mk3uIZEsMkQAJE+TZDoHmbFx+YHrjPg7EKba5+8jtqyH7sVHETEAHZaU6U2nVAd 135lN3+g0Dgn6y/8OlncJbioleXpWyWLzpYjMBv9mPPHj+2G0jj8Lg7wk1JzN0YN frq7wNEVFJB4Ryh1OUdfU89fY9PHPPl8WuE2E82XrqF6vY5R727ji97ojODi0g6s O5ygMbwccnNIhCSnuf/vZDvc/DVsPUytlkJdk7vaAXTFpYQk++UqG8mXKtWz43PZ p9SFy6gIZ0D4DZi0xxUg79fiKvy2tNDv8nAwXBWPGZicpmTxLJ2eRoYNpIlNgnZ6 Uk0txvS3414A0MZ0x4AC/WXilx6ykNxo9Fz8rS/8LMYfQXjdivg84LevuZkFa+BY nha0Fq1HwJpwbarmyu/BcKEXEBM8RPF0Rjm3ZymXJzkQto57kkzKKeud2Ob8WhDd 6qGv5bmU78KoR3NHgQc8bV+qYSY6ng5O4BcEUwtZjy3y8vTihJkyQ3W+U9dcBm6H kbTl4dL4kvRMJsGimT6iL80YL4tQltvEWuw14I6h7Hiq4YZMky30LI3mC/D+kcK3 5/eTVF9330snVg7yxEhc5CR/oBJoIRYNz1d26wYwm2AA1yqCizWRBYoMnr+M1nyE h/4v3m2v112FRXCpe74MzaSmY3W0jFW7t+l6D0uWUMb8vKNIeAR4v1q1iQEcBBAB AgAGBQJSGnwqAAoJEL/qyBxVCbTi9EgH/RoqiM5LPuZAqHkCx4o/h3Bu1txbTpzq OsXFvyEr8YOybUznu03Z103p7VeO1aHl87IhmEzPVLWLaM9mrk+QH6D0PHecHkti +Xz6RnHHWXZNFPli0ceW/Jx6xFyQCQRSfdsfkk5xRazEeBci4Tu2QWKohfKaVMSt 0oe/C76/WxrRHuwUMgPnfzF+2GnhyGdp/nICsyuENsk1CdSeqfuGqf/onNVdbcNK Nj8/UPdbndvsttqDhWSWn3PtoOhmpQMMEOoYw8FMeXsasNEx2v0NDDb6VboLcng4 UC2Cz5xZSa3nAgoXGhDMEUA8T1nWZT6ownk86EJxL+b1h18+BcXKVUnR1zXXMwEQ AAEBAAAAAAAAAAAAAAAA/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAgGBgcGBQgH BwcJCQgKDBQNDAsLDBkSEw8UHRofHh0aHBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5 PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCACEAIkDASIAAhEBAxEB /8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUF BAQAAAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcY GRolJicoKSo0NTY3ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW 19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEAAwEBAQEBAQEBAQAAAAAAAAEC AwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSExBhJBUQdhcRMi MoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaan qKmqsrO0tba3uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6 /9oADAMBAAIRAxEAPwDg8jB6d6cfLyc4qH7JIwzuIppt2HVq6jMn3IDytN8wEFVG OajFsx/iNPFqwGS1ACkr35OKMqBhhzT/ALO3HzfpTksZpnCRKzseAqrkmkBEGXP3 celHyDr16V22l/DO9fT/AO0daluLC3/giitHnnk/7ZqMj8axtZbwzoOTLoHi+fb/ AB3MK2kbfiVJqXNIdmc/5at1zyfWgxRD1qeH4li3dbXw54U063uJmEay3Ra7lJPA A3YUH8K9C+Jmt+IPDc/hbStL07TTqt7b5ulisI5BLN8oKqCDgZz09an2iHynl7iN cgctn/CpYR/eHboK98v/AAZ4c/4RyDU/GcWn2V6kS/a7m0Jt4wx7Yzg+me/6V5v4 28MW2kS217otsraLKn7q9huTOsp9z0U+36+lKaYmrHIEgcbTmmlgGI6kkYpz7um4 UkaY+bPPU5qxBjaCSDnPApV2kknJ/Go3ZicBu/anBGA64HrQBISD0FRbl/2v1qVF IBwah2f5xSYGjvyAPaoGPzVaMQKBuhA/pVJ+DTAsxHNWLe3mu7hLe3iaWWRgqIgy WPoKqQnkV1cV7cfDG3HiHVIEW7nhdNPs3b55GIHzsB91QOvfkDvUydkCRe1xdH+F +gC61eK31HxJdJ/oti/zRw/7bjuB+p4Hc15rJ8YvG5P+j6pFaJ2S2tIkA/8AHc1y etazf+INWuNT1O4a4u523O7foAOwHQCqFYNt7mljth8XfHoOf+Ekuf8Av3H/APE1 Yj+NHj+MYOu+YPSS1hOf/Ha4GnxRSTzJDEjSSOwVEUZLE9ABSA918DT+L9f1nT9X 1rw/pL6Jta6l1BtMh3bEBPysozuyPrXoXib4i6X4a8J6N4pv9I83Ub6NRbwEBJVD Dc3zEEqBx+YrR0HRdZ8M+D9Ls7SRHktdPSD7MUyv2h2XdIx6lVy3APIz7V5L+0pL Kdb0GFjmNbaRh6biwB/kKAMDx/8AFHSfHlkUuNH1KGeNP9GAvx5Mb/3igT5j25P0 xXMeDfHN94UuHgdftujXPy3enynKSL3I/ut6EVp+F/g94s8V6Ump2cNtb2cozFJd S7fMHTIABOPrio9U+EPi/TbKW9js4L+1hLCSWxnWXaVOGGPvcYOeOMUAdT4i8PW9 pa2mu6NI13oN8N1vN/FGe8b+jAgj8K58gEHK4FX/AIOeKo4NUfwdqyfaNG1lvLCM f9VMeFYemeB9cHtWr4w8J3nhTV2t5WZ7VyWt5yOHX0PuO4raEr6Mho5pQMfKvGc5 zTs5JwnQdaUNjADcYo5J5fArQQhcBcBc1U84/wB2rZBIADcetQeV/t0gNxZYFkQT BmjyNyo20kexwf5VoHUfCMXXQNQmYf39QA/klYrHCLkZ98V3dh4P03T0HijxGUt/ D8NlBchc58+RkGVx1+9njvkDpSk0txnSaRqfh3w/8PZvEWp+HobKxVswRuwnlmzw Nu8Dqeg9ielcT4h134XfFLUIrjUNT1PRdSCCJJZ1/dkZOAeWUDk91rz34i/EW98d 6mgCfZdJtci0tB0UdNzY6tj8AOB78TWDdyz2y/8A2drv7GbzSPE1hdW5TzFedDGp XrncpYY968s8R+FdX8K3kdvqtt5fmrvhlRg8cy/3kYcEV0nw4+JWpeDL5bWXfe6J McXFm3zYB6sgPQ+3Q9/Uafxev9fuZbBJ5baXwy4M2kPaW4jiCEY2+oZRwVJpAeX1 9F/ATwBZJpMfi+/iWa7mdlswwyIlUlS/+8SCPYD3r50r2r4VfE+/sdK07wpb20c1 zHeZgV2C+fCxYvECcBXydyknB6emQD3vxN4p0nwlpL6jq90sMQB2J1eVv7qjuf8A Jr5Y1CbV/it4pvtbvp0sdLtRmW5mJ8qzhz8qj+8x7AcsTXSfHXR9Wu/iZYJveWLU Yoo7GMnhGyFZPruOT/vVhfE68t9Ea18CaO2NP0oBrt14NzdEZZ29cZwB25FAFq++ L1/pGhW3hrwc8tnplopRbu4Aa4lySSfRASTgDketZ+i614w8EaZZeMbTUle11W5l WSCVy4mdT8xkU+vPzA5+lcBXremR+EvFvwu0Pw9d+KINJ1nT5Z5FFzGwiO9ycMxA HTbyDxQBjPbR65r0Xi7whp7tJbTJeXukRnL27qwYsgHLRkjqBlc4IAxXsHh/X38X 6JZS+J5be60nxBcSwQRiMK2n3Cs2yLcOuVHDEZzxyGri9G+EeteEv+KstfFukxpY I1ws0BaRHUDJUngEEcfjWt4X1/TrDxraNJaxN4W8WMl5bJKgZLS+BwwGeAQ4x+Kn tQBxuu2CaNrt9pyv5n2aZog+MZANZ25SeRXQfEPTpLTx7q4lO3zJzKuR1VuQf1rm FgJPDV0rVGZZ3oB07dKr5X+6v50vkYPL1X8o/wB6gDdtklu7mC1gG6WZ1jRT3YnA rc+P+statong+3kP2aytlmlA6M2NiZ+gUn/gVbmm2VtYeEPCOvwWayagmq+TtXgz Au5AJ9RtGD71558crqC6+KWoeRMsoiiiifb/AAsFGV/Cspu5SOJ0PRL/AMR6zbaT pkPnXlwxEaFgo4BJJJ6AAE/hXf33h7wb8OpBB4hkfxFrygF9PtZDFbwH0kf7xPsP xFY/w0uJdIv9Z8RxD95pGmSyxMRkCV8RJ+rk/hV7QNG8OePLy4sbKz1qDW5LaW4N xPdpLB5iqWJc7AwUnjOepFZlFy1+OGraURHovh7w/p9sOkUVq2ce5DDNd54d+Jmh fFW3bwj4s0yO1uLriCSJvkaTttJ5R/Trnp3wfnIjBxUtrcy2d3DdQOUmhdZEYdQw OQfzoA6/x/8ADjVPA2oOH/0rTWfbFeRjj2Vx/C3t37VjeEPECeFvFNjrT2KXwtHL iB32gnBAOcHBBOenavUIPFWm+I9F8f6tZaC+nwz6cGvHe7aVZLh3AQhMBQc7jnr9 K8UoA9YsfiLe+Ovi34ZutYFvbWVrej7PCoGItxHVjySSq8n8hXBeL4b+DxjrC6pC 8N613I8qP1yzE/iOeD6ViglWDKSCOQR2r1XULyL4q+DYGWLf400hArqv37+3HUj+ 869SOvXHXgA8popzo0bsjqVdTgqwwQabQA4SOEKB2CnqueDXqfgy5Oq/BjxhpDt+ 8014tRtm7ocjdj0+5/49XlVdz4Oku9L8GeMNRkgdbC5sBYrKeFaZpEwo9SF3HjoB QB6xrEK/ET4baZ4us1EmpWkPlXyL1bb9/j2PzD2avMicDlQKt/BfxJf6frl7odrd mJtSt2+yq4zH9pX5k3D0IBU49fpWh4jsrO6gsvEWloYtN1VWbyev2eZTiSL6A9PY 1rTl0Ja6mHkAA7R61B5g/ufoaeAueWyOlR5T/np+laMk9e8OzpHoPhLzV3W9ob/U JB/1yBK/qa+bby7mv764vLhy888jSyMe7Mck/ma+hrE+X8PTJ/FHoGrMPruUV85V hLctHo/we1mytNdv9H1PTY76w1O2bzlfoohVpRkdx8v8qzta+JepahZz6fpWn6do OnzjbLDptuI2lX0d+pH5A034Wappel+OIDrDCOzuoZbRpicCIyKV3H25x7ZzWP4p 8Kap4R1iWw1K3dQGPlTAfJMnZlPQgj8qkZh1Na2s99dxWtrC81xM4SONBlmY8AAV Eqs7BVBLE4AA5Jr2zwxo9v8ADXT1vLiOKfxldRbooZBuXTY2HDOP75Hb8OBkmoQl N8sdxNqKuzI8Y2qeCfBFh4BtCJ9b1CZLzVfJ+Yhv+WcQx15wce2f4qdafDTSvDnh ObxJ4qe51FoJBFLpulyKfIf+7NJzt7Zx0yOtLowOkeIJvEDt9v1ZxIRcXZ3bZGGN 4A6EHp1xWN4G1y+8IeNEt9UUzaZqj/Zr+KT5kmRzjcc9SM59eo71tVw1SkryWhEK sJ6I0fCmteE9e8XaZoi+AtOhtbydYS73U0kig98lhz+FX9dk+HGi+LbvTpdF1/QL 2xuWSO8sLnf0PyuA5yARg8eta+kfDSx0v4xQtoGt2c8GmXazXNlOzJPAnXAyMOBk cg+mazNX+KE8nj7Ura68P6L4gSC9lisZp7dfMRVchcOByo9x+NYJNuyNDa1aDwzr VqJ9X+xeIHDiJ7uzBsdSjP8A01iPyuR6nH0rCuPh18PWjMyeKNWsExkpcWfnFfqU GKUeZLc3V7clGvLyVp7h1GAXY5OB6DoKcCQevHevXhlsXD3nqcEsW+b3VoZyeFPh VZus1149uruNDuaGCxdWcegODjNYnj7x1B4kjs9H0Sx/s7w7p/Ftbd3b++/v+fU8 nNdjL/wjC6M6a9o2kGziAHm27/Z7/wCZuWTtLtyMg849a898aeEW8LXtvJbXIvtI v4/PsL1RgSp6H0YdCK8urTdObg+h2wkpxUkZOg6vcaBr1jq1q2JrSZZV98HkfQjI /GvoHxbp9uvhzxL9jRVtY9Tt9RgCjACzwqGI9i2TXzbX01oF1Drf7P0l7KoN1HZr azP3IgkOzP0B/WojuNnkwRyMBeB3qv8AZnq2GB4GcetR/J/tV0Mg9ILiH4ctk436 HqaD/vsH+lfO9e/6rBczfD/SYbUbpri01CJV/vd8fU9q8ArCe5aCvRvD/wAZNc0P w5Foc9hp+q2kRxH9vjaQqvZeuCB2/KvOaKkZ6WPjFNCxltfBvha2uByk8djhkbsw 56g80mi3E97pxvruZ57q7kaWaVzlnYnGT+Vea10nhbVbr7daaSkfnLcTLFEo4IZm wMfia68FVhSqXmY14OcLI7U+1RSwxTKFljV1DAgEdCO9SSYEksQZWaKRo32sGwyn BH50gDYwRya97SS7o83VM5vx1DqWs+ILzxBIFka5KmQRKRtwoXp6cVb8LaJ9gt/t lwuLiUfKD1Rf8TXY6XYeY3mOBgfrV280tZPniGG9OxrkhhaVOrzo0niJSjysxN3f pmhnVI2ZmAVRkseg96WWF4mKsCD3qhqumT654X1WTSL2KW500q93ZLnzTDjlx6gH GQPf8eivWjShzMzp03UlZHCeIdYOrXvyH/R4srGPX1P412vgR08ZeENT8B3Tg3iB r7Rmc9JVHzxg+jD+prze3tbi7l8q2glmkxnZGhY/kKntbm/0PVYLuBpbS9tpBIjE bWRhyODXzk5ynJyluz1oxUVZFWWN4ZXilRkkRirKwwQR1Br3X4YXm/4GeKbZj/qJ 2I9gyp/UGvPfiZLDfazpesx20cE2raXDe3SxDCmZiyswHbO2uo+F84/4Vh46hJ4X 7M3/AH0zD+lStyjF81RjBHSoPO/2h+VOEa571B5X1roMz0vQ7yaHSIJnYtFpeowz jP8ACjkhx9Mqv5mvHvHWiDw5441jS1XbFDcsYh/0zb5k/wDHSK9y8E2kWqWGt6OS POu7QGEHuyHI/UivO/jFa/apPD3iJQf9PsBBOf8AptCdrZ/MflWU9ykeYUUUVmUF dt8J7Nbj4gWd3KuYNNjlv5T6CJCwP/fW2uJr03wJb/2R8LvG3iVxhpoF0u3PqZCN +PwZfyoA4G31e8tb6S6jlO+Ryzg8hsnPIr0Dw3qUGvNsRSk68uh5AHrn0rzOGGSe ZIolLO5woHc16p4dsE0KyEQw0j4aVx1J9M+gr0svdVtpfCceL5FHzO0hiWGJUQcC pM8VStrsOoyc1YllWOMtke3Nei07nnlDWBEbV1LbJCvDgcr71zvgKw03wdqF54s1 3WpY/sLbYbS2UNJebwQQQ3GPUfjkYGbV/cmeVvm+UH8zVJ40mUxyKGQjBVh1qK+G VaNm9Ub0KrpnR2k+jaT8MvGHjPwq1xp39oSxwQREhZbVxINyqwP3SHBx2HHauQsP G+neKvDV7onjmQy3kcTPpmrmPdLHIBwjkDJUn+fPYjWjh01vh9feF3mns4Zb4X6z RxedghQpTbkHHGc5NYWg2/w50G+S/wBX1fUNZeBtyWMNgYlZh0Dl25HtxXiVaM6T tJHpQnGauil8R7N9Pl8MWcqlZYtBtvMU9VZmdsf+PVsfC+Qnwj44tweWtbZ/++ZD /jXLePPFr+NfFlzrLW/2aN1WOKHdu2IowMn17/jXa/AGK1v/ABTq+k3sYktrzTm3 oSRu2yIe31NZrRlmV8ykkY5qt+9/ur+dWZAiyyDBwGIX6VBx/cNdBmbVv4hutK1C C9sX2TwNuU9j7H2I4/Guy8YaXaeMfhLqmrafsRLe4/tJIieYJMYni+nVx65Feast dr8PdQsUs/EWkayX/si6095LgL1ULgFh7hWJ/wCA1E1dFI8KorrfHfgK/wDBGpRr K63Wm3I32d7H9yZev4HBHH5VyVYlBXrPxAA8LfCvwp4QHy3dyDqd6vcFs7Qf++iP +AVyXw18PJ4m8faZYTbTbiTzplYgb0T5ioz1zgD8a6XVoR4r8Z65rXiy7TSpoJVi tdLn4lk5ARAv90Dkt0JPvTiuZpCbsrmR4R0P7PCNSuF/eyD9yp7L6/jXVA44xk0p GwgdB2x6Up9a+mo0o0oKMTx6k3OXMxY5DF8yttxyc1u31rDB8NLjxN9ojvPNeFbJ LVySSzbXRhj73fj0rBvPC2r6vpfmi4tdK0l8+fqV7MEQL3VR1Y/T6ZrHbx5p/gbR 59D8Dz3F1LMwa41a6GAWAxmGI8J1+8ef0rzcbi2pclN7bnXh8Omuaa3L1zbXNs6R 3dvLbTNGsnkzDa6q3TcvUVEvSvM11S+GoNfG6le6dizyuxZnJ65J6/jXZ6P4lt9Q 2wzhYbn/AMdf6f4VthsbGp7s9GTVw7jrHVG0pO7iuG8XpGmt/IACYlLY9ef/AK1d bqGr2OmxF5ZkaXHEaHLE/wBK87vryS/vJLmX7znOPQdhWeYVY8nItysLB83N0K9e 1fBrw6+k6FrHj27Zo0gt5YLJc4EjYwWPqM4Ue+fSvHbGzm1HULaytk3z3EqxRr6s xwB+Zr6Q+Ilza+GPCWkeCbAjbFCjT7eCVXpn3Zst+FeTFXZ2s8rOVOdw9DUPmP6i pSUwSAfzqDcPRvzroIJzytbvgiJLnxDLaSjMVxY3UUg9VML0UUpbMaIfAss3jbwH rXhnWp5JbHSYRe2TqR5kTjI2hjn5cE8Y78EV5MwwxHoaKK5yxUd4pFeNmR1OVZTg g12WnfFXxbYxJDNfx6jAnSPUYVuP/HmG79aKKAOl0vUZNV09L2WKKJ5Cx2RAhV56 DJJ/Wn6jO9rp1zPHjfHGzLnpkUUV9NBv2SfkeRJLnt5nll3qF7fspu7uefYML5sh baPQZ6Cq1FFfMnrhRRRQAUUUUAehfBOygvfippQnXcIRJMo/2lQkH8Dz+FXvFd/c an4r1O6uX3SNcOvsApwAPYACiitKe4mY/aoaKK1JP//ZiQI+BBMBAgAoBQJSGnvg AhsDBQkJZlk2BgsJCAcDAgYVCAIJCgsEFgIDAQIeAQIXgAAKCRBj6/JpN7iGRE8R D/9KemwRcbhCG2fGMGmoTKC8ig1vcmabOVYg5z6FmeR2XY/HmBRYVCa70wxXeJWa QLPYE55MlA8vFvwnxfc3Z4Q+DPkDWbIdSZS+ioWMdO5omtMP4wD6gHCnBpBrmQaH yP0CLhsJFKfVZ0c+V0N+pTezgxwI2lB6zTggM6JOK4IvvOQ9QjAvhqlu8wbq3F93 10g6ON+W6Z2Bj5lKuczfAicHLTMHafc2g9zC0XMvV2o0gqTWHGl+/f8sfBu8D8W7 xUQbkatURa+/UCkU4fv1EJ/ILIfsPuJy2H8nq8awx6iDOMJxbifZXT3pTe8Jngmi n66+7rH4iaopvH+lJTfQXXWtLv3d7cny1SdU0Zg26TxEnYy7ZX9oAagxlGl6krLh yATOyYzFQ1SRkIJA4wb4g3BHDy9bvgI+Z0X5JwTicwue1pdj3WrpSXhDd7xjldba 2JYUeRYUSCD3qsPnCeBJw5sgi74PCVf+5fa6SWFeSTliRA7cfhMsMMGD+2jBeGia pVw5ILKoi/RztWyzdX6M2VPwZLgrt7Drp0lGbi7TnouOIUlUa7NkuDS9zgYoK1kP xpKOPZLa/m4B0hPxfcKJg80YkYgJhGeqVBh1jLiawPKHRlTDNCXx98iOSuO8GOym 0YdZQJuqoiJXug0CeR7kz5qQZtseP3C58vwg5DzozjgIDLkCDQRSGnsKARAAsl9R VFbiFepi0pV+/ye7YiQst77aUomCvhsXzJGxQAGLCqBs5zE/a1hIJpXXP+4VDZCW ku5YSkZZkyzjGdjgUAcqHZxLTJ9eOwJDrjsWfr79zNlrNALj8npIzRuqr0GGCBU0 ZttfbRSWaKIMfJMXlHJ7c/9y3DhDLpDbwieFp1B4r6AF0L1BFCMPt+MtzoJZZ7hy 7IlQXouWK/luSQOzi7K1h+MDs9vFMxsf0IvGWNcpig2hiD7J0SAS47Lf7M16e2/q ABVO4BnnyZpUOFOA/9AvLsq/A9178MFuKifuNzGhGACJylAGC25EwAvmbYL4oiIo Yj6yO2ggzPNSr0zzmWzSeVU8/uEOm7dRiU+sjMxUttYNQrKnbggqAd87Dd+g2tXT sEqB6RVKu6PqKT6syR9acdlMSXmNllgRQOclwshrm1aS2em8d0xFa/fF3F028uhc 3nQRkseLU1FZup3hM9850kypo3q5UgYEdZZzYfBbvNWYaHvkHvRzWYEGWS1klVlE 1X4a6/8KrLWcCLxfWikwjAgIEx5+WN6ZDcscmx62EGIhfuOj8WWxsK2h1D6Y/kc4 N3nOuyyotbAWm67mOKc+TeZmm8mGVnorbq0s1GpEuHDM4c4+QioDPdy/AANsJJn0 E+AJN3AQK/jNom9X6Nhc4V8oo7u8Dp+vUS+87hEAEQEAAYkCJQQYAQIADwUCUhp7 CgIbDAUJCWZZNgAKCRBj6/JpN7iGRKdhEACR2GhG4ZGYQ0nFCI2KaNm3Ys2KmpGr n2QvzT0jLEQxshCoYjJhLwuySEWUTyVxn+J3BnapR0/4YmUSSoQKgGw1WorIfn8n 2jkXduXs9Dxv1DZab3x1NVBuhCFQQ/RnFrR19up9shWkAfdzat245rANm8jxQhEb pMauMGTe8opLWV7di9j+LjY6Dc7Aqo6i25PjkbVy8CMBzXyVk3X4qflzKJpkdxLo VCzN43VxGWOaEKSY3cTC5qrMShgiRi7zhsil2h0w5oJt1D3B0hx4VWUipcf1mBUy H76m5Dy9pQYd4/5TeQsGFIUwGh37wz9zkFHpxinnCFt9FrFNbpH/H0liYZps76jN 6c9CM0EUw7waOtfeswCZGdLFKfCu1zlNfe2U16QxHOLE7v4cjKeE6zvh1xkC26Im vGON7PLFlrSkGdpTr+Zm/vjtRJNiTMCQ1S7zNhg20Ee/0jLYY85qFiqqyAKKaANR 4hvMWK0cQLI1xL73DCtnjObUc2bDG0hZVUCMkjIPCwVseh8p7acRzQnELh+FUHWU EjI1FpFO5Lan551byPMz23E+LQQvXlHrtfI/TQz2Y5hieps7Pxpc1o+5QPpNu+9+ 9tcQkdANJo0rhky387RTrdu6Oyh4Mib1YphkPCb2vnJpmjjOBkMgiBHVt77BhgD6 LmV01hrApV+zGg== =r/sW -----END PGP PUBLIC KEY BLOCK-----

2 1

(no subject)
by Bruno Kitzis 27 Aug '13

27 Aug '13

Hello, Can you remove my email adress from your contact list? Thanks in advance.

2 1

Indiegogo campaign: 3771 Euro for Exits and Bridges!
by Moritz Bartl 27 Aug '13

27 Aug '13

Hi! The torservers.net Indiegogo campaign has ended today, and yields 3771.84 Euro to be spread equally across our current seven organizations. Each organization can hand in receipts and get reimbursed, or, alternatively, we can transfer their share up front. I will mail out stickers and posters today and tomorrow to everyone who donated. Within the week, I'll put up the donation website that lists everyone who donated and wanted to be publicly mentioned. Thank you! [ http://www.indiegogo.com/projects/tor-anti-censorship-and-anonymity-infrast… ] -- Moritz Bartl https://www.torservers.net/

1 0

Re: [tor-relays] Store key files in RAM
by Tony Xue 27 Aug '13

27 Aug '13

Thanks for the instructions. So what if I set up an L2TP VPN connection from my server to my computer at home which stores the keys and I download the file directly into the RAM folder? The purpose is to avoid storing the file or let the file passing through the local normal storage system on my vserver which could be extremely insecure in this situation. So will any of these techniques you have described or I stated above let my data passing through the local ROM storage system of the vserver? > Date: Tue, 27 Aug 2013 00:14:36 -0400 > From: tor(a)t-3.net > To: <tor-relays(a)lists.torproject.org> > Subject: Re: [tor-relays] Store key files in RAM > Message-ID: <521c27ac.570.f998d700.49849df(a)t-3.net> > Content-Type: text/plain; charset="us-ascii"; Format="flowed" > > IMO cut and paste in the situation you're describing is not the > perfect way. Better way would be: > > Have a secure linux machine running an sshd at your home (or another > physically-controlled location?). > Close off iptables and ip6tables for inbound sshd except for your > vserver's IP > (hint: "ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_4096_key -b 4096" > (don't put a password when it asks)) > and edit sshd_config to point it to the new key. Also in the config, > force your local sshd > server to insist upon only using these 2 ciphers ("Ciphers > aes256-ctr,aes256-cbc"). > Restart the local sshd (maybe "service sshd restart") and verify that > you can NOT connect > from the vserver to the home box using a different cipher (ssh -l > someuser -c aes128-ctr your.home.ip.here). > A test ssh connection without the "-c aes128-ctr" should work, the one > with it should fail. > > You would do transfers of important files to and from the vserver via > an 'sftp' session which you start > from your vserver, and you are connecting into your home machine (sftp > someuser(a)your.home.ip.here) > Don't make the connection in the reverse direction, you can push and > pull files with the one. And don't > let anyone steal your ssh_host_rsa_4096_key off the home box. (could > even shred/delete/regenerate it > now and then). In general, turn off the home sshd when you aren't > using it. > > The above setup should be pretty good in terms of the network transfer > if the data hasn't already been > compromised, of course. The certainty that it hasn't been is not > necessarily guaranteed if it's already > been thrown through a network card in a less-solid way, such as the > contents having been viewed > via 'cat', 'nano', etc. via a connection in the 'wrong' direction. > > If you are deleting files from your vserver's hard drive after copying > them out for backup, try doing > "shred" on the file first, and then "rm". It may help do the deletion > better, depending upon how your vserver > hosting is set up. > > > > > > On Monday 26/08/2013 at 10:53 pm, Tony Xue wrote: > > > > > > > > > > > > > > Hi, > > > > I have been discovering simple and secure way of protecting the Tor > > key files recently, in order to achieve the safety of the keys on VPS. > > > > So I created a folder on Linux called /tor and it is stored in the RAM > > file system. I put my key file into that folder and link it back to > > the data directory folder of Tor. I also backed up the key files in > > case my server need to be restarted and the RAM would be cleaned up. I > > left the key in RAM for some undesired failures, errors or > > configuration which need to restart the Tor software. > > > > If the server gets down, I would probably do the simple cut and paste > > in the SSH client to restore my key files. Or in a higher level way if > > cut&paste is not safe enough. > > > > I am not sure whether this is a good way to protect my key files on a > > VPS. Does anyone have any comment on that or a better way? > > > > > > Tony > > _______________________________________________ > > tor-relays mailing list > > tor-relays(a)lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays > > > >

1 0

Re: [tor-relays] Store key files in RAM
by tor＠t-3.net 27 Aug '13

27 Aug '13

IMO cut and paste in the situation you're describing is not the perfect way. Better way would be: Have a secure linux machine running an sshd at your home (or another physically-controlled location?). Close off iptables and ip6tables for inbound sshd except for your vserver's IP (hint: "ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_4096_key -b 4096" (don't put a password when it asks)) and edit sshd_config to point it to the new key. Also in the config, force your local sshd server to insist upon only using these 2 ciphers ("Ciphers aes256-ctr,aes256-cbc"). Restart the local sshd (maybe "service sshd restart") and verify that you can NOT connect from the vserver to the home box using a different cipher (ssh -l someuser -c aes128-ctr your.home.ip.here). A test ssh connection without the "-c aes128-ctr" should work, the one with it should fail. You would do transfers of important files to and from the vserver via an 'sftp' session which you start from your vserver, and you are connecting into your home machine (sftp someuser(a)your.home.ip.here) Don't make the connection in the reverse direction, you can push and pull files with the one. And don't let anyone steal your ssh_host_rsa_4096_key off the home box. (could even shred/delete/regenerate it now and then). In general, turn off the home sshd when you aren't using it. The above setup should be pretty good in terms of the network transfer if the data hasn't already been compromised, of course. The certainty that it hasn't been is not necessarily guaranteed if it's already been thrown through a network card in a less-solid way, such as the contents having been viewed via 'cat', 'nano', etc. via a connection in the 'wrong' direction. If you are deleting files from your vserver's hard drive after copying them out for backup, try doing "shred" on the file first, and then "rm". It may help do the deletion better, depending upon how your vserver hosting is set up. On Monday 26/08/2013 at 10:53 pm, Tony Xue wrote: > > > > > > > Hi, > > I have been discovering simple and secure way of protecting the Tor > key files recently, in order to achieve the safety of the keys on VPS. > > So I created a folder on Linux called /tor and it is stored in the RAM > file system. I put my key file into that folder and link it back to > the data directory folder of Tor. I also backed up the key files in > case my server need to be restarted and the RAM would be cleaned up. I > left the key in RAM for some undesired failures, errors or > configuration which need to restart the Tor software. > > If the server gets down, I would probably do the simple cut and paste > in the SSH client to restore my key files. Or in a higher level way if > cut&paste is not safe enough. > > I am not sure whether this is a good way to protect my key files on a > VPS. Does anyone have any comment on that or a better way? > > > Tony > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >

1 0

Store key files in RAM
by Tony Xue 27 Aug '13

27 Aug '13

Hi, I have been discovering simple and secure way of protecting the Tor key files recently, in order to achieve the safety of the keys on VPS. So I created a folder on Linux called /tor and it is stored in the RAM file system. I put my key file into that folder and link it back to the data directory folder of Tor. I also backed up the key files in case my server need to be restarted and the RAM would be cleaned up. I left the key in RAM for some undesired failures, errors or configuration which need to restart the Tor software. If the server gets down, I would probably do the simple cut and paste in the SSH client to restore my key files. Or in a higher level way if cut&paste is not safe enough. I am not sure whether this is a good way to protect my key files on a VPS. Does anyone have any comment on that or a better way? Tony

1 0

What if my favorite online store website blacklists all Tor Relay IP addresses?
by David Carlson 25 Aug '13

25 Aug '13

It seems that at least two 'normal' online store websites that I visit from time to time have apparently decided to block my IP address which I am also using for a non-exit Tor relay. I have had extended discussions with one of them and they considered unblocking my IP address to be a risk greater than the lost income (US $160/year revenue) was worth. They suggested switching to a different IP address, which was like pulling hens' teeth from my ISP. To do that, I had to have a technician visit my house and install a new modem because they do not have a person who understands tech talk available for ordinary users, and I couldn't get sufficiently elevated in their support hierarchy. The supposedly dynamic IP address that I get from them hardly ever changes, probably because I am buying U-verse television service from them. Now, after a couple of months, the "new" IP address is also blocked. My question is this. What if it becomes common practice for commercial entities such as online stores to block all IP addresses that they find on lists of Tor relays such as <https://www.dan.me.uk/tornodes> or the official Tor metrics data? That list is updated every half hour, includes all nodes, and is not limited to exit nodes. It currently lists 4438 nodes. That is a manageable size for a blacklist, but it could represent tens or hundreds of thousands of clients. Wouldn't this eventually either cripple the Tor network or generally discourage Tor clients that can no longer buy products online from store XYZ through the Tor network? David C

2 2

help with relay and bridges
by That Guy 25 Aug '13

25 Aug '13

Hello all, been feeling helpless and have decided to at the least get a few relay's and bridges up and running and hopefuly learn enough in the process to help/teach others to do the same. Although for many it is a simple task, for many many more who would like to help it is no easy task and there is lots of uncertanty and questions if one does managage to get a relay up when they are not sure what they are doing. I understand these are elementary issues and that is why as a non-programmer of Security expert I would like to help where and when I can and with a little help from some or even one of you I hope that I can help others while taking some strain off the real minds. Many others like me exist and want to help. I am asking for someone to help me help others. Thank you grep(a)gmx.us -- -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.10 (GNU/Linux) mQENBFFn+3IBCAD0cqkxl7t+5Kychbzqaf/Wn8z3B5UCQYZk77I1sZj5sZCNhoCw bne6Q2L6SAk/K81C6ih0X1quTiCX65XmyEzjADX61CMMqwot4DZpt0Iahsp3JQbV zGryYn4fLjOO1r3pPg100luD2C37oNfOZmUhvHgtyLMTpCGBD3O8LF7p7/POLraH uYcFx0oXN5+P2xrp0MxJazxgRpKNW+00Q5t3vyzejF9z8zaw/yOrcip/5Bz8kYwh +dTjxudmV9R/bKhyRrtLaIfdM4UyvAIgGAL224kRBT+YfNouKEWRqA55HSTdKFnt sqlbV4bJ9vzZwFKiyG/r2L0eJtAaYuJLHBRrABEBAAG0GWsgPHJpZ2h0Y29hc3Q3 N0BodXNoLmNvbT6JAT4EEwECACgFAlFn+3ICGyMFCQlmAYAGCwkIBwMCBhUIAgkK CwQWAgMBAh4BAheAAAoJEL/qyBxVCbTig6sIAKIo00P0XH5a/JrBEkiqU4cE9z2F GAGBs3xKO1gFbkyM6AG/8bqSlKmUqYcuZ64kQFXDidXATtyhJCK8gH/AdRv1jEIh FmZZDK2Y94lkdxiN4MVvjTOM+Lmze+C6hM7UZY+sq2ZeVfkA5kbqgPCMB5XJu0Ff xuUBFoicXDy4eegAQEP7VGep/Uxc3q40SJWeF08TNx5GliA8TNAR8hPs4C41oicF qoXiAyG9JKJlBSS02H6zHQGK/S5ma5xYPjh+GCLiRA+UjuHQa+fBoTPVTR0w63h1 iHZA44SZYffi6NfKEvmGz0WwsvxmyM78B4oKtqNseCtAGc2mEusfVrJkY8e5AQ0E UWf7cgEIAMSh0dg9JY8VDPyRSzJCoghYrjAbbY67i7JdxTtqUvR4CV7jg5Oy1OWi fTAgwMFL/seVihozUYA+0justddC5wDJK6YvULDBh43dCrZyUMLMjtHodtORAcXM uQm67MWYX1E5HH+x0nVIbP1O7GjjWzu7EkGqnqpBr+DI/tfVbfDKL6xjRoE3rO7h Tl9i7sc7QIcRiK3ZP6S2Agr8W5nCQxNXSFSh1chMdxAedkRNEbzyU3wnU+aUw4VU FJ1FNNiCXs1X7miAUrGnDdqN3C+cg4QIaE9UIjawIkSRlCPxUkelY5ceTiN1+vLz /EJc4LnaWd8jBw8Myx5F0Egi7qD7adkAEQEAAYkBJQQYAQIADwUCUWf7cgIbDAUJ CWYBgAAKCRC/6sgcVQm04gYuCADXra9mbW+vNRWV0toEfKXRzsZ9nL4Vwp3Dys6I Hn8T1wq7DyS9N/8gan6lms8AyvNyp3vC6WZdYPnVk70YCKn1pEztyyL0YzN8WUqZ 8hBoDDKDmOS65DerGj5Fppbg1J5HEQfV1onkMKnT5KKW590Mr0EpTda28N2WUS8Q gwk7cqJ8HC033LEd16mA4FS3aZmRM5QfwkdvKb+hc29+TvrmuLIQ4yJuFQUVyoTt lfq1iY6N3PBOnBSeCSz4Ky3buxiilU9g158r7KKu0FqDMr1bhlRUR9aydSzyKSwd sQS78U81FmwMXXfLJc2TWSEgtqKQJJHbYq2jj6C8qtrs2hSg =tYo4 -----END PGP PUBLIC KEY BLOCK-----

2 1

Increase of number of new relays and exit nodes
by Jon 22 Aug '13

22 Aug '13

I am wondering with the increase of number of new relays and exit nodes how this might be affecting the other ( non- new ) relays and exits? I have noticed over the past several months that the amount my exit relay was being used has drastically dropped as the new relays and new exits have come online. Is this normal to see my usage drop noticeably? Is this going to be a continuing trend as new relays and exits join with what we already have, that some relays / exits will see a lower usage from their nodes? Jon

2 3

Re: [tor-relays] [tor-talk] obfsproxy failure: obfs3
by lee colleton 22 Aug '13

22 Aug '13

here's that email again in plain text (previously held for moderation due to message size) On Thu, Aug 22, 2013 at 3:13 AM, lee colleton <lee(a)colleton.net> wrote: > > here's both "netstat - tulpen" and "netstat -tulpen" > > lee@tor-bootstrap:~$ netstat - tulpen > Active Internet connections (w/o servers) > Proto Recv-Q Send-Q Local Address Foreign Address State > tcp 0 256 tor-bootstrap.c.tor:ssh li388-156.members:39392 ESTABLISHED > tcp 0 0 tor-bootstrap.c.t:45903 grn-it.gnuradionet:9001 ESTABLISHED > tcp 0 0 tor-bootstrap.c.t:48994 torproxy02.teamcym:9001 ESTABLISHED > tcp 0 0 tor-bootstrap.c.t:46128 xray275.server4you:9001 TIME_WAIT > tcp 0 0 tor-bootstrap.c.t:47652 metadata.google.in:http TIME_WAIT > tcp 0 0 tor-bootstrap.c.t:47654 metadata.google.in:http ESTABLISHED > tcp 0 48 tor-bootstrap.c.tor:ssh li388-156.members:34711 ESTABLISHED > tcp 0 0 tor-bootstrap.c.t:41250 metadata.google.in:http ESTABLISHED > tcp 0 0 tor-bootstrap.c.t:56064 static.68.158.9.5.:9001 ESTABLISHED > Active UNIX domain sockets (w/o servers) > Proto RefCnt Flags Type State I-Node Path > unix 2 [ ] DGRAM 283 @google-simple-watchdog > unix 8 [ ] DGRAM 2235 /dev/log > unix 3 [ ] STREAM CONNECTED 1765015 > unix 3 [ ] STREAM CONNECTED 1765014 > unix 2 [ ] DGRAM 1765013 > unix 3 [ ] STREAM CONNECTED 1735417 > unix 3 [ ] STREAM CONNECTED 1735416 > unix 3 [ ] STREAM CONNECTED 17047 /var/run/tor/control > unix 3 [ ] STREAM CONNECTED 17046 > unix 2 [ ] DGRAM 17019 > unix 2 [ ] DGRAM 17016 > unix 3 [ ] STREAM CONNECTED 16926 > unix 3 [ ] STREAM CONNECTED 16925 > unix 3 [ ] STREAM CONNECTED 6135 > unix 3 [ ] STREAM CONNECTED 6134 > unix 2 [ ] DGRAM 6133 > unix 2 [ ] DGRAM 2658 > unix 2 [ ] DGRAM 2541 > unix 2 [ ] DGRAM 2479 > unix 3 [ ] DGRAM 553 > unix 3 [ ] DGRAM 552 > lee@tor-bootstrap:~$ netstat -tulpen > (No info could be read for "-p": geteuid()=1000 but you should be root.) > Active Internet connections (only servers) > Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name > tcp 0 0 0.0.0.0:40872 0.0.0.0:* LISTEN 103 16963 - > tcp 0 0 0.0.0.0:9001 0.0.0.0:* LISTEN 0 16931 - > tcp 0 0 0.0.0.0:52176 0.0.0.0:* LISTEN 103 16970 - > tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 0 2727 - > tcp6 0 0 :::22 :::* LISTEN 0 2729 - > udp 0 0 0.0.0.0:68 0.0.0.0:* 0 2108 - > udp 0 0 0.0.0.0:55889 0.0.0.0:* 0 2086 - > udp 0 0 10.240.245.45:123 0.0.0.0:* 0 2674 - > udp 0 0 127.0.0.1:123 0.0.0.0:* 0 2673 - > udp 0 0 0.0.0.0:123 0.0.0.0:* 0 2666 - > udp6 0 0 :::123 :::* 0 2667 - > udp6 0 0 :::55026 :::* 0 2087 - > lee@tor-bootstrap:~$ > > > > On Thu, Aug 22, 2013 at 3:02 AM, Admin <webmaster(a)afo-tm.org> wrote: >> >> Looks like nothing does listen on port 443 can you post the output of "netstat - tulpen"? >> >> Am 22.08.2013 00:42 schrieb "lee colleton" <lee(a)colleton.net>: >>> >>> I'm still having trouble connecting to my obfsproxy bridge; Any pointers would be appreciated. External scanning indicates that the correct ports are open except for port 443 but it's definitely open on the firewall. >>> >>> lee@li388-156:~$ nmap -p 22,443,9001,40872,52176 173.255.119.202 >>> >>> Starting Nmap 5.21 ( http://nmap.org ) at 2013-08-21 16:44 EDT >>> Nmap scan report for 202.119.255.173.bc.googleusercontent.com (173.255.119.202) >>> Host is up (0.16s latency). >>> PORT STATE SERVICE >>> 22/tcp open ssh >>> 443/tcp closed https >>> 9001/tcp open tor-orport >>> 40872/tcp open unknown >>> 52176/tcp open unknown >>> >>> lee@li388-156:~$ openssl s_client -showcerts -connect 173.255.119.202:443 >>> connect: Connection refused >>> connect:errno=111 >>> >>> maybe this? https://trac.torproject.org/projects/tor/ticket/5104 >>> >>> Confirming that 443 is accessible: >>> >>> lee@tor-bootstrap:~$ sudo python -m SimpleHTTPServer 443 >>> >>> Serving HTTP on 0.0.0.0 port 443 ... >>> 106.187.45.156 - - [21/Aug/2013 22:39:16] code 400, message Bad request syntax ('\x16\x03\x01\x00\xdc\x01\x00\x00\xd8\x03\x02R\x15A\x94\xc5\xfc\xc1(\x04O\xe0\xee@\x92d\x17.\xd9N\xa1Q\xb3$_\xa6H\xc6adp\xa11\x00\x00f\xc0\x14\xc0') >>> 106.187.45.156 - - [21/Aug/2013 22:39:16] " � � R A��( O��@�d .�N�Q�$_�H�adp�1f� �" 400 - >>> >>> lee@li388-156:~$ openssl s_client -showcerts -connect 173.255.119.202:443 >>> CONNECTED(00000003) >>> 140181545842336:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:749: >>> --- >>> no peer certificate available >>> --- >>> No client certificate CA names sent >>> --- >>> SSL handshake has read 7 bytes and written 225 bytes >>> --- >>> New, (NONE), Cipher is (NONE) >>> Secure Renegotiation IS NOT supported >>> Compression: NONE >>> Expansion: NONE >>> --- >>> >>> >>> >>> >>> On Thu, Aug 15, 2013 at 10:14 AM, lee colleton <lee(a)colleton.net> wrote: >>>> >>>> -tor-relay >>>> +tor-relays >>>> >>>> >>>> On Thu, Aug 15, 2013 at 10:13 AM, lee colleton <lee(a)colleton.net> wrote: >>>>> >>>>> All of the ports respond on the external IP except for 443 but I can connect via SSL on 9001. I don't understand how ORListenAddress is supposed to work: my bridge times out on 443 but when I comment out the ORListenAddress line it doesn't connect via obfsproxy at all. >>>>> >>>>> Please advise. >>>>> >>>>> >>>>> On Thu, Aug 15, 2013 at 1:47 AM, lee colleton <lee(a)colleton.net> wrote: >>>>>> >>>>>> With the ORListenAddress line uncommented, a slightly different failure results: >>>>>> >>>>>> Orbot is starting… >>>>>> Orbot is starting… >>>>>> got tor proc id: 28490 >>>>>> Tor process id=28490 >>>>>> >>>>>> Connecting to control port: 9051 >>>>>> SUCCESS connected to control port >>>>>> SUCCESS authenticated to control port >>>>>> Starting Tor client… complete. >>>>>> adding control port event handler >>>>>> SUCCESS added control port event handler >>>>>> Starting privoxy process >>>>>> /data/data/org.torproject.android/app_bin/privoxy /data/data/org.torproject.android/app_bin/privoxy.config & >>>>>> NOTICE: Heartbeat: Tor's uptime is 0:00 hours, with 0 circuits open. I've sent 0 kB and received 0 kB. >>>>>> Privoxy is running on port:8118 >>>>>> Privoxy process id=28508 >>>>>> >>>>>> Network connectivity is good. Waking Tor up... >>>>>> Circuit (1) LAUNCHED: >>>>>> NOTICE: Bootstrapped 5%: Connecting to directory server. >>>>>> orConnStatus (173.255.119.202:443): LAUNCHED >>>>>> NOTICE: Bootstrapped 10%: Finishing handshake with directory server. >>>>>> Circuit (1) FAILED: ONEHOP_TUNNEL > IS_INTERNAL > NEED_CAPACITY >>>>>> NOTICE: Your application (using socks4a to port 443) instructed Tor to take care of the DNS resolution itself if necessary. This is good. >>>>>> NOTICE: Your application (using socks4a to port 80) instructed Tor to take care of the DNS resolution itself if necessary. This is good. >>>>>> NOTICE: Your application (using socks4a to port 443) instructed Tor to take care of the DNS resolution itself if necessary. This is good. >>>>>> NOTICE: Your application (using socks4a to port 80) instructed Tor to take care of the DNS resolution itself if necessary. This is good. >>>>>> NOTICE: Your application (using socks4a to port 443) instructed Tor to take care of the DNS resolution itself if necessary. This is good. >>>>>> NOTICE: Your application (using socks4a to port 80) instructed Tor to take care of the DNS resolution itself if necessary. This is good. >>>>>> NOTICE: Your application (using socks4a to port 443) instructed Tor to take care of the DNS resolution itself if necessary. This is good. >>>>>> NOTICE: Tried for 120 seconds to get a connection to [scrubbed]:443. Giving up. (waiting for circuit) >>>>>> NOTICE: Your application (using socks4a to port 443) instructed Tor to take care of the DNS resolution itself if necessary. This is good. >>>>>> >>>>>> On Aug 15, 2013 1:41 AM, "lee colleton" <lee(a)colleton.net> wrote: >>>>>>> >>>>>>> When I attempt to connect to this bridge, I see a failure in handshaking: >>>>>>> >>>>>>> Orbot is starting… >>>>>>> Orbot is starting… >>>>>>> got tor proc id: 27365 >>>>>>> Tor process id=27365 >>>>>>> Connecting to control port: 9051 >>>>>>> SUCCESS connected to control port >>>>>>> SUCCESS authenticated to control port >>>>>>> Starting Tor client… complete. >>>>>>> adding control port event handler >>>>>>> SUCCESS added control port event handler >>>>>>> Starting privoxy process >>>>>>> /data/data/org.torproject.android/app_bin/privoxy /data/data/org.torproject.android/app_bin/privoxy.config & >>>>>>> NOTICE: Heartbeat: Tor's uptime is 0:00 hours, with 0 circuits open. I've sent 0 kB and received 0 kB. >>>>>>> Privoxy is running on port:8118 >>>>>>> Privoxy process id=27393 >>>>>>> Network connectivity is good. Waking Tor up... >>>>>>> Circuit (1) LAUNCHED: >>>>>>> NOTICE: Bootstrapped 5%: Connecting to directory server. >>>>>>> orConnStatus (173.255.119.202:443): LAUNCHED >>>>>>> NOTICE: Bootstrapped 10%: Finishing handshake with directory server. >>>>>>> NOTICE: We weren't able to find support for all of the TLS ciphersuites that we wanted to advertise. This won't hurt security, but it might make your Tor (if run as a client) more easy for censors to block. >>>>>>> NOTICE: To correct this, use a more recent OpenSSL, built without disabling any secure ciphers or features. >>>>>>> Circuit (1) FAILED: ONEHOP_TUNNEL > IS_INTERNAL > NEED_CAPACITY >>>>>>> orConnStatus (173.255.119.202:443): FAILED >>>>>>> WARN: Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (DONE; DONE; count 1; recommendation warn) >>>>>>> WARN: 1 connections have failed: >>>>>>> WARN: 1 connections died in state handshaking (TLS) with SSL state SSLv2/v3 read server hello A in HANDSHAKE >>>>>>> NOTICE: Your application (using socks4a to port 80) instructed Tor to take care of the DNS resolution itself if necessary. This is good. >>>>>>> NOTICE: Your application (using socks4a to port 443) instructed Tor to take care of the DNS resolution itself if necessary. This is good. >>>>>>> NOTICE: Your application (using socks4a to port 80) instructed Tor to take care of the DNS resolution itself if necessary. This is good. >>>>>>> >>>>>>> On Aug 15, 2013 12:31 AM, "lee colleton" <lee(a)colleton.net> wrote: >>>>>>>> >>>>>>>> When I comment out the ORListenAddress line things look OK. >>>>>>>> >>>>>>>> # Listen on a port other than the one advertised in ORPort (that is, >>>>>>>> # advertise 443 but bind to 9001). >>>>>>>> #ORListenAddress 0.0.0.0:9001 >>>>>>>> >>>>>>>> Aug 15 06:52:50.000 [notice] Tor 0.2.4.16-rc (git-dcf6b6d7dda9ffbd) opening log file. >>>>>>>> Aug 15 06:52:50.000 [notice] We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently lacks accelerated support for the NIST P-224 and P-256 groups. Building openssl with such support (using the enable-ec_nistp_64_gcc_128 option when configuring it) would make ECDH much faster. >>>>>>>> Aug 15 06:52:50.000 [notice] Your Tor server's identity key fingerprint is 'gcedemo 08C752E8E86EB5916574A8625030B0EC204EABB8' >>>>>>>> Aug 15 06:52:50.000 [notice] Configured hibernation. This interval began at 2013-08-15 00:00:00; the scheduled wake-up time was 2013-08-15 00:00:00; we expect to exhaust our quota for this interval around 2013-08-16 00:00:00; the next interval begins at 2013-08-16 00:00:00 (all times local) >>>>>>>> Aug 15 06:52:50.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. >>>>>>>> Aug 15 06:52:50.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. >>>>>>>> Aug 15 06:52:50.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. >>>>>>>> Aug 15 06:52:51.000 [notice] We now have enough directory information to build circuits. >>>>>>>> Aug 15 06:52:51.000 [notice] Bootstrapped 80%: Connecting to the Tor network. >>>>>>>> Aug 15 06:52:52.000 [notice] Bootstrapped 85%: Finishing handshake with first hop. >>>>>>>> Aug 15 06:52:53.000 [notice] Guessed our IP address as 173.255.119.202 (source: 38.229.70.33). >>>>>>>> Aug 15 06:52:53.000 [notice] Bootstrapped 90%: Establishing a Tor circuit. >>>>>>>> Aug 15 06:52:53.000 [notice] Registered server transport 'obfs3' at '0.0.0.0:40872' >>>>>>>> Aug 15 06:52:53.000 [notice] Registered server transport 'obfs2' at '0.0.0.0:52176' >>>>>>>> Aug 15 06:52:55.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. >>>>>>>> Aug 15 06:52:55.000 [notice] Bootstrapped 100%: Done. >>>>>>>> Aug 15 06:52:55.000 [notice] Now checking whether ORPort 173.255.119.202:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) >>>>>>>> Aug 15 06:53:04.000 [notice] New control connection opened. >>>>>>>> Aug 15 07:10:11.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Wed, Aug 14, 2013 at 9:53 PM, lee colleton <lee(a)colleton.net> wrote: >>>>>>>>> >>>>>>>>> Yes, I've opened the ports in the Google Compute Engine (see below). I'll follow up on their forum to make sure I've altered the firewall properly. >>>>>>>>> >>>>>>>>> --lee >>>>>>>>> >>>>>>>>> lee@li388-156:~$ gcutil --service_version="v1beta15" --project="colleton.net:tor-cloud" listfirewalls >>>>>>>>> +------------------------+---------------------------------------+---------+------------+-------------+-------------+ >>>>>>>>> | name | description | network | source-ips | source-tags | target-tags | >>>>>>>>> +------------------------+---------------------------------------+---------+------------+-------------+-------------+ >>>>>>>>> | default-allow-internal | Internal traffic from default allowed | default | 10.0.0.0/8 | | | >>>>>>>>> | default-ssh | SSH allowed from anywhere | default | 0.0.0.0/0 | | | >>>>>>>>> | tor-obfsproxy | | default | 0.0.0.0/0 | | obfsproxy | >>>>>>>>> +------------------------+---------------------------------------+---------+------------+-------------+-------------+ >>>>>>>>> lee@li388-156:~$ gcutil --service_version="v1beta15" --project="colleton.net:tor-cloud" getfirewall tor-obfsproxy >>>>>>>>> +---------------+-------------------------------+ >>>>>>>>> | property | value | >>>>>>>>> +---------------+-------------------------------+ >>>>>>>>> | name | tor-obfsproxy | >>>>>>>>> | description | | >>>>>>>>> | creation-time | 2013-08-07T18:37:35.986-07:00 | >>>>>>>>> | network | default | >>>>>>>>> | source-ips | 0.0.0.0/0 | >>>>>>>>> | source-tags | | >>>>>>>>> | target-tags | obfsproxy | >>>>>>>>> | allowed | tcp: 443, 9001, 40872, 52176 | >>>>>>>>> +---------------+-------------------------------+ >>>>>>>>> lee@li388-156:~$ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Wed, Aug 14, 2013 at 9:19 PM, Roger Dingledine <arma(a)mit.edu> wrote: >>>>>>>>>> >>>>>>>>>> On Wed, Aug 14, 2013 at 09:08:03AM -0700, lee colleton wrote: >>>>>>>>>> > There's a more serious issue in that my server doesn't appear to be >>>>>>>>>> > reachable. I've opened tcp:443,9001 along with the two specifiedobfsproxy >>>>>>>>>> > ports >>>>>>>>>> > >>>>>>>>>> > Aug 14 15:26:58.000 [notice] Bootstrapped 100%: Done. >>>>>>>>>> > Aug 14 15:26:58.000 [notice] Now checking whether ORPort >>>>>>>>>> > 173.255.119.202:443 is reachable... (this may take up to 20 minutes -- >>>>>>>>>> > look for log messages indicating success) >>>>>>>>>> > Aug 14 15:28:00.000 [notice] New control connection opened. >>>>>>>>>> > Aug 14 15:46:56.000 [warn] Your server (173.255.119.202:443) has not >>>>>>>>>> > managed to confirm that its ORPort is reachable. Please check your >>>>>>>>>> > firewalls, ports, address, /etc/hosts file, etc. >>>>>>>>>> >>>>>>>>>> Well, that's because it's unreachable. (I just tried.) >>>>>>>>>> >>>>>>>>>> Can you try following the suggestion in the log message? >>>>>>>>>> >>>>>>>>>> --Roger >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> tor-talk mailing list - tor-talk(a)lists.torproject.org >>>>>>>>>> To unsusbscribe or change other settings go to >>>>>>>>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>> >>>> >>> >>> >>> _______________________________________________ >>> tor-relays mailing list >>> tor-relays(a)lists.torproject.org >>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays >>> >

1 0

Config Tor Exit Node
by var 22 Aug '13

22 Aug '13

Hi guys, we moved from a Win to Linux with our tor exit node. The win was running fine no problems since we are running the the exit node on a Debian wheezy we got in trouble. The exit node is installed and configured with the how to on the official Tor website. The exit node is directly plugged in to the gateway. Its an DIR-655 <http://support.dlink.com.tw/> which just have to run our internet traffic + the tor exit node. Here is the torrc file: > http://pastebin.com/QsZ3UJPA Problem is that when the node is running i lose my internet on every other PC around. Connection is still there but it take years to resolve the names....so i figured it must be an DNS problem. I hope you can help us. Thanks in advance VarVarna

3 2

TOR Exit Node trouble
by var 22 Aug '13

22 Aug '13

The exit node got an internal IP address...but bounds normally on the outside address. 192.168.0.5 192.168.01 88.77.66.33 Exit node -----------> Router------------> Internet But if i do a look up on different Tor service site the find the Exit node and give it the external IP address.

2 1

Re: [tor-relays] Key files encryption methods.
by tor＠t-3.net 22 Aug '13

22 Aug '13

I have something to add to this. I'm a new relay operator, but not new to server hosting in general. People should be aware that some providers of vservers run their internal operations by using a large-capacity storage box for the disk storage, and separate hardware hosts which run the cpu/memory/operationals of the vservers. The disk storage is accessed by a private network and would tend to be reached by the servers through a manageable switch. At least on Linux platform, the protocol I have seen the hosts talk to the disk box with is NFS. The core of NFS is unencrypted. In a server farm environment where one is keeping the traffic all on a private switch like that on private IP space, the operator would not tend to tunnel those host NFS connections over SSH. An operator is looking for speed and throughput in that environment, and SSH tunneling would decrease both. It is assumed that passing the traffic through the private switch isn't a meaningful security concern. What that means to tor server operators is that if you're using a vserver where the internals are set up this way, the unencrypted contents of your disk are likely being exposed to a managed switch. That switch could potentially be used to examine or redirect traffic. This is a real concern, not a theoretical one. Security procedures on the key handling should take into account this sort of situation, where it may exist. (In my case I get to choose which way I want the vserver - and with that, I'll be taking my new tor server offline for a little while for a re-implementation :/ ). On Wednesday 21/08/2013 at 7:24 am, Moritz Bartl wrote: > On 21.08.2013 11:56, Tony Xue wrote: >> >> Is that those key files are only loaded when the Tor start and reload? >> So could it be possible to decrypt the file before the start-up and >> encrypt them again after the Tor start-up process is complete? > > The files are required only on startup of the relay, so you can keep > them stored wherever (offsite, in an encrypted container, ...), and > remove them from the live system after you start Tor. > > https://trac.torproject.org/projects/tor/wiki/doc/OperationalSecurity > > -- > Moritz Bartl > https://www.torservers.net/ > _______________________________________________ > tor-relays mailing list > tor-relays(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

2 1

Re: [tor-relays] [tor-talk] obfsproxy failure: obfs3
by lee colleton 21 Aug '13

21 Aug '13

-tor-relay +tor-relays On Thu, Aug 15, 2013 at 10:13 AM, lee colleton <lee(a)colleton.net> wrote: > All of the ports respond on the external IP except for 443 but I can > connect via SSL on 9001. I don't understand how ORListenAddress is > supposed to work: my bridge times out on 443 but when I comment out the ORListenAddress > line it doesn't connect via obfsproxy at all. > > Please advise. > > > On Thu, Aug 15, 2013 at 1:47 AM, lee colleton <lee(a)colleton.net> wrote: > >> With the ORListenAddress line uncommented, a slightly different failure >> results: >> >> Orbot is starting… >> Orbot is starting… >> got tor proc id: 28490 >> Tor process id=28490 >> >> Connecting to control port: 9051 >> SUCCESS connected to control port >> SUCCESS authenticated to control port >> Starting Tor client… complete. >> adding control port event handler >> SUCCESS added control port event handler >> Starting privoxy process >> /data/data/org.torproject.android/app_bin/privoxy >> /data/data/org.torproject.android/app_bin/privoxy.config & >> NOTICE: Heartbeat: Tor's uptime is 0:00 hours, with 0 circuits open. I've >> sent 0 kB and received 0 kB. >> Privoxy is running on port:8118 >> Privoxy process id=28508 >> >> Network connectivity is good. Waking Tor up... >> Circuit (1) LAUNCHED: >> NOTICE: Bootstrapped 5%: Connecting to directory server. >> orConnStatus (173.255.119.202:443): LAUNCHED >> NOTICE: Bootstrapped 10%: Finishing handshake with directory server. >> Circuit (1) FAILED: ONEHOP_TUNNEL > IS_INTERNAL > NEED_CAPACITY >> NOTICE: Your application (using socks4a to port 443) instructed Tor to >> take care of the DNS resolution itself if necessary. This is good. >> NOTICE: Your application (using socks4a to port 80) instructed Tor to >> take care of the DNS resolution itself if necessary. This is good. >> NOTICE: Your application (using socks4a to port 443) instructed Tor to >> take care of the DNS resolution itself if necessary. This is good. >> NOTICE: Your application (using socks4a to port 80) instructed Tor to >> take care of the DNS resolution itself if necessary. This is good. >> NOTICE: Your application (using socks4a to port 443) instructed Tor to >> take care of the DNS resolution itself if necessary. This is good. >> NOTICE: Your application (using socks4a to port 80) instructed Tor to >> take care of the DNS resolution itself if necessary. This is good. >> NOTICE: Your application (using socks4a to port 443) instructed Tor to >> take care of the DNS resolution itself if necessary. This is good. >> NOTICE: Tried for 120 seconds to get a connection to [scrubbed]:443. >> Giving up. (waiting for circuit) >> NOTICE: Your application (using socks4a to port 443) instructed Tor to >> take care of the DNS resolution itself if necessary. This is good. >> >> On Aug 15, 2013 1:41 AM, "lee colleton" <lee(a)colleton.net> wrote: >> >>> When I attempt to connect to this bridge, I see a failure in handshaking: >>> >>> Orbot is starting… >>> Orbot is starting… >>> got tor proc id: 27365 >>> Tor process id=27365 >>> Connecting to control port: 9051 >>> SUCCESS connected to control port >>> SUCCESS authenticated to control port >>> Starting Tor client… complete. >>> adding control port event handler >>> SUCCESS added control port event handler >>> Starting privoxy process >>> /data/data/org.torproject.android/app_bin/privoxy >>> /data/data/org.torproject.android/app_bin/privoxy.config & >>> NOTICE: Heartbeat: Tor's uptime is 0:00 hours, with 0 circuits open. >>> I've sent 0 kB and received 0 kB. >>> Privoxy is running on port:8118 >>> Privoxy process id=27393 >>> Network connectivity is good. Waking Tor up... >>> Circuit (1) LAUNCHED: >>> NOTICE: Bootstrapped 5%: Connecting to directory server. >>> orConnStatus (173.255.119.202:443): LAUNCHED >>> NOTICE: Bootstrapped 10%: Finishing handshake with directory server. >>> NOTICE: We weren't able to find support for all of the TLS ciphersuites >>> that we wanted to advertise. This won't hurt security, but it might make >>> your Tor (if run as a client) more easy for censors to block. >>> NOTICE: To correct this, use a more recent OpenSSL, built without >>> disabling any secure ciphers or features. >>> Circuit (1) FAILED: ONEHOP_TUNNEL > IS_INTERNAL > NEED_CAPACITY >>> orConnStatus (173.255.119.202:443): FAILED >>> WARN: Problem bootstrapping. Stuck at 10%: Finishing handshake with >>> directory server. (DONE; DONE; count 1; recommendation warn) >>> WARN: 1 connections have failed: >>> WARN: 1 connections died in state handshaking (TLS) with SSL state >>> SSLv2/v3 read server hello A in HANDSHAKE >>> NOTICE: Your application (using socks4a to port 80) instructed Tor to >>> take care of the DNS resolution itself if necessary. This is good. >>> NOTICE: Your application (using socks4a to port 443) instructed Tor to >>> take care of the DNS resolution itself if necessary. This is good. >>> NOTICE: Your application (using socks4a to port 80) instructed Tor to >>> take care of the DNS resolution itself if necessary. This is good. >>> On Aug 15, 2013 12:31 AM, "lee colleton" <lee(a)colleton.net> wrote: >>> >>>> When I comment out the ORListenAddress line things look OK. >>>> >>>> # Listen on a port other than the one advertised in ORPort (that is, >>>> # advertise 443 but bind to 9001). >>>> #ORListenAddress 0.0.0.0:9001 >>>> >>>> Aug 15 06:52:50.000 [notice] Tor 0.2.4.16-rc (git-dcf6b6d7dda9ffbd) opening log file. >>>> Aug 15 06:52:50.000 [notice] We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently lacks accelerated support for the NIST P-224 and P-256 groups. Building openssl with such support (using the enable-ec_nistp_64_gcc_128 option when configuring it) would make ECDH much faster. >>>> Aug 15 06:52:50.000 [notice] Your Tor server's identity key fingerprint is 'gcedemo 08C752E8E86EB5916574A8625030B0EC204EABB8' >>>> Aug 15 06:52:50.000 [notice] Configured hibernation. This interval began at 2013-08-15 00:00:00; the scheduled wake-up time was 2013-08-15 00:00:00; we expect to exhaust our quota for this interval around 2013-08-16 00:00:00; the next interval begins at 2013-08-16 00:00:00 (all times local) >>>> Aug 15 06:52:50.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. >>>> Aug 15 06:52:50.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. >>>> Aug 15 06:52:50.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. >>>> Aug 15 06:52:51.000 [notice] We now have enough directory information to build circuits. >>>> Aug 15 06:52:51.000 [notice] Bootstrapped 80%: Connecting to the Tor network. >>>> Aug 15 06:52:52.000 [notice] Bootstrapped 85%: Finishing handshake with first hop. >>>> Aug 15 06:52:53.000 [notice] Guessed our IP address as 173.255.119.202 (source: 38.229.70.33). >>>> Aug 15 06:52:53.000 [notice] Bootstrapped 90%: Establishing a Tor circuit. >>>> Aug 15 06:52:53.000 [notice] Registered server transport 'obfs3' at '0.0.0.0:40872' >>>> Aug 15 06:52:53.000 [notice] Registered server transport 'obfs2' at '0.0.0.0:52176' >>>> Aug 15 06:52:55.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working. >>>> Aug 15 06:52:55.000 [notice] Bootstrapped 100%: Done. >>>> Aug 15 06:52:55.000 [notice] Now checking whether ORPort 173.255.119.202:443 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) >>>> Aug 15 06:53:04.000 [notice] New control connection opened. >>>> Aug 15 07:10:11.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor. >>>> >>>> >>>> >>>> On Wed, Aug 14, 2013 at 9:53 PM, lee colleton <lee(a)colleton.net> wrote: >>>> >>>>> Yes, I've opened the ports in the Google Compute Engine (see below). >>>>> I'll follow up on their forum to make sure I've altered the firewall >>>>> properly. >>>>> >>>>> --lee >>>>> >>>>> lee@li388-156:~$ gcutil --service_version="v1beta15" --project="colleton.net:tor-cloud" listfirewalls >>>>> +------------------------+---------------------------------------+---------+------------+-------------+-------------+ >>>>> | name | description | network | source-ips | source-tags | target-tags | >>>>> +------------------------+---------------------------------------+---------+------------+-------------+-------------+ >>>>> | default-allow-internal | Internal traffic from default allowed | default | 10.0.0.0/8 | | | >>>>> | default-ssh | SSH allowed from anywhere | default | 0.0.0.0/0 | | | >>>>> | tor-obfsproxy | | default | 0.0.0.0/0 | | obfsproxy | >>>>> +------------------------+---------------------------------------+---------+------------+-------------+-------------+ >>>>> lee@li388-156:~$ gcutil --service_version="v1beta15" --project="colleton.net:tor-cloud" getfirewall tor-obfsproxy >>>>> +---------------+-------------------------------+ >>>>> | property | value | >>>>> +---------------+-------------------------------+ >>>>> | name | tor-obfsproxy | >>>>> | description | | >>>>> | creation-time | 2013-08-07T18:37:35.986-07:00 | >>>>> | network | default | >>>>> | source-ips | 0.0.0.0/0 | >>>>> | source-tags | | >>>>> | target-tags | obfsproxy | >>>>> | allowed | tcp: 443, 9001, 40872, 52176 | >>>>> +---------------+-------------------------------+ >>>>> lee@li388-156:~$ >>>>> >>>>> >>>>> >>>>> On Wed, Aug 14, 2013 at 9:19 PM, Roger Dingledine <arma(a)mit.edu>wrote: >>>>> >>>>>> On Wed, Aug 14, 2013 at 09:08:03AM -0700, lee colleton wrote: >>>>>> > There's a more serious issue in that my server doesn't appear to be >>>>>> > reachable. I've opened tcp:443,9001 along with the two >>>>>> specifiedobfsproxy >>>>>> > ports >>>>>> > >>>>>> > Aug 14 15:26:58.000 [notice] Bootstrapped 100%: Done. >>>>>> > Aug 14 15:26:58.000 [notice] Now checking whether ORPort >>>>>> > 173.255.119.202:443 is reachable... (this may take up to 20 >>>>>> minutes -- >>>>>> > look for log messages indicating success) >>>>>> > Aug 14 15:28:00.000 [notice] New control connection opened. >>>>>> > Aug 14 15:46:56.000 [warn] Your server (173.255.119.202:443) has >>>>>> not >>>>>> > managed to confirm that its ORPort is reachable. Please check your >>>>>> > firewalls, ports, address, /etc/hosts file, etc. >>>>>> >>>>>> Well, that's because it's unreachable. (I just tried.) >>>>>> >>>>>> Can you try following the suggestion in the log message? >>>>>> >>>>>> --Roger >>>>>> >>>>>> -- >>>>>> tor-talk mailing list - tor-talk(a)lists.torproject.org >>>>>> To unsusbscribe or change other settings go to >>>>>> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk >>>>>> >>>>> >>>>> >>>> >

1 1

Experience with obfuscated bridge on Raspberry Pi Raspian
by z0rc 21 Aug '13

21 Aug '13

Hi, As lately there were many discussions on getting Tor from the experimental repository running on Raspian, I thought I would share my experiences here. First, I tried to install Tor following [1] and [2] and ran into the same compatibility issues as most of you. But then I just downloaded the soft-float version of Raspian "wheezy" from [3]. And I could install Tor and obsproxy from the experimental repository without any issues (i.e. without any compiling or complex configurations). I ran the obfuscated bridge for a week and it relayed a few 100 MB without any problems. The bridge is connected to a standard home cable connection in Switzerland (router runs pfSense). Of course the load was not too high due to only running an obfuscated bridge. After the week I decided to shut the bridge down because I heard from people being contacted by the police even though only running a non-exit relay. As I share a flat with some friends, I absolutely cannot afford being raided or similar. If anyone can give me some advice on running non-exit relays at home in Switzerland, I might consider running the bridge again. Hope this helps. Cheers, Damian [1] https://www.torproject.org/projects/obfsproxy-debian-instructions.html.en#i… [2] https://www.torproject.org/docs/debian.html.en#development [3] http://www.raspberrypi.org/downloads

4 5

Key files encryption methods.
by Tony Xue 21 Aug '13

21 Aug '13

Hi, As shown on the Tor website, the most important file of Tor is the key files. So is there any efficient way to encrypt those files in order to prevent anyone else, i.e. Hosting provider, getting and reading them? Is that those key files are only loaded when the Tor start and reload? So could it be possible to decrypt the file before the start-up and encrypt them again after the Tor start-up process is complete? Cheers, Tony

2 1

Upgrading an obfsbridge to the latest alpha on git master, on raspberry pi
by Kostas Jakeliunas 21 Aug '13

21 Aug '13

A few days ago, George posted an invitation for obfsproxy operators to upgrade their Tor software to the latest version on the master branch in the Tor git repo. [1] I'm running a low traffic obfsbridge on a raspberry pi, the whole thing is rather experimental in its nature already, so decided to try just that. Presumably everyone for whom this might be relevant already knows these things much better than myself, but since they might be applicable to all/some Debian users (raspberrypi + raspbian/debian users for sure), i'm outlining a couple of snags that can maybe be avoided. Previously I ran 0.2.4.15-rc compiled from deb-src (http://deb.torproject.org/torproject.orgexperimental-wheezy main); I think it'd have been the same if a precompiled package had been used. I'd still like to be able to manage Tor via init scripts with as little change as possible, etc. TL;DR: - after make && make install, do a whereis tor; in all likelihood, your new version will be at /usr/local/bin/tor, old one at /usr/sbin/tor etc.; /etc/init.d/tor will be using /usr/sbin/tor, so need to change the DAEMON key there - torrc-defaults will have different values in different distro packages. cd /usr/local/etc/tor; if there's no torrc there: sudo ln -s /etc/tor/torrc (presumably that's where you kept your torrc before; ~/.torrc should work in any case) $ git clone https://git.torproject.org/tor.git && cd tor $ ./autogen.sh if it complains about no aclocal (et al.): $ sudo apt-get install automake && ./autogen.sh $ ./configure $ make $ sudo make install # or, just use it like that (Tor binary is in src/or/) If you're using service tor {start,stop,reload,etc}: $ /usr/sbin/tor --version; /usr/local/bin/tor --version $ grep DAEMON= /etc/init.d/tor The latter will likely point to /usr/sbin/tor, which might be outdated (check above). If that's the case, change that line in init.d/tor to point to the new Tor executable /usr/local/bin/tor - that's where it *should* be; if you don't like that, change BINDIR = /usr/local/bin in Tor's Makefile and make install again. The Debian Tor packages seem to like to assume torrc will be placed in /etc/tor/torrc. If that's where your torrc resides, make a symlink to it from /usr/local/etc/tor, which is where the new Tor executable will look for it. This is probably an insanely ugly way of dealing with these snags, but if anyone is reserved to upgrade because of things like that, maybe this'll help someone.. Kostas. [1]: https://lists.torproject.org/pipermail/tor-relays/2013-August/002477.html

2 2

Re: [tor-relays] Experience with obfuscated bridge on Raspberry Pi Raspian
by TonyXue 20 Aug '13

20 Aug '13

>China's internet censorship / 'firewall' thing seems to have been trying to enumerate bridges for a while now. Yes, it does. I guess it's actually detecting bridges from users. The bridges become 'one-off', you can only use those bridges one time(at least in a period of time) and the second time you try to connect through the same bridges, it won't work. From: tony.x(a)outlook.com To: tor-relays(a)lists.torproject.org Subject: RE: [tor-relays] Experience with obfuscated bridge on Raspberry Pi Raspian Date: Tue, 20 Aug 2013 18:42:41 +0800 >China's internet censorship / 'firewall' thing seems to have been trying to enumerate bridges for a while now. Yes, it does. I guess it's actually detecting bridges from users. The bridges become 'one-off', you can only use those bridges one time(at least in a period of time) and the second time you try to connect through the same bridges, it won't work. From: kostas(a)jakeliunas.com Date: Tue, 20 Aug 2013 13:01:35 +0300 To: tor-relays(a)lists.torproject.org Subject: Re: [tor-relays] Experience with obfuscated bridge on Raspberry Pi Raspian Thanks for sharing your experience! > After the week I decided to shut the bridge down because I heard from people being contacted by the police even though only running a non-exit relay. Do you remember where you did hear this? Was it in writing, are you by chance maybe able to link to it? It would be interesting to know more. All non-bridge relays (exit or non-exit) can be enumerated by anyone (that's by design); this is not the case with bridges. However I suppose the extent to which any potential efforts to do just that may be happening does very much depend on the jurisdiction where that bridge is being run; China's internet censorship / 'firewall' thing seems to have been trying to enumerate bridges for a while now. [1] In any case, as far as I'm concerned, it would be *really* interesting to hear of any incidents between the police and non-exit relay operators. [1]: https://blog.torproject.org/blog/knock-knock-knockin-bridges-doors On Tue, Aug 20, 2013 at 2:00 AM, z0rc <damian.goeldi(a)gmail.com> wrote: Hi, As lately there were many discussions on getting Tor from the experimental repository running on Raspian, I thought I would share my experiences here. First, I tried to install Tor following [1] and [2] and ran into the same compatibility issues as most of you. But then I just downloaded the soft-float version of Raspian "wheezy" from [3]. And I could install Tor and obsproxy from the experimental repository without any issues (i.e. without any compiling or complex configurations). I ran the obfuscated bridge for a week and it relayed a few 100 MB without any problems. The bridge is connected to a standard home cable connection in Switzerland (router runs pfSense). Of course the load was not too high due to only running an obfuscated bridge. After the week I decided to shut the bridge down because I heard from people being contacted by the police even though only running a non-exit relay. As I share a flat with some friends, I absolutely cannot afford being raided or similar. If anyone can give me some advice on running non-exit relays at home in Switzerland, I might consider running the bridge again. Hope this helps. Cheers, Damian [1] https://www.torproject.org/projects/obfsproxy-debian-instructions.html.en#i… [2] https://www.torproject.org/docs/debian.html.en#development [3] http://www.raspberrypi.org/downloads _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0