Re: [tor-dev] Why the seeming anticorrelation between obfs3 and vanilla bridges in metrics graphs?
On 23/10/14 19:32, David Fifield wrote: > In the past few months of bridge user graphs, there is an apparent > negative correlation between obfs3 users and vanilla users: when one > goes up, the other goes down. If you draw a horizontal line at about > 5500, they are almost mirror images of each other. I don't see it with > any other transport pairs. Any idea why it might be? Hi David, I briefly looked at the raw data behind this graph, but didn't find any obvious problems with the algorithm. I'm running out of time now, but I can share some preliminary results in case you want to dig deeper: - https://people.torproject.org/~karsten/volatile/bridge-users-obfs3-or-mean.png is the graph that you posted with a third line for mean values. - https://people.torproject.org/~karsten/volatile/bridge-responses.csv.xz contains numbers of responses (for requested consensuses) by bridge, transport, and time interval. - https://people.torproject.org/~karsten/volatile/bridge-responses-by-transport.pdf shows responses by transport. - https://people.torproject.org/~karsten/volatile/bridge-responses-over-time.pdf shows only and obfs3 responses over time. - https://people.torproject.org/~karsten/volatile/bridge-responses-or-by-fingerprint.pdf shows only responses higher than 1000 by fingerprint. - https://onionoo.torproject.org/details?fingerprint=231E2DE81DC4314F2035D2C0D0D043A425FF8999 is the bridge reporting those high numbers for responses. Is PacificSunset maybe one of the bundled bridges? That's all. Maybe it helps? All the best, Karsten ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] tor-fw-helper redux
Hello, "You are in a maze of twisty little firmwares, all terrible". I'm at the point where the new and improved firewall helper could use some additional testing by various users, though there's some issues with the design that still need to be resolved. But not being one to keep issues inherited from the original from stopping progress... Code: https://github.com/yawning/go-fw-helper Bug: https://trac.torproject.org/projects/tor/ticket/13338 Yes, it's another Go app. It should work both as a helper for tor (PortForwardingHelper in the torrc), and for flashproxy. I am currently only concerned about the latter use case since it will immediately make flashproxy more useful in various environments, and I'm not sure people that can't setup port forwarding should be running relays in the first place. How to test it: $ go build github.com/yawning/go-fw-helper One of: * Play with it by hand. "-h" dumps usage. * Edit the torrc-defaults file shipped with Tor Browser to have flashproxy use the helper. On the Linux bundle the file in question is located at tor-browser_en-US/Browser/TorBrowser/Data/Tor The flashproxy ClientTransportPlugin line should look something like: ClientTransportPlugin flashproxy exec ./TorBrowser/Tor/PluggableTransports/flashproxy-client --port-forwarding-helper=/path/to/go-fw-helper --register :0 :9000 You *can* edit where it says "9000" to use a different port, but having it auto assigned will lead to it being harder to remove when done. * Try running a tor relay using PortForwardingHelper. I personally don't recommend this, and haven't tested it at all, but there's no reason why it won't work unless the tor side of the code rotted (unlikely?). Caveats: * Not sure which version of the Go compiler/runtime this requires. Development was done on 1.3.3. It probably requires 1.2.x but it may work on older versions (Not a bug/WONTFIX). * UPnP discovery requires being able to listen on a UDP traffic and accept incoming packets. Your local firewall may prevent this. (Not a bug/WONTFIX). * flashproxy does not know how to deal with mappings expiring, so things will stop working after 2 hours if NAT-PMP is used. * Neither flashproxy nor tor know how to use go-fw-helper to delete mappings, because tor-fw-helper did not have such a thing. WARNING: If UPnP is used as the protocol, mappings are indefinite. You will need to use the router's admin interface or "go-fw-helper -d" to remove it. Yes, there is a very good reason why this is like this, despite the protocol on paper having the length as a registration time parameter. Note: NAT-PMP mappings obtained by go-fw-helper last for 2 hours. * go-fw-helper's "-T" option doesn't do everything tor-fw-helper's does. (Meh?) * The UPnP mapping description is hard coded to "Tor relay" to match tor-fw-helper. Useful extensions over tor-fw-helper: Dump all current mappings with: $ go-fw-helper -l Remove mappings with: $ go-fw-helper -d ([]:] Both of those options only work with UPnP because NAT-PMP does not have a method of querying mapping information, and because at least one NAT-PMP implementation deployed on a lot of routers does not handle removal correctly (Bug reported to maintainer, and fixed in master but people do not update router firmware enough. There is a way to force go-fw-helper to let you delete port forwarding entries, but it's intentionally undocumented, because I don't want to support it.) Force a certain protocol (Case sensitive): $ go-fw-helper --protocol=NAT-PMP ... $ go-fw-helper --protocol=UPnP ... Tested on: * 64 bit Linux * 64 bit FreeBSD 9.3 * 32 bit Windows 7 Need testing on: * Darwin (esp with NAT-PMP) * With more routers than the 2 I have immediate access to. If something breaks "-v" gets you debug output. Questions, Comments, Feedback appreciated, -- Yawning Angel pgpWsPVIzWZO3.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Understanding Tor and SOCKS
Hi everyone! I am trying to understand the communication between an application and Tor (especially connecting to a hidden service). I am tracing packets on loopback between a torified netcat request to connect to a .onion address. When the connection gets granted I am getting a response from the socks server: (hex data of the tcp payload) 0x05 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 Regarding to the SOCKS specification this means that the request is granted. But I don't understand the 0x01 in byte no 4. It means IPv4 address in the SOCKS specification, but the following part of the destination address and port (the following 0x00's) are empty. So what does that 0x01 mean? Can someone explain me that? Thank you! Cheers, spriver ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Understanding Tor and SOCKS
Hm... Did you try Wireshark on it? 2014-10-26 11:46 GMT+03:00 spriver : > Hi everyone! > > I am trying to understand the communication between an application and Tor > (especially connecting to a hidden service). I am tracing packets on > loopback between a torified netcat request to connect to a .onion address. > When the connection gets granted I am getting a response from the socks > server: > (hex data of the tcp payload) > > 0x05 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 > > Regarding to the SOCKS specification this means that the request is > granted. But I don't understand the 0x01 in byte no 4. It means IPv4 > address in the SOCKS specification, but the following part of the > destination address and port (the following 0x00's) are empty. So what does > that 0x01 mean? > > Can someone explain me that? > > Thank you! > > Cheers, > spriver > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] tor-fw-helper redux
On Sun, Oct 26, 2014 at 08:41:08AM +, Yawning Angel wrote: > Hello, > > "You are in a maze of twisty little firmwares, all terrible". > > I'm at the point where the new and improved firewall helper could use > some additional testing by various users, though there's some issues > with the design that still need to be resolved. But not being one > to keep issues inherited from the original from stopping progress... > > Code: https://github.com/yawning/go-fw-helper > Bug: https://trac.torproject.org/projects/tor/ticket/13338 This is great. Is there any reason not to call it tor-fw-helper, and replace/deprecate the existing src/tools/tor-fw-helper? I'm thinking that as a conservative step, we should first deploy using a static external port for flash proxy. An ephemeral port is better for scanning resistance, but there is also the risk of poking long-lasting holes in firewalls and overflowing port forwarding tables in these shoddy routers. We need at least to add a loop to where flashproxy-client calls the port forwarding helper. Ideally we would also try to remove the mapping before exiting. We could do it in the first SIGINT handler--though we know that SIGINT handling doesn't work on Windows because tor immediately zaps you with TerminateProcess. We could do something like we do with terminateprocess-buffer and meek-client-torbrowser, and add an --exit-on-stdin-eof option to flashproxy-client so that it can detect when it is supposed to shut down gracefully. I'm not sure it's worth it though, especially if unmapping ports is unreliable. We'll need a tor-browser-bundle branch that builds go-fw-helper and adds it to the ClientTransportPlugin line. I'll look at adding the flashproxy-client loop. > * The UPnP mapping description is hard coded to "Tor relay" to match >tor-fw-helper. Is there any way to omit it or leave it blank? I thought there was a ticket somewhere about "Tor relay" making Tor use more conspicuous, but I can't find it now. David Fifield ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] tor-fw-helper redux
On Sun, 26 Oct 2014 02:07:26 -0700 David Fifield wrote: > On Sun, Oct 26, 2014 at 08:41:08AM +, Yawning Angel wrote: > > Hello, > > > > "You are in a maze of twisty little firmwares, all terrible". > > > > I'm at the point where the new and improved firewall helper could > > use some additional testing by various users, though there's some > > issues with the design that still need to be resolved. But not > > being one to keep issues inherited from the original from stopping > > progress... > > > > Code: https://github.com/yawning/go-fw-helper > > Bug: https://trac.torproject.org/projects/tor/ticket/13338 > > This is great. Is there any reason not to call it tor-fw-helper, and > replace/deprecate the existing src/tools/tor-fw-helper? No particular reason for the former. This could even be done at the packaging step since I kind of don't want to move the repo. I think, assuming people like my stab at this, that having it live in it's own space under git.tp.o somewhere would be best. > I'm thinking that as a conservative step, we should first deploy > using a static external port for flash proxy. An ephemeral port is > better for scanning resistance, but there is also the risk of poking > long-lasting holes in firewalls and overflowing port forwarding > tables in these shoddy routers. Indeed. It has no external dependencies so adding it to the build process should be trivial, just not something I've bothered with yet. > We need at least to add a loop to where flashproxy-client calls the > port forwarding helper. Ideally we would also try to remove the > mapping before exiting. We could do it in the first SIGINT > handler--though we know that SIGINT handling doesn't work on Windows > because tor immediately zaps you with TerminateProcess. We could do > something like we do with terminateprocess-buffer and > meek-client-torbrowser, and add an --exit-on-stdin-eof option to > flashproxy-client so that it can detect when it is supposed to shut > down gracefully. I'm not sure it's worth it though, especially if > unmapping ports is unreliable. I would think it's worth trying to do so, particularly if ephemeral ports are used. NAT-PMP mappings (the one that has routers that have trouble unmapping), have a sane lifespan (currently 2h, but changing this is trivial). As far as I know removing UPnP mappings should always work, and that's the protocol that needs infinite duration mappings due to firmware badness. There's no harm in trying to unregister mappings. Unless the undocumented flag is set, go-fw-helper will just fail to remove NAT-PMP mappings with an internal error. I changed the reporting for the deregistration process to mostly match the registration as well, so automating this is straight forward. I may reconsider disallowing NAT-PMP deregistration since the router side implementation where I found the bug supports both UPnP and NAT-PMP, and so in such environments UPnP should be used anyway due to how the code is setup. > We'll need a tor-browser-bundle branch that builds go-fw-helper and > adds it to the ClientTransportPlugin line. I'll look at adding the > flashproxy-client loop. > > > * The UPnP mapping description is hard coded to "Tor relay" to > > match tor-fw-helper. > > Is there any way to omit it or leave it blank? I thought there was a > ticket somewhere about "Tor relay" making Tor use more conspicuous, > but I can't find it now. It's a constant in the UPnP code. This is also trivial to omit/change, if people want it to be different, but having it well defined makes the admin side of things easier. NAT-PMP doesn't have a description field. As a side note, before I sent the e-mail, I was browsing the web for a bit with flashproxy configured to use the helper, so at least in my test environment things work as expected. -- Yawning Angel pgpVJ0UyNHcWA.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Understanding Tor and SOCKS
> address. When the connection gets granted I am getting a response from > the socks server: > (hex data of the tcp payload) > > 0x05 0x00 0x00 0x01 0x00 0x00 0x00 0x00 0x00 0x00 > > Regarding to the SOCKS specification this means that the request is > granted. But I don't understand the 0x01 in byte no 4. It means IPv4 > address in the SOCKS specification, but the following part of the > destination address and port (the following 0x00's) are empty. So what > does that 0x01 mean? > > Can someone explain me that? > Hi, What you see is the reply to a CONNECT command. From: https://www.ietf.org/rfc/rfc1928.txt CONNECT In the reply to a CONNECT, BND.PORT contains the port number that the server assigned to connect to the target host, while BND.ADDR contains the associated IP address. The supplied BND.ADDR is often different from the IP address that the client uses to reach the SOCKS server, since such servers are often multi-homed. It is expected that the SOCKS server will use DST.ADDR and DST.PORT, and the client-side source address and port in evaluating the CONNECT request. So, the SOCKS protocol supports redirection to another SOCKS server. An all-zero address/port simply means: use the server/port that you are currently connected to. Rob. http://freedomboxblog.nl ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Vidalia Relay Bundle(win) Tor version, obfs4proxy package in deb.tp.o
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 1. I have noticed that the Vidalia Relay Bundles for Windows available to download on torproject.org are using Tor 0.2.4.23, while we are on 0.2.5.10 as stable branch. I know 0.2.4.23 is still on the recommended list in the consensus, but since someone is downloading the bundles fresh from the Tor home page, I think it is expected to include the latest stable Tor version. 2. Configured some obfs4 bridges using obfs4proxy. They work very good, however it's a little bit complicated since package obfs4proxy exists in Debian sid, but not in deb.torproject.org, so you have to add sid repo to sources.list, install obfs4proxy and then make sure you edit apt preferences or comment the sid repo from the list in order not to upgrade you entire Debian system with packages from unstable/testing branch. Received couple of emails from users wanted to deploy obfs4 bridges and were confused. Is it possible to include obfs4proxy in deb.torproject.org for Debian, and while at it also make a rpm package for RHEL/CentOS? obfsproxy (python based pluggable transport) was easy to install in RHEL/CentOS using EPEL repo and `pip` but obfs4proxy should come as a rpm from deb.torproject.org. 3. Last thing, the page https://bridges.torproject.org/ does not contain obfs4 in the drop-down list where the user needs to select the pluggable transport. It only allows requests for obfs2, obfs3, scramblesuit and fteproxy bridges. Don't know about fteproxy, but shouldn't obfs2 be deprecated or is it still working/used? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUTRBeAAoJEIN/pSyBJlsR2zwH/2mnA2GNomxNQZI7Eeumt1sM uA6iXvlUiILJdQRG8EcHx8sfHU5MD20V5mOH774XsX7elAG47/ePL+/SKL69OfuR nl/X4IzH34CaqbMLGVHotl9Bcugfgw71fAF+Gm5nymM8VRxsdQnS51nnz7pwphon /DeeMfCE45eCYpVYyOqXZcSM4DA6Hr5bWG5TlCVJXTOl67fMr/pEBFgfpc6RIAL/ 8GXk+Cv6k/vW0AsEb/XoHBNbIzfHhOlb9O9q3giq3kGmJahMheKKLVOP5FNiEWi1 S6AhlxOYNnoAc9jhSAmNsMmJCteVVBV96c9jgeP9QOF2WtLnq6md8/uFocOelUc= =iUXk -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Vidalia Relay Bundle(win) Tor version, obfs4proxy package in deb.tp.o
On Sun, 26 Oct 2014 17:16:46 +0200 s7r wrote: > 3. Last thing, the page https://bridges.torproject.org/ does not > contain obfs4 in the drop-down list where the user needs to select the > pluggable transport. It only allows requests for obfs2, obfs3, > scramblesuit and fteproxy bridges. Don't know about fteproxy, but > shouldn't obfs2 be deprecated or is it still working/used? A note on this (I don't handle packaging, sorry). obfs4 propbably should be added to the dropdown once there is a critical mass of bridges in the database, and when obfs4 is in official Tor Browser builds. As far as I am aware, the official integration (as opposed to my obsolete not-really-working-anymore snapshots) is scheduled to happen in the next alpha series. Regarding obfs2, it still "works" in some environments if the DPI used by the censor is not particularly sophisticated (not targeted specifically at detecting obfs2). I personally think that it should be deprecated sooner rather than later, but others have disagreed with me on this. Hope that helps, -- Yawning Angel pgpRkxhRUfSjM.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Understanding Tor and SOCKS
On Sun, 26 Oct 2014 14:34:59 +0100 Rob van der Hoeven wrote: > So, the SOCKS protocol supports redirection to another SOCKS server. > An all-zero address/port simply means: use the server/port that you > are currently connected to. That's a really interesting way of interpreting that part of the RFC. The reason why BND.ADDR and BND.PORT are supplied in a SOCKS5 response is to provide the client with the information equivalent to calling getsockname() on a non-proxied socket. In the context of tor, the reason why BND.ADDR and BND.PORT are all NUL bytes is because the RELAY_CONNECTED cell does not propagate BND.PORT backwards to the client from the exit. BND.ADDR could technically be filled in (since the tor client knows where it is exiting from), but I don't see much point (and this information is useless at best in the context of HSes). Regards, -- Yawning Angel pgpGA5tzki8YH.pgp Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfs4proxy package in deb.tp.o
s7r: > 2. Configured some obfs4 bridges using obfs4proxy. They work very > good, however it's a little bit complicated since package obfs4proxy > exists in Debian sid, but not in deb.torproject.org, so you have to > add sid repo to sources.list, install obfs4proxy and then make sure > you edit apt preferences or comment the sid repo from the list in > order not to upgrade you entire Debian system with packages from > unstable/testing branch. Received couple of emails from users wanted > to deploy obfs4 bridges and were confused. > > Is it possible to include obfs4proxy in deb.torproject.org for Debian You should now be able to get obfs4proxy by using: deb http://deb.torproject.org/torproject.org obfs4proxy main The package should work on most Ubuntu and Debian versions. It is available for amd64 and i386. -- Lunar signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Request to expunge project 'torsocks' on Google Code
Hello again! I want to reiterate very strongly that this page needs to be closed OR at the very least should point to the official git.tpo code. Please, who ever has admin right to the Google code torsocks page, manifest yourself. This is important, the 1.3 code is not safe and unmaintained. Thanks! David On 16 Aug (10:25:55), David Goulet wrote: > On 28 Feb (22:19:39), Roger Dingledine wrote: > > On Wed, Feb 26, 2014 at 02:06:25PM +0100, Jeroen Massar wrote: > > > On 2014-02-26 13:46, Jacob Appelbaum wrote: > > > > I think this is a fine idea - if no one objects, I'll purge it. > > > > > > No objection per-se, but a recommendation/check-up: > > > > Sounds great to me -- disabling it seems like the best option, along > > with (if doable) marking it as "moved to the new url". As Jeroen says, > > we don't want somebody showing up and starting a google code project > > called torsocks. > > > > (I just found myself trying to help somebody on #tor with torsocks, > > and it was totally not clear to me where torsocks actually lives today.) > > With the release of the 2.0 stable version, this should be closed *ASAP*. > > Thanks! > David > > > > > Thanks! > > --Roger > > > > ___ > > tor-dev mailing list > > tor-dev@lists.torproject.org > > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > ___ > tor-dev mailing list > tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfs4proxy package in deb.tp.o
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/26/2014 7:56 PM, Lunar wrote: > s7r: >> 2. Configured some obfs4 bridges using obfs4proxy. They work >> very good, however it's a little bit complicated since package >> obfs4proxy exists in Debian sid, but not in deb.torproject.org, >> so you have to add sid repo to sources.list, install obfs4proxy >> and then make sure you edit apt preferences or comment the sid >> repo from the list in order not to upgrade you entire Debian >> system with packages from unstable/testing branch. Received >> couple of emails from users wanted to deploy obfs4 bridges and >> were confused. >> >> Is it possible to include obfs4proxy in deb.torproject.org for >> Debian > > You should now be able to get obfs4proxy by using: > > deb http://deb.torproject.org/torproject.org obfs4proxy main > > The package should work on most Ubuntu and Debian versions. It is > available for amd64 and i386. > Dear Lunar, Thank you! I can see the package in the main pool, but wanted to ask something: any reason why this is not available using: deb http://deb.torproject.org/torproject.org `$lsb_release -c` main Basically the same where Tor, tor-arm and obfsproxy are available too? > > > ___ tor-dev mailing > list tor-dev@lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUTWraAAoJEIN/pSyBJlsRyZIH/iUNG37+60MBaqDw4RvEBaVW 5VUga+zBCCyBj9kxE8i9YUNdS4sLRWFkpLFP05d/mNpGpyxL9fvQqwbhwdcOaXCT SnyCQfYnRW52BVhLM0EsuHmjGmsU9gtY2ffr7JUR4rMbTLdT2HzgLVHQ6N6coZP0 Fcgbj3Xg9wSigKS2ZxXKdeaGtmMWrHKPHGR5NFVuL8XVTWTND0g66v2uzffBjRDe JMydIhVsckvipGHJa2Cw+T3VJZUKKLcDUv8q73TrVq1nAEGdhMeGmS7t2bFej5/2 dNTgjfx/EUuOwea7jQwH0T+tY9ImAS0HLrKaaDIIYa9tqwd+qL/zbcSivLOrp5o= =AkAO -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] obfs4proxy package in deb.tp.o
s7r: > Thank you! I can see the package in the main pool, but wanted to ask > something: any reason why this is not available using: >deb http://deb.torproject.org/torproject.org `$lsb_release -c` main > > Basically the same where Tor, tor-arm and obfsproxy are available too? Because obfs4proxy is in Go and statically linked. The same package can be used on many distributions. It could not be built on every suite though, as they don't have the needed build dependencies. -- Lunar signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
