- tor-dev - lists.torproject.org

Hidden Service Scaling
by Christopher Baines 14 May '14

14 May '14

I have been looking at doing some work on Tor as part of my degree, and more specifically, looking at Hidden Services. One of the issues where I believe I might be able to make some progress, is the Hidden Service Scaling issue as described here [1]. So, before I start trying to implement a prototype, I thought I would set out my ideas here to check they are reasonable (I have also been discussing this a bit on #tor-dev). The goal of this is two fold, to reduce the probability of failure of a hidden service and to increase hidden service scalability. I think what I am planning distils down to two main changes. Firstly, when a OP initialises a hidden service, currently if you start a hidden service using an existing keypair and address, the new OP's introduction points replace the existing introduction points [2]. This does provide some redundancy (if slow), but no load balancing. My current plan is to change this such that if the OP has an existing public/private keypair and address, it would attempt to lookup the existing introduction points (probably over a Tor circuit). If found, it then establishes introduction circuits to those Tor servers. Then comes the second problem, following the above, the introduction point would then disconnect from any other connected OP using the same public key (unsure why as a reason is not given in the rend-spec). This would need to change such that an introduction point can talk to more than one instance of the hidden service. These two changes combined should help with the two goals. Reliability is improved by having multiple OP's providing the service, and having all of these accessible from the introduction points. Scalability is also improved, as you are not limited to one OP (as described above, currently you can also have +1 but only one will receive most of the traffic, and fail over is slow). I am aware that there are several undefined parts of the above description, e.g. how does a introduction point choose what circuit to use? but at the moment I am more interested in the wider picture. It would be good to get some feedback on this. 1: https://blog.torproject.org/blog/hidden-services-need-some-love 2: http://tor.stackexchange.com/questions/13/can-a-hidden-service-be-hosted-by…

11 44

Installing obfsproxy from wheezy-backports
by irregulator＠riseup.net 14 May '14

14 May '14

Hello there, tl;dr obfsproxy from wheezy-backports raises exception about not finding Twisted although Twisted-core is installed. I want to install obfsproxy from wheezy-backports on a wheezy machine. The package currently in wheezy-backports [1] depends on : python (>= 2.7), python (<< 2.8), python-pkg-resources, python-crypto, python-twisted-core (>= 13.2) After installation i get: $ obfsproxy Traceback (most recent call last): File "/usr/bin/obfsproxy", line 5, in <module> from pkg_resources import load_entry_point File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2707, in <module> working_set.require(__requires__) File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 686, in require needed = self.resolve(parse_requirements(requirements)) File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 584, in resolve raise DistributionNotFound(req) pkg_resources.DistributionNotFound: Twisted obfsproxy explicitly requires twisted: $ cat /usr/lib/python2.7/dist-packages/obfsproxy-0.2.7.egg-info/requires.txt PyCrypto Twisted argparse pyptlib >= 0.0.5 pyyaml But in /usr/lib/python2.7/dist-packages/ there is only: twisted Twisted_Core-13.2.0.egg-info Meaning obfsproxy doesn't seem to find Twisted, cause there is no Twisted*.egg-info in dist-packages/ directory. Interestingly obfsproxy wheezy package from deb.torproject.org [2] depends on : python (>= 2.7), python (<< 2.8), python-pkg-resources, python-crypto, python-twisted, python-pyptlib (>= 0.0.4), python-yaml (The same goes for obfsproxy in debian testing.) Notice it's 'python-twisted' and not 'python-twisted-core'. So the package from deb.torproject ends up installing a Twisted*.egg-info in /dist-packages and obfsproxy does not complain. So i'm wondering, is this a bug? Should i file a debian bug for the debian package in wheezy-backports? Does obfsproxy need all of twisted dependencies or 'python-twisted-core' suffices? If the latter how may we fix the original exception? Cheers, Alex [1]: https://packages.debian.org/wheezy-backports/obfsproxy [2]: https://deb.torproject.org/torproject.org/dists/wheezy/main/binary-amd64/Pa…

2 2

[PATCH] Fix minor typos in tor-spec.txt
by Martin Kepplinger 13 May '14

13 May '14

--- feel free to ignore this. I don't know if you take typo fixes. But why not report them while reading. thanks, martin tor-spec.txt | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/tor-spec.txt b/tor-spec.txt index 2555af4..86ee849 100644 --- a/tor-spec.txt +++ b/tor-spec.txt @@ -501,7 +501,7 @@ see tor-design.pdf. highest number contained both in the VERSIONS cell they sent and in the versions cell they received. If they have no such version in common, they cannot communicate and MUST close the connection. Either party MUST - close the connection of the versions cell is not well-formed (for example, + close the connection if the versions cell is not well-formed (for example, if it contains an odd number of bytes). Since the version 1 link protocol does not use the "renegotiation" @@ -648,8 +648,8 @@ see tor-design.pdf. To check the AUTHENTICATE cell, a responder checks that all fields from TYPE through TLSSECRETS contain their unique correct values as described above, and then verifies the signature. - signature. The server MUST ignore any extra bytes in the signed - data after the SHA256 hash. + The server MUST ignore any extra bytes in the signed data after + the SHA256 hash. Initiators MUST NOT send an AUTHENTICATE cell before they have verified the certificates presented in the responder's CERTS @@ -751,7 +751,7 @@ see tor-design.pdf. another, it chooses from only one half of the possible values based on the ORs' public identity keys. In link protocol version 3 or lower, if the sending node has a lower key, it chooses a CircID with - an MSB of 0; otherwise, it chooses a CircID with an MSB of 1. (Public + a MSB of 0; otherwise, it chooses a CircID with a MSB of 1. (Public keys are compared numerically by modulus.) In link protocol version 4 or higher, whichever node initiated the @@ -1087,7 +1087,7 @@ see tor-design.pdf. bytes sent between Alice and Bob (assuming Alice was not already connected to Bob.) - To prevent this, when an OR we gets an extend request, it SHOULD use an + To prevent this, when an OR gets an extend request, it SHOULD use an existing OR connection if the ID matches, and ANY of the following conditions hold: - The IP matches the requested IP. -- 1.7.10.4

1 0

Missing days in "Bridge users by transport"
by David Fifield 13 May '14

13 May '14

Do you know what is the cause of the missing data between April 14 and April 22 in this graph? I'd like to be able to account for it when I present the graph. https://metrics.torproject.org/users.html?graph=userstats-bridge-transport&… I don't suppose it is a problem with the bridge, because other transports show the same gap. https://metrics.torproject.org/users.html?graph=userstats-bridge-transport&… https://metrics.torproject.org/users.html?graph=userstats-bridge-transport&… David Fifield

2 1

Finding the catch probability
by saurav dahal 13 May '14

13 May '14

In the paper "A New Cell Counter Based Attack Against Tor, Zhen Ling, Junzhou Luo, Wei Yu, Xinwen Fuz, Dong Xuan, Weijia Jia", in Fig. 9, Catch probability graph is drawn. I am interested in finding out this graph using "Shadow Simulator" as a part of my project in graduate studies. Can anybody please tell me how to find out this graph using this simulator. Thanks, -- Saurav

2 3

GSoC: Ahmia.fi - Search Engine for Hidden Services
by Juha Nurmi 13 May '14

13 May '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I'm a student who is starting to work with ahmia.fi search engine as a part of Google Summer of Code. :) The proposal is online here https://ahmia.fi/gsoc/ In practise, I have now time and funding to develop my search engine. George is my primary mentor and Moritz the backup mentor. Today, I will submit all the required documents (the tax forms etc.) to Google. After that, I think I will speed up with code base in the GitHub :) Cheers, Juha -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTViWUAAoJELGTs54GL8vAuC8H/jSdgBCRQM/3l3mX5Uig9fgM wacPsxm6RJd3Sw+JJpYgoRP1nDqI513haP4Z6s//tR3Vn5RyQ/u7ik3QdFEVKbJD KqnQ4Eaf5hT4xsJwBXZIjzW6uhbYaq1GmUJi4eaglwUrgIgJrHzDbOz/p8q71O1z rLnrS1vrsvMzY4rU0dRe1/S9LyPWTUAfpVMINa54RPmNjMzrTT/WUnlcQWo9cY3a SRrT2MVz5nwBEXJuhZUmC3L6XLL8RX2TgzGwVyYOUfMlNuZdcSaOOTvF7gKVZVZQ hGhr/V40iNm5BOAcQ2TVaxuR5HjxSFWUp15T8ux+xxyN/Yp9EeaDjsAsTVegq0w= =QMfR -----END PGP SIGNATURE-----

2 5

BridgeDB's email server rewrite; NEED CODE REVIEW
by isis 12 May '14

12 May '14

Hi everyone! If someone who is comfortable with Twisted Python and SMTP could look over my rewrite of BridgeDB's email servers, that would be great! The servers currently "online" (they are mostly down, and they keep falling over) had so many bugs that I spent a week and a half trying to stabilise them. Then I spent a mere day and a half rewriting them completely, fixing the following bugs: #5463 #7547 #7550 #8241 #11475 #11753, among others. The relevant branch is my `fix/5463-7547-7550-8241-11475-11753-email-rewrite` branch, [0] and most of the new code can be found in the `lib/bridgedb/email` tree. [1] The relevant ticket for providing feedback would be #5463, where most of the discussion is happening. [2] Since I've already waited about a week for review, and the servers are currently broken and people are complaining at me a lot, I'm giving y'all 48 hours to speak up, else forever hold your pisces. Thanks in advance for reviewing! :) [0]: https://gitweb.torproject.org/user/isis/bridgedb.git/shortlog/refs/heads/fi… [1]: https://gitweb.torproject.org/user/isis/bridgedb.git/tree/refs/heads/fix/54… [2]: https://trac.torproject.org/projects/tor/ticket/5463 -- ♥Ⓐ isis agora lovecruft _________________________________________________________ GPG: 4096R/A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt

1 0

New OnionMail's fast Debian setup is out.
by Liste 12 May '14

12 May '14

There is an easy way to install OnionMail on debian: The first setup package 1) Download the package at http://onionmail.info/download/onionmail-debian-setup-all.tar.gz 2) Execute the following command ./setup.sh http://onionmail.info/setup.html Video tutorial: https://www.youtube.com/watch?v=PcOmvFxi4P4

1 0

ooniprobe 1.0.2 released
by Arturo Filastò 11 May '14

11 May '14

We are pleased to announce that ooniprobe 1.0.2 has been released. It includes a series of bugfixes and improvements including: * Add ooniprobe manpage. * Fix various security issues raised by the least authority audit. * Add a test that checks for Tor bridge reachability. * Record the IP address of the exit node being used in torified requests. * Captive portal test now uses the ooni-probe test templates. * Have better test naming consistency. You may download it from pypi here: https://pypi.python.org/pypi/ooniprobe/1.0.2 Soon the debian package for it will also be updated. Have fun, ~ Art.

2 1

fteproxy 0.2.14 released (resolves ticket #11629)
by Kevin P Dyer 11 May '14

11 May '14

Hi George, I've released version 0.2.14 of fteproxy [1], with corresponding changes [2] to the Tor Browser. This release addresses ticket #11629 [3], thanks to Yawning's patch [6]. My changes [2] to the tor-browser-bundle include the following: - Updated fteproxy to 0.2.14 - Updated obfsproxy to 0.2.9 - Changed versions.nightly tag to "master" for fteproxy and obfsproxy - The fte python module (the FTE cryptographic primitive) is now a separate project [4,5] as of fteproxy 0.2.14. This is reflected in the build process. I've tested these changes and they resolve #11629 on Windows/LInux/OSX. Would be great if you could test this, too. As discussed in the PT meeting on Friday, from 0.2.14 I will treat fteproxy master as stable and perform all development on a separate branch. Changes that break the tor-browser-bundle will be pushed to master only when there is a correspond tor-browser update. Hopefully, this should resolve the issue of fteproxy breaking the nightly TBB build. Thanks! -Kevin [1] https://github.com/kpdyer/fteproxy/releases/tag/0.2.14 [2] https://github.com/kpdyer/tor-browser-bundle [3] https://trac.torproject.org/projects/tor/ticket/11629 [4] https://pypi.python.org/pypi/fte [5] https://github.com/kpdyer/libfte [6] https://github.com/kpdyer/fteproxy/commit/0f7f68d01b133f7d61bd3ad239af89021…

1 0