tor-dev

tor-dev@lists.torproject.org

3581 discussions

Collecting data to demonstrate TCP ISN-based port knocking
by Julian Kirsch 14 May '14

14 May '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, some of you might remember a project called "Knock", which implements a variant of port-knocking in the Linux kernel that can be used to check the authenticity of arbitrary TCP connections and even can do integrity checking of the TCP payload by using a pre-shared key. Knock started as a student project which was presented during the Tor developer meeting at Technische Universität München last July. This was also where Jake added his two cents to help the project to move on. We still hope that Knock will be eventually useful for Tor (think: bridges), but could use your help to collect data to help convince the Linux people to adopt the latest patch. As Knock uses two fields in the TCP header in order to hide information and we explicitly want to be compatible with machines sitting in typical home networks, we need to make sure that this information doesn't get corrupted by the majority of NAT boxes out there. We thus created a program which tests if Knock would work in your environment. It would be great if some of you were able to execute the program on your machines in order to help us to get an estimation of if Knock one day could be used in a large scale. You can find sources, binaries and a more elaborate description here: https://gnunet.org/knock_nat_tester Technical details about Knock and a (somewhat outdated) research paper as well as kernel patches are provided here: https://gnunet.org/knock Best, Julian -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJTc+ytAAoJENwkOWttRRA4X/MH/3rDq/szoRTxQDNa8TlBQqNv 3Lcsze55XTpaYY2k9gwK5lKUXar4Ngy6v4i+SOjSrC/gZur5j/g/8LhKy5XdvHdl zXXV2+3ubkK+lWzOq0JP3rJ8lKDAW3Lor0EnVEmZv45+fpgQIbyTKvmEUaiU0l5l A10wDsXjvWTApl+S52pga2qK0g397hn+Y99843PRl8KSxpFDP0t4vTBYBZmLYbMT o7rfoe5BiUtogAgvLdlJ4GlQUrHiH4s6QyQb5/obcGBaN1V8ydkjH0pw6yHR4PTD D5IB7ZYadwi+9k1UyQbAwTCs9+6omiPzN0ugeTdcffzQio2eZUzPOQPyS9vRPwM= =gXcK -----END PGP SIGNATURE-----

1 0

Torsocks 2.x status report
by David Goulet 14 May '14

14 May '14

Hi everyone! Took me a while to do it but there it is! For those not following torsocks development, this is a status report of the project. As of April 4th 2014, the release candidate 7 was released. With that release, the main code is now on torproject.org which is now the official upstream of the project. https://gitweb.torproject.org/torsocks.git My Github repository[1] is now a mirror and all tickets from the tracker have been moved to trac.torproject.org. We are still looking for some more Signed-off or/and Acked-by volunteers that want to have a look at the code. With that, 2.0 stable will be released and from there we'll start adding features! :) Thanks to intrigeri and Lunar, you can find the new version in Debian experimental by now. https://packages.debian.org/experimental/torsocks I plan to update the Tor wiki[2][3] with that new version, create a FAQ and a blog post explaining the Why/How of torsocks 2.0. Finally, the old page should be close soon (hopefully) thus moving everything back to torproject.org. https://code.google.com/p/torsocks/ That's about it, again please test and review it to help out :). Cheers! David [1] https://github.com/dgoulet/torsocks [2] https://trac.torproject.org/projects/tor/wiki/doc/torsocks [3] https://trac.torproject.org/projects/tor/wiki/doc/TorifyHOWTO

1 0

[PATCH] torspec: fix typos
by Martin Kepplinger 14 May '14

14 May '14

2 1

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 13 May '14

13 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 12 May '14

12 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev