Re: [tor-relays] Debian relay Puppet module
On Mon, Jun 16, 2014 at 4:40 AM, Moritz Bartl mor...@torservers.net wrote: Thank you for this. I've come across several Puppet and Ansible recipes for Tor over time, but sadly have not found time to properly review or even use them for our own servers yet. Thank you for the feedback. I'm new in the Tor land but I think a well crafted CM module could definitely help the adoption, so I'm happy to see there's some discussion here. https://github.com/shaftoe/puppet-tor/blob/fixes/manifests/apt.pp key = '886DDD89' You should never rely on short key IDs for anything. They can be forged within minutes. When you look at https://www.torproject.org/docs/debian.html.en , it fetches the key using the short key ID, but only imports a key that matches the whole fingerprint. Ok I found keys.gnupg.net to be unreliable sometimes, it would be good to have some fallback options. Maybe add this fallback options to https://www.torproject.org/docs/debian.html.en too? Tor generates key material, the default location is /var/lib/tor. I always wondered if it was possible to pregenerate the necessary files locally, and then push them to the relays, where /var/lib/tor is on a ramdisk. I've been told on #tor that the secret_id key is more to be thought as a 'state' more then as a configuration, and if a Tor relay has to be moved on a different server, it's best practice to just start a new one from fresh. Or better said, there's no actual need of keeping a fingerprint consistent. Personally, I think it would be great to not only have puppet modules spread out somewhere across the Internet, but a full-fledged guide/wizard that makes it easy for people to locally configure relays without knowing anything about Tor configuration options. In my dream world, it would not only support Debian: Right now, most of the Tor network runs on Debian, which is not ideal. We need more *BSD and Solaris! And FreeDOS! :) Yeah, I share the dream too :) It should be as easy as include 'tor' to install a relay with the most common configurations default (in my case, a non exit relay), regardless of the platform. -- http://about.me/alexanderfortin ___ 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 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.___ 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 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
[tor-relays] New SSL keys for new OpenSSL version?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Tor! I run an internal Tor relay on Debian Wheezy. Today the OpenSSL version was updated to 1.0.1e-2+deb7u11 . Do I need to delete the old SSL keys like after the Heartbleed bug? Thanks and best regards Anton - -- no.thing_to-hide at cryptopathie dot eu 0x30C3CDF0, RSA 2048, 24 Mar 2014 0FF8 A811 8857 1B7E 195B 649E CC26 E1A5 30C3 CDF0 Bitmessage (no metadata): BM-2cXixKZaqzJmTfz6ojiyLzmKg2JbzDnApC -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJTn1hxAAoJEMwm4aUww83weJAH/jYHtjrhrFrGnVdjrKPlN/TR w9NZcvRd0GrNDbZGGwemVam+OmFdHTDEeWZ73fgb/DvrGT8Iej8hD09/vD37xn9p GYhLabsKW06j8oRz7fiVDlWVOWND8QHW+UImnwKcIlvgp9a2EaSyBGVshIGppqMW wGgc8ZhoXvo5fAe/M630PHi6e/oGDJZIilSTIDmttV8M9cTEmsxah64oHZiJqVqc ierCAlAlsbkYH7fs7/QgJw0QolnhtcIZ5ALgijT+Z4EGH5oJBFnA20lvni1qLp1T O/RUTuF8qLAUWFBLgrF1Ng5zDlyPEaVUK5SO1pM6dzvDwvSWOlrapmfCd3b07DI= =OslV -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] New SSL keys for new OpenSSL version?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/16/2014 11:49 PM, no.thing_to-h...@cryptopathie.eu wrote: Hello Tor! I run an internal Tor relay on Debian Wheezy. Today the OpenSSL version was updated to 1.0.1e-2+deb7u11 . Do I need to delete the old SSL keys like after the Heartbleed bug? Thanks and best regards Anton ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays No, you do not need to delete the keys and you SHOULD NOT delete those keys if not in an extreme situation. The latest OpenSSL vulnerability was not that bad, it had a different attack vector and an attacker could not have possibly gain your onion keys, unlike in heartbleed, where an attacker could read data out of your memory and theoretically compromise your onion keys. It's a good thing you changed keys after heartbleed, but the latest vulnerability did not have such impact so you should not do the same, otherwise you will lose your current identity (relay), flags and all history associated with it in the consensus. Tor-relay mail list (subscribe if you are not subscribed) will always tell you what you need to do, in such events. If you need to throw away onion keys and generate new keys for an existing relay, you will be clearly notified about it, if not, it means they were not affected. In the latest OpenSSL bug you only needed to update OpenSSL, that's all. - -- s7r PGP Fingerprint: 7C36 9232 5ABD FB0B 3021 03F1 837F A52C 8126 5B11 PGP Pubkey: http://www.sky-ip.org/s...@sky-ip.org.asc -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) iQEcBAEBAgAGBQJTn17aAAoJEIN/pSyBJlsRKe8H/3RaRM2qS8VwpRgkwUmwI8l/ UT5hfDmCqAeyNRdBkLo46Xe32MD/qyBQg7F8U5iLO3cPHDIm1zejHzeR04rAV6T5 f8mQdx3BAotTwgVQnPAAMYbuF9MKGf2SeeKkio9M7/Udbg89t+had+FFx57j07H2 lpDKRQo8ot2lnlDe1VRlcF0hojcyddq2b7ny3hRf/I4dgT4eU2uvbFo9mXMkJYab eNgpTge8ZguM+gGIJEYo/jA/rf2Z5e3xrdevKqjxWY0waRphXQ3Lhb06u0lG6I/w kUM/yRC8AdVo3GbGqHAA6NiI3JHrEabxHxumsZmtircq9nYazRQszIbVhJc0x90= =Z53i -END PGP SIGNATURE- ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
Re: [tor-relays] Debian relay Puppet module
On Sunday, June 15, 2014, Moritz Bartl mor...@torservers.net wrote: Personally, I think it would be great to not only have puppet modules spread out somewhere across the Internet, but a full-fledged guide/wizard that makes it easy for people to locally configure relays without knowing anything about Tor configuration options. +1; this would be great for Tor Cloud users. In my dream world, it would not only support Debian: Right now, most of the Tor network runs on Debian, which is not ideal. We need more *BSD and Solaris! And FreeDOS! :) Why is this not ideal? I'm not following. Also, do you mean Debian or Debian-like? If the latter, Tor Cloud (Ubuntu) probably accounts for a fair bit of that inbalance. ___ 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 6/16/14, grarpamp grarp...@gmail.com wrote: On Thu, May 15, 2014 at 9:36 AM, Jeroen Massar jer...@massar.ch wrote: If an operator does not want you on their site, do not circumvent it. You are thus stating: I want to circumvent a site's decision to block me. No, you are still not understanding a (not so delicate, yet very important) distinction... - IP blocking is NOT blocking a particular single user context (ie: 'you', 'me', joe, jane, anonuser1543), it is blocking whoever happens to be using that IP [1]. In my opinion, that is wrong because it takes out innocent users and thus I'm happy to suggest any number of ways to push back against it until this effectively 'anti-innocent' model changes. This is foundational I say - some of us are willing to give up a little (or a lot) of convenience, for the long term benefits/ freedoms which we anticipate and strive for. Today we have an abundance of libre/free software. When Richard Stallman, and later others, sacrificed their time and their statutory proprietary-ownership possibilities, for the long term vision, they did not have the abundance that has since been created - their sacrifice was MUCH greater than ours today. Yet the spirit of sacrifice/inconvenience for the longer term greater good, lives strongly in some of us. I wholeheartedly support those who live this principle. Rock on! Zenaan ___ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
