[tor-dev] Attributes of Current Public Bridges
Hi everyone, Over the last few days there were a few questions raised regarding the current status of public bridges and their pluggable transports. I've written a script to gather some data points using the sanitized bridge descriptors and extrainfo documents provided on metrics.tp.o. If anyone is interested in any specific attributes then I can work on providing them. Currently the script provides the number of bridges per distinct OS (Linux, Windows, etc) and per OS version/arch (Windows 7, Windows 8, Linux i386, etc), pluggable transports per OS, number of bridges using a certain versions of Tor, number of bridges that provided contact details (useful or not), and the number of bridges that have their ExtORPort configured (but I'm not sure this is correct). Please let me know what I should add to this list. #10680 is opened for this, as well, so feel free to comment there, too. Thanks! Matt ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Unable to clone gitian-builder repository
On Mon, Jan 20, 2014 at 06:16:46PM -0500, Jacob Garber wrote: > I apologise if this doesn't belong in this list and for my inexperience. > I am trying to clone the gitian-builder repository to test out the > deterministic builds, but > I'm running into an issue: > "warning: remote HEAD refers to nonexistent ref, unable to checkout." > It creates the gitian-builder directory and a .git directory within, > but it is otherwise empty. > The command being run is: > "git clone https://git.torproject.org/builders/gitian-builder.git"; > Should I be running a different command? You need to check out the tor-browser-builder-2 branch: git clone -b tor-browser-builder-2 https://git.torproject.org/builders/gitian-builder.git If you check out /builders/tor-browser-bundle.git first, and run "make" in the gitian directory, it will tell you all the things you need to install (it's where I copied that command from). David Fifield ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Unable to clone gitian-builder repository
I apologise if this doesn't belong in this list and for my inexperience. I am trying to clone the gitian-builder repository to test out the deterministic builds, but I'm running into an issue: "warning: remote HEAD refers to nonexistent ref, unable to checkout." It creates the gitian-builder directory and a .git directory within, but it is otherwise empty. The command being run is: "git clone https://git.torproject.org/builders/gitian-builder.git"; Should I be running a different command? ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Security issue
Hello I found a security issue in Tor. With Tor Browser Bundle default settings any web-site can access to local resources by JavaScript and XMLHttpRequest. For example ANY web-site can scan local ports sending a requests to http://127.0.0.1:port and see what port is opened. For example: http://127.0.0.1:80, http://127.0.0.1:8080 and any other ports. If some application listen some port it will be able to accept connections and responce to them. If it will be a local web-server any web-site that you visit can view html-pages on it even if all external incoming connections from Internet to this port are disabled by system firewall and only local connections from 127.0.0.1 are allowed. The decision is turn on ABE (Application Boundaries Enforcer) by default in NoScript Add-On. Now it's disabled by default. After this any web-site can't get access to http://127.0.0.1:port by JavaScript and XMLHttpRequest. This rule will be added in NoScript by default if you turn on ABE: # Prevent Internet sites from requesting LAN resources. Site LOCAL Accept from LOCAL Deny If you have default settings of Tor Browser Bundle, ABE is not turned on. If so you can test what ports are opened on your computer for example here: http://tortestprivacy.url.ph/ Regards ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Allowing NAT for relay/exit nodes - Bootstrap file size
This would be a nice-to-have, but not a priority for Tor. OTOH, that functionality is more vital for i2p, who are exploring the idea of integrating into Tor's PT system: https://trac.torproject.org/projects/tor/ticket/10629 Also, right now, no PT servers can actually traverse NAT. In the future, we plan to add WebRTC capability to flashproxy, which will include NAT traversal: https://trac.torproject.org/projects/tor/ticket/5578 If you want to see it done faster, feel free to help us/them out, or find someone where I can apply for funding for it. X On 20/01/14 19:24, Juan Berner wrote: > Yes, but the point of flash proxies, is to use them as bridges, what I > meant is to allow OR's behind NAT to be relays or even exit nodes. > > > 2014/1/20 David Fifield > >> On Mon, Jan 20, 2014 at 05:00:38PM -0200, Juan Berner wrote: >>> 1) Allow NAT clients to be TOR relay nodes (even maybe exit nodes) , >> this would >>> be done using a queue system, possibly in a hidden service but not >> necessary, >>> where nat relay nodes can query what tor clients want to connect to them >> and >>> initiate the connection. This would allow more nodes in the TOR network. >> >> This is how flash proxy works. Clients register themselves as needing a >> connection, and then proxies connect to the clients. (The problem is >> that many *clients* are also behind NAT, and then it doesn't work so >> well.) >> >> You can run a flash proxy just by going to a web page like >> http://crypto.stanford.edu/flashproxy/, and there is also code to run a >> proxy in the background without a browser: >> https://trac.torproject.org/projects/tor/ticket/7944. >> >> David Fifield >> -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] txtorcon 0.9.1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I am pleased to announce that txtorcon v0.9.1 is now available. This release adds quite a few minor bug-fixes, simplifies GeoIP handling (with support for both pre- and post 0.3 pygeoip APIs), a tutorial-style walkthrough, the availability of a "wheel" distribution and uses "twine" to do the uploads (allowing me to actually test the signed tarball and whl files before uploading). Full list of improvements: * put test/ directory at the top level * using http://nedbatchelder.com/code/coverage tool instead of custom script * using coveralls.io and travis-ci.org for test coverage and continuous integration * issue #56: added Circuit.close() and Stream.close() starting from aagbsn's patch * parsing issues with multi-line keyword discovered and resolved * preserve router nicks from long-names if consensus lacks an entry (e.g. bridges) * using https://github.com/dstufft/twine for releases * "Wheel" release now also available * issue #57: "python setup.py develop" now supported * issue #59: if tor_launch() times out, Tor is properly killed (starting with pull-request from Ryman) * experimental docker.io-based tests (for HS listening, and tor_launch() timeouts) * issue #55: pubkey link on readthedocs * issue #63 * clean up GeoIP handling, and support pygeoip both pre and post 0.3 * slightly improve unit-test coverage (now at 97%, 61 lines out of 2031 missing) * added a walkthrough to the documentation sha256 sums for the distribution files: 68e21f719f6541448c0ec8e4a95787a0fe13452dd4086631ffdce79b47134e37 txtorcon-0.9.1.tar.gz b92fb5a767eeb3c3d1ec7626fb992d76c73f068e00e69bda51cdbbfc8868eba7 txtorcon-0.9.1-py27-none-any.whl Note that there are cryptographic signatures in the github repository, linked and hosted on readthedocs as well as via the hidden service. Also note that you did not miss out on 0.9.0; I screwed up the tarball upload to PyPI resulting in a signature mismatch and pypi doesn't let you re-upload a tarball. Thanks, meejah -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBAgAGBQJS3XBnAAoJEMJgKAMSgGmnkPoH+weZSVm2szTo89Z0LlL3wjdV oUFvypgvlmc6Vetf1jShpO3P31QIVtwpUsRHJPpBYxmcWuZJ2mC/CgVMiQiuHq2g tuUiYeTkwTMSiIgbnPaVqNW1ZJxNCwFulqzwZz6zy55hVCuAr2SArLPhxY4LJLWQ TWGXGbf9hO8+MlF3jYgnfbWxGfrLtmN+eUl/pbuqyicoLbHpIMF2tbdPxl4tn04/ 3yW5IOtQdSzgkI7Fhui0P88H8wyTKaijqKevSTnceSyL5q6YNuCfbm0XMq4pDuCQ ItcOtk0fgFsmfMG3Or3chRdSn+KKXBQVVRFDxafXTnDZFyOyZFxxfQaPfoB07sY= =pjAa -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] Allowing NAT for relay/exit nodes - Bootstrap file size
Yes, but the point of flash proxies, is to use them as bridges, what I meant is to allow OR's behind NAT to be relays or even exit nodes. 2014/1/20 David Fifield > On Mon, Jan 20, 2014 at 05:00:38PM -0200, Juan Berner wrote: > > 1) Allow NAT clients to be TOR relay nodes (even maybe exit nodes) , > this would > > be done using a queue system, possibly in a hidden service but not > necessary, > > where nat relay nodes can query what tor clients want to connect to them > and > > initiate the connection. This would allow more nodes in the TOR network. > > This is how flash proxy works. Clients register themselves as needing a > connection, and then proxies connect to the clients. (The problem is > that many *clients* are also behind NAT, and then it doesn't work so > well.) > > You can run a flash proxy just by going to a web page like > http://crypto.stanford.edu/flashproxy/, and there is also code to run a > proxy in the background without a browser: > https://trac.torproject.org/projects/tor/ticket/7944. > > David Fifield > ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Allowing NAT for relay/exit nodes - Bootstrap file size
On Mon, Jan 20, 2014 at 05:00:38PM -0200, Juan Berner wrote: > 1) Allow NAT clients to be TOR relay nodes (even maybe exit nodes) , this > would > be done using a queue system, possibly in a hidden service but not necessary, > where nat relay nodes can query what tor clients want to connect to them and > initiate the connection. This would allow more nodes in the TOR network. This is how flash proxy works. Clients register themselves as needing a connection, and then proxies connect to the clients. (The problem is that many *clients* are also behind NAT, and then it doesn't work so well.) You can run a flash proxy just by going to a web page like http://crypto.stanford.edu/flashproxy/, and there is also code to run a proxy in the background without a browser: https://trac.torproject.org/projects/tor/ticket/7944. David Fifield ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Allowing NAT for relay/exit nodes - Bootstrap file size
Hi, Im wondering if you have considered this, I haven't seen it anywhere: 1) Allow NAT clients to be TOR relay nodes (even maybe exit nodes) , this would be done using a queue system, possibly in a hidden service but not necessary, where nat relay nodes can query what tor clients want to connect to them and initiate the connection. This would allow more nodes in the TOR network. 2) Reduce the bootstrap file size clients download. An increase in nodes would increase the file, roughly 1.5mb right now, this file could be decreased to 10k if clients would first download a list of hashes that identify each OR, then they choose randomly and retrieve from the directory the information for each of the hashes they choose. This would be a temporary way to start connections while the real bootstrap file is being downloaded. It would only benefit those clients with slow connections. Thanks ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Projects to combat/defeat data correlation
On Mon, Jan 20, 2014 at 05:30:27PM +0100, Philipp Winter wrote: > On Sat, Jan 18, 2014 at 01:40:43AM +, Matthew Finkel wrote: > > obfs3 is supposed to be fairly difficult to detect because entropy > > estimation is seemingly more difficult than typically assumed, > > and thus far from what has been seen in practice this seems to be true. > > There's a recent paper which covers that topic [1]. While entropy estimation > is certainly more expensive than, say, counting packet sizes, it's probably > not > out of reach for well-equipped boxes. I think (we should expect that) entropy detection is one of the standard tools in the DPI toolkit. obfs3 isn't meant to be secure "because nobody can tell there's a lot of entropy". It's meant to drive up the risk of false positives -- if you cut all flows that have a lot of entropy, what else do you cut besides obfs2 and obfs3? And even if you're convinced it's a worthwhile risk now, are you convinced the background traffic won't change in the future? That's why pairing obfs3 with something that modifies packet volume (and maybe timing) is important -- otherwise more complex DPI rulesets can look not just for entropy, but also for underlying hints that it's the Tor protocol underneath, and then reduce their false positive rates. It also explains why the most effective attacks against obfs2 and obfs3 involve detecting that it "might" be obfs traffic, and then doing some follow-up checking to get more confidence. --Roger ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Projects to combat/defeat data correlation
On Sat, Jan 18, 2014 at 01:40:43AM +, Matthew Finkel wrote: > obfs3 is supposed to be fairly difficult to detect because entropy > estimation is seemingly more difficult than typically assumed, > and thus far from what has been seen in practice this seems to be true. There's a recent paper which covers that topic [1]. While entropy estimation is certainly more expensive than, say, counting packet sizes, it's probably not out of reach for well-equipped boxes. [1] http://cs.unc.edu/~amw/resources/opaque.pdf Cheers, Philipp ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Projects to combat/defeat data correlation
On Mon, Jan 20, 2014 at 08:30:12AM -0500, Ian Goldberg wrote: > On Sat, Jan 18, 2014 at 01:40:43AM +, Matthew Finkel wrote: > > obfs3 is supposed to be fairly difficult to detect because entropy > > estimation is seemingly more difficult than typically assumed, > > and thus far from what has been seen in practice this seems to be true. > > Wouldn't the way to detect obfs3 be to look at packet sizes, not > contents? obfs3 doesn't hide those at all, right? Yes, obfs3 doesn't hide packet sizes. As a result, Tor over obfs3 results in packets which are multiples of Tor's 512-byte cells (excluding TLS headers). Cheers, Philipp ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] A threshold signature-based proposal for a shared RNG
On Fri, Jan 17, 2014 at 10:01:13PM -0600, Nicholas Hopper wrote: > > Yes: Nick (who would probably be the one writing the code anyway) > > generates the shares encrypted to keys generated by the authority > > operators, sends them to the authority operators, and forgets the > > intermediate results. ;-) (Only partially kidding.) > > Ha! Yes, byzantine agreement is much easier with a trusted party. :) > > > Then again, if *that* code is written, then just having each authority > > operator run an instance of that code in the role of Nick, and having > > everyone add their results, works fine if everyone is online. It's also > > easy to check that the protocol succeeeded, by interpolating the > > resulting public keys. An actively malicious adversary during this > > phase would cause the protocol to fail, but I think it would be good to > > know that we have an actively malicious authority. ;-) > > Let's call this the "optimistic approach", and it would certainly be > an option, although one issue is that when it fails we can say that > someone is malicious but not which authority(s). Although one > possibility is to have the ability to fall back to a full > byzantine-tolerant protocol in that event. Actually, I think the above "optimistic" protocol _would_ let you identify the misbehaving party if each message is signed by its sender. - Ian ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Projects to combat/defeat data correlation
On Sat, Jan 18, 2014 at 01:40:43AM +, Matthew Finkel wrote: > obfs3 is supposed to be fairly difficult to detect because entropy > estimation is seemingly more difficult than typically assumed, > and thus far from what has been seen in practice this seems to be true. Wouldn't the way to detect obfs3 be to look at packet sizes, not contents? obfs3 doesn't hide those at all, right? - Ian ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] IRC meeting on Wed, Jan 22, 18:00 UTC to discuss next steps for Weather rewrite
Hi devs, we're going to have an IRC meeting to discuss next steps for the Weather rewrite: Wednesday, January 22, at 18:00 UTC in #tor-dev on OFTC. http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140122T18 Everyone's invited to join the discussion. Abhiram, Norbert, and Oliver, who all stated their interest in the Weather rewrite, already indicated that they're going to be there. Possible topics are: briefly introduce ourselves, identify open tasks, assign tasks for the next week, talk about infrastructure that would make us more productive, etc. All that shouldn't take longer than 30--45 minutes. If people want to read up on what this is all about, here are two URLs to start with: https://trac.torproject.org/projects/tor/wiki/doc/weather-in-2014 https://gitweb.torproject.org/weather.git/blob/HEAD:/doc/design.txt Talk to you on Wednesday! All the best, Karsten ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
