Re: [tor-talk] Introducing Torsion, hidden service IM with real-world ambition
Fascinating project =) I look forward to watching it progress. best, Griffin John Brooks wrote: I’d like to present a project that I hope will interest some of you: Torsion is a ready-to-use hidden service instant messaging client with bigger goals and better implementation than the previous work on this concept. The goal [2] is to have a real solution for anonymous chat, with no servers to trust with your communication habits, that any reasonable person can use safely. I think this is a better way to meet those goals than the endless list of server-based encrypted messengers, including those that can integrate with Tor. The current version is a substantial improvement over (and not related to) TorChat, and I intend to quickly improve it from here to be more secure and more appealing to a broad audience. It’s usable now; there are packages [3] for Windows and OS X [4], a configuration wizard similar to TBB, contact requests, and a protocol I hopefully won’t regret. I’m looking for people to try it out, validate my ideas and implementation, and help plan the future. I’ve met my first milestones; where to go from here is a decision I’d like to make with the interested community. If you’re intrigued, please give it a try and add torsion:rs7ce36jsj24ogfw. I’m also responsive to email, github issues, and on OFTC as ‘special’. I’ve documented the major points of the design at [2], but I’m happy to answer questions and discuss. [1] https://github.com/special/torsion [2] https://github.com/special/torsion/blob/master/doc/design.md [3] https://github.com/special/torsion/releases [4] No linux packaging yet, see: https://github.com/special/torsion#downloading--building - John -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Introducing Torsion, hidden service IM with real-world ambition
Hi John interesting. Maybe you want to look at http://firefloo.sf.net , which is as well a decentral messaging hybrid with XMPP. When you swaped encryption keys, and set the proxy to Tor, then all friends with the lock-sign in the friendslist are sent over Tor. All your criteria are given and realized here, maybe it is worth to think about some integration. FireFloo does not need a central sever, and hence it is not needed to have a hidden service. The User-ID is as well detached from the IP or Tor. Maybe you want to check it out.. or send your key for a test. Regards Tom On Thu, Mar 27, 2014 at 6:20 AM, John Brooks john.bro...@dereferenced.netwrote: I'd like to present a project that I hope will interest some of you: Torsion is a ready-to-use hidden service instant messaging client with bigger goals and better implementation than the previous work on this concept. The goal [2] is to have a real solution for anonymous chat, with no servers to trust with your communication habits, that any reasonable person can use safely. I think this is a better way to meet those goals than the endless list of server-based encrypted messengers, including those that can integrate with Tor. The current version is a substantial improvement over (and not related to) TorChat, and I intend to quickly improve it from here to be more secure and more appealing to a broad audience. It's usable now; there are packages [3] for Windows and OS X [4], a configuration wizard similar to TBB, contact requests, and a protocol I hopefully won't regret. I'm looking for people to try it out, validate my ideas and implementation, and help plan the future. I've met my first milestones; where to go from here is a decision I'd like to make with the interested community. If you're intrigued, please give it a try and add torsion:rs7ce36jsj24ogfw. I'm also responsive to email, github issues, and on OFTC as 'special'. I've documented the major points of the design at [2], but I'm happy to answer questions and discuss. [1] https://github.com/special/torsion [2] https://github.com/special/torsion/blob/master/doc/design.md [3] https://github.com/special/torsion/releases [4] No linux packaging yet, see: https://github.com/special/torsion#downloading--building - John -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Tor Project and Youtube is blocked in Turkey too
Hey Andrew, Frankly, I admire Tor Project. I'm writing about censorship, privacy, surveillance ands similar subjects over a year. If I didn't have Tor or other anonymity tools, I wouldn't express myself freely. Maybe I auto-censor or self-censor my thoughts or writings I though. Actually, I need to thank you for giving me this opportunity. The first step to the end goal of censorship is surveillance. The Internet might seem like the ultimate tool for free speech, but without tools to protect our privacy, unwanted surveillance online can post a serious threat. Every day around the world, people are using Tor to protect their online privacy, whether they're concerned about surveillance by corporations, their government, or someone else. This is also true for circumventing Internet censorship. Tor, like all technology, can be used for good or bad. Kitchen knives, iPhones, and automobiles are used every day for both good and bad, yet no one is advocating a ban of these technologies. If someone starts a crime wave with crowbars, do you ban crowbars? Then hammers? Then tire irons? The morality is in the user of the technology, not the technology itself. The same Tor that's being maligned in the press is used daily by law enforcement agents to successfully hunt down horrendous criminals by protecting the identity and privacy of the agent. I wrote very similar in the article. I gave two examples. First one is an individual expressing himself/herself freely over Tor in an oppressing regime. Second one is a jerk who is abusing people over Tor. If you evaluate Tor over the jerk and say this is what Tor is, you're making a logical fallacy. Tell us how we can help Turkey defeat this attempt to censor the Internet. I think there are two ways to do that. First way changing the perception of Tor in here. Second way is raising awareness of Turkish Tor users. Because I read some posts about suggesting Adblock and some add-ons with plugins like Flash etc. I wrote installing and using add-ons or plugins may leak your IP, your graphic card info, take away your anonymity, it's not a good idea to change Tor Browser's environment by installing these and this will make it more unique. I don't know what it's called in English but creating some simple info graphics about Tor, using Bridges, what to do and what not to do both English and Turkish would be nice. And again, thanks for blogging about Tor in Turkey. You're very welcome. Chees, ~Kus -- Andrew pgp 0x6B4D6475 -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -- The most violent element in society is ignorance. Blog:https://network23.org/kame Twitter: https://twitter.com/songuncelleme Fingerprint: EE978F37B9ABAE87C449E875FED65B269A0545A9 -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Tor and Hamachi IP conflict
Hello, My problem is that if I want to host a relaying point, I have to release my Hamachi adapter, otherwise Tor resolves it's IP as my external, so others can't join. I tried to change the adapter order but it didn't help. Also, if I renew my Hamachi IP after Tor set up the relaying and done port checks, it says my external IP changed from Real external IP to Hamachi IP. I tried to set ORPort to 192.168.1.128:443 (my local IP that's connected to the router) and also OutboundBindAddress 192.168.50.128 but they did not help, Tor still trying to use my Hamachi IP. I'm using the v0.2.4.20 on Windows 7. Does anyone know a solution for this? Regards; Szotyi -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Safer Anonymous Operating System Guide
version 0.6.2 of the Beginner Friendly Comprehensive Guide to Installing and Using a Safer Anonymous Operating System is now online. the guide covers the following: - installing debian on a luks encrypted usb drive, or on a luks encrypted hd partition to be unlocked with a usb boot key. - installing virtualbox and whonix - installing, configuring and using tor browser, keepassx, xchat, pidgin+otr and icedove+torbirdy+enigmail. in order to meet the goal of making this information easy to follow by novice users, a screen shot has been provided for almost every step. a user editable wiki is available at the following urls: http://yuxv6qujajqvmypv.onion https://anonguide.cyberguerrilla.org a static uneditable version is available at http://www.freeanons.info/wiki/index.php?title=Beginner_os_guide pdf versions are also available on each of the pages. feedback and contributions welcome. -- gpg key - 0x2A49578A7291BB34 fingerprint - 63C4 E106 AC6A 5F2F DDB2 3840 2A49 578A 7291 BB34 -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Failed to connect to tor netword with the provided obfs3 bridges when using the tor-browser-linux64-3.6-beta-1.
--On Thursday, March 27, 2014 10:11 PM +0800 Hongyi Zhao hongyi.z...@gmail.com wrote: Yes, I'm from China. And the GFW is a annoying thing ;-( It protects you from american spying though. Whereas Tor enables it. 2014-03-27 16:55 GMT+08:00 Roger Dingledine a...@mit.edu: On Thu, Mar 27, 2014 at 03:51:09PM +0800, Hongyi Zhao wrote: In my case, considering that I use router for surfing and don't set the port fordwarding on the router, I don't test the flashproxy bridges shipped with the above tor-browser-bundle. Ok. If the other two stop working for you, maybe you will try Flashproxy. :) Considering that the obfs3 is the recommented type of tranport bridge, why I meet this issue? Any hints on this issue will be highly appreciated. It looks like the obfs3 bridges in the bundle are blocked by your network. And it looks like the fte bridges in the bundle are not blocked by your network. Are you in China perhaps? Note that whether the particular bridges are blocked (probably by IP and port) is a different question from whether the protocol (obfs3 or fte) is blocked by deep packet inspection. That is, it could just be that somebody at GFW fetched the bundle earlier and blocked the specific obfs3 bridges that it lists, whereas they haven't fetched a recent bundle to block the fte bridges yet. So if you found an obfs3 bridge that GFW hasn't found yet, it would probably still work? Worth testing. But that said, assuming you are in China, there aren't enough obfs3 bridges total, and it's not easy to give them out to everybody without GFW learning them too: https://blog.torproject.org/blog/how-to-read-our-china-usage-graphs --Roger -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -- Hongyi Zhao hongyi.z...@gmail.com Xinjiang Technical Institute of Physics and Chemistry Chinese Academy of Sciences GnuPG DSA: 0xD108493 -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] Linux kernel transproxy packet leak (w/ repro case + workaround)
Hello all, I've discovered that the Linux kernel appears to have a leak in how it applies transproxy rules to the TCP CLOSE_WAIT shutdown condition under certain circumstances. This applies to both the kernels in use by common Android devices (Cyanogenmod 10.x and 11-M4), as well as the Linux kernel in Ubuntu 13.04 (3.8.0-35-generic). The bug can be triggered either by a remote server closing a connection, or by restarting the local tor client. Basically, the bug happens when a transproxy connection shuts down completely before a client application properly closes the socket. This seems to cause the kernel to lose track of the fact that the client application connection was being transproxied, and when the client application finally does close its socket (or exits), the Linux kernel generates a FIN ACK that completely bypasses any transproxy rules you have installed. It sends this packet first as the UID of the app in question, and if that fails, it resends it as a blank UID (the kernel itself). Here's how to reproduce it and see for yourself: First run the attached iptables script, and launch a tor daemon with the attached torrc (edit the iptables script's TOR_UID=`id -u debian-tor` and NETWORK_USER_ID=1000 vars if your setup is different). Then, fire up tcpdump, like so: sudo tcpdump -n -i wlan0 host 74.125.28.104 and tcp port 80 Replace '-i wlan0' with your network interface. If you use '-i any', you will also see transproxied packets (which are not normally leaked). Then, as your transproxied user, paste this python snippet into a python interpreter: import socket s = socket.create_connection((74.125.28.104, 80)) (That IP handles www.google.com). After the connection is made, you should see something like the following in 'netstat -natp': tcp 0 0 127.0.0.1:9040 192.168.1.23:42235 ESTABLISHED 1121/tor tcp 0 0 192.168.1.23:42235 74.125.28.104:80 ESTABLISHED 977/python At this point, either wait a couple minutes for Google to close that connection on you, or shut down your Tor daemon. In either case, you should see the first connection transition to TIME_WAIT, or FIN_WAIT2, or similar, lose track of its PID+UID, and then finally disappear entirely, but the python program will remain in CLOSE_WAIT indefinitely. Once the first connection is fully gone (this takes 60s from TIME_WAIT state with default TCP settings), issue this in your python shell: s.close() At this point, you will see a FIN ACK or RST ACK packet appear in your tcpdump window. That packet has leaked past the iptables firewall rules, and past the transproxy rules. It went straight to Google. I have noticed several Android apps (including Firefox, F-Droid, and many Google apps and Android services) that allow their sockets to sit in CLOSE_WAIT upon remote close while transproxied, and they all leak packets in this case, which happens frequently in normal usage. I am not sure if this is just a common programming error, an issue with how the Android networking APIs are designed, something specifically exacerbated by the transproxy, or some combination of these. For a workaround, I was able to prevent this issue with the addition of the following rules: iptables -I OUTPUT ! -o lo ! -d 127.0.0.1 ! -s 127.0.0.1 -p tcp -m tcp --tcp-flags ACK,FIN ACK,FIN -j DROP iptables -I OUTPUT ! -o lo ! -d 127.0.0.1 ! -s 127.0.0.1 -p tcp -m tcp --tcp-flags ACK,RST ACK,RST -j DROP None of the transproxy documentation I could find mentions this issue, nor suggests any additional safety rules. This means every transproxied Tor user is unwittingly leaking packets, at least some of the time. Sorry to be the bearer of bad news. Please send workaround discussion to tor-talk, and kernel/TCP state machine discussion to tor-dev. I Cc'd both like a jerk, because I figure each group might have different sets of commentary, and both groups should be aware of this issue. Don't be a jerk like me, please. Use your best judgment to Cc one list or the other. -- Mike Perry #!/bin/bash IPTABLES=/sbin/iptables TOR_UID=`id -u debian-tor` NETWORK_USER_ID=1000 # Clear existing rules $IPTABLES -F INPUT $IPTABLES -F OUTPUT $IPTABLES -t nat -F ## Transproxy rules for Tor $IPTABLES -t nat -A OUTPUT ! -d 127.0.0.1 -m owner ! --uid-owner $TOR_UID -p tcp -j REDIRECT --to-ports 9040 || exit $IPTABLES -t nat -A OUTPUT -p udp -m owner ! --uid-owner $TOR_UID -m udp --dport 53 -j REDIRECT --to-ports 5300 || exit # Allow Tor and the network user $IPTABLES -A OUTPUT -m owner --uid-owner $TOR_UID -j ACCEPT || exit $IPTABLES -A OUTPUT -m owner --uid-owner $NETWORK_USER_ID -j ACCEPT $IPTABLES -A INPUT -j LOG --log-prefix OUTPUT DROPPED: --log-uid || exit $IPTABLES -A OUTPUT -j DROP || exit # Create INPUT firewall. Allow established connections and transproxy $IPTABLES -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT || exit $IPTABLES -A INPUT -i lo -j ACCEPT # Transproxy output comes from lo $IPTABLES -A INPUT -d
[tor-talk] DOJ Pushes to Hack Cyber-Criminals (Torizens)
http://blogs.wsj.com/law/2014/03/27/doj-pushes-to-expand-hacking-abilities-against-cyber-criminals http://arstechnica.com/tech-policy/2014/03/feds-want-an-expanded-ability-to-hack-criminal-suspects-computers http://news.slashdot.org/story/14/03/28/0242232/doj-pushes-to-expand-hacking-abilities-against-cyber-criminals http://yro.slashdot.org/story/14/03/28/195200/cispas-author-has-another-privacy-killing-bill-to-pass-before-he-retires http://edition.cnn.com/2014/03/27/living/student-money-saving-typeface-garamond-schools/index.html -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [tor-dev] Linux kernel transproxy packet leak (w/ repro case + workaround)
On Fri, Mar 28, 2014 at 3:43 PM, Mike Perry mikepe...@torproject.org wrote: I've discovered that the Linux kernel appears to have a leak in how it applies transproxy rules to the TCP CLOSE_WAIT shutdown condition under certain circumstances. ... At this point, you will see a FIN ACK or RST ACK packet appear in your tcpdump window. That packet has leaked past the iptables firewall rules, and past the transproxy rules. It went straight to Google. Good eye. This applies to both the kernels in use by common Android devices (Cyanogenmod 10.x and 11-M4), as well as the Linux kernel in Ubuntu 13.04 (3.8.0-35-generic). It someone here can also verifiy and second it against a current stock kernel, such as 3.12.15, why not submit it to Linux Bugzilla? https://www.kernel.org/ https://bugzilla.kernel.org/ For a workaround, I was able to prevent this issue with the addition of the following rules: That is, if it's a bug and not a 'use a proper ruleset' issue. None of the transproxy documentation I could find mentions this issue So that Tor and folks like Tails won't have to carry such docs and workaround forever. The ruleset seems to use uid based transproxy, what happens with entire vm IP transproxy (perhaps like Tails)? -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] [tor-dev] Linux kernel transproxy packet leak (w/ repro case + workaround)
grarpamp wrote (28 Mar 2014 21:02:35 GMT) : [...] what happens with entire vm IP transproxy (perhaps like Tails)? Tails only uses a transproxy for the automapped .onion addresses: https://tails.boum.org/contribute/design/Tor_enforcement/ Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] Linux kernel transproxy packet leak (w/ repro case + workaround)
Velope on IRC suggested a better workaround. It turns out these connections actually end up in state INVALID when the transproxy side dies. I tested this with my repro case and confirmed that the --ctstate rule is working by itself. Additional iptables rules inline below. Preserving full original text for historical record. Mike Perry: Hello all, I've discovered that the Linux kernel appears to have a leak in how it applies transproxy rules to the TCP CLOSE_WAIT shutdown condition under certain circumstances. This applies to both the kernels in use by common Android devices (Cyanogenmod 10.x and 11-M4), as well as the Linux kernel in Ubuntu 13.04 (3.8.0-35-generic). The bug can be triggered either by a remote server closing a connection, or by restarting the local tor client. Basically, the bug happens when a transproxy connection shuts down completely before a client application properly closes the socket. This seems to cause the kernel to lose track of the fact that the client application connection was being transproxied, and when the client application finally does close its socket (or exits), the Linux kernel generates a FIN ACK that completely bypasses any transproxy rules you have installed. It sends this packet first as the UID of the app in question, and if that fails, it resends it as a blank UID (the kernel itself). Here's how to reproduce it and see for yourself: First run the attached iptables script, and launch a tor daemon with the attached torrc (edit the iptables script's TOR_UID=`id -u debian-tor` and NETWORK_USER_ID=1000 vars if your setup is different). Then, fire up tcpdump, like so: sudo tcpdump -n -i wlan0 host 74.125.28.104 and tcp port 80 Replace '-i wlan0' with your network interface. If you use '-i any', you will also see transproxied packets (which are not normally leaked). Then, as your transproxied user, paste this python snippet into a python interpreter: import socket s = socket.create_connection((74.125.28.104, 80)) (That IP handles www.google.com). After the connection is made, you should see something like the following in 'netstat -natp': tcp 0 0 127.0.0.1:9040 192.168.1.23:42235 ESTABLISHED 1121/tor tcp 0 0 192.168.1.23:42235 74.125.28.104:80 ESTABLISHED 977/python At this point, either wait a couple minutes for Google to close that connection on you, or shut down your Tor daemon. In either case, you should see the first connection transition to TIME_WAIT, or FIN_WAIT2, or similar, lose track of its PID+UID, and then finally disappear entirely, but the python program will remain in CLOSE_WAIT indefinitely. Once the first connection is fully gone (this takes 60s from TIME_WAIT state with default TCP settings), issue this in your python shell: s.close() At this point, you will see a FIN ACK or RST ACK packet appear in your tcpdump window. That packet has leaked past the iptables firewall rules, and past the transproxy rules. It went straight to Google. I have noticed several Android apps (including Firefox, F-Droid, and many Google apps and Android services) that allow their sockets to sit in CLOSE_WAIT upon remote close while transproxied, and they all leak packets in this case, which happens frequently in normal usage. I am not sure if this is just a common programming error, an issue with how the Android networking APIs are designed, something specifically exacerbated by the transproxy, or some combination of these. For a workaround, I was able to prevent this issue with the addition of the following rules: iptables -I OUTPUT ! -o lo ! -d 127.0.0.1 ! -s 127.0.0.1 -p tcp -m tcp --tcp-flags ACK,FIN ACK,FIN -j DROP iptables -I OUTPUT ! -o lo ! -d 127.0.0.1 ! -s 127.0.0.1 -p tcp -m tcp --tcp-flags ACK,RST ACK,RST -j DROP Here's a set of rules to try both --ctstate and --state invalid, as well as log which ones get hit, for testing purposes. Note the use of -A in this case, for readability wrt ordering. These rules should come before any other rule in the OUTPUT chain section of the firewall script you use: #iptables -A OUTPUT -m conntrack --ctstate INVALID -j LOG --log-prefix Transproxy ctstate leak blocked: --log-uid iptables -A OUTPUT -m conntrack --ctstate INVALID -j DROP iptables -A OUTPUT -m state --state INVALID -j LOG --log-prefix Transproxy state leak blocked: --log-uid iptables -A OUTPUT -m state --state INVALID -j DROP iptables -A OUTPUT ! -o lo ! -d 127.0.0.1 ! -s 127.0.0.1 -p tcp -m tcp --tcp-flags ACK,FIN ACK,FIN -j LOG --log-prefix Transproxy leak blocked: --log-uid iptables -A OUTPUT ! -o lo ! -d 127.0.0.1 ! -s 127.0.0.1 -p tcp -m tcp --tcp-flags ACK,RST ACK,RST -j LOG --log-prefix Transproxy leak blocked: --log-uid iptables -A OUTPUT ! -o lo ! -d 127.0.0.1 ! -s 127.0.0.1 -p tcp -m tcp --tcp-flags ACK,FIN ACK,FIN -j DROP iptables -A OUTPUT ! -o lo ! -d 127.0.0.1 ! -s 127.0.0.1 -p tcp -m tcp --tcp-flags ACK,RST
