[tor-dev] ooniprobe 1.0.2 released
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. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Introduction Points and their rotation periods (was Re: Hidden Service Scaling)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/05/14 21:09, George Kadianakis wrote: It's interesting that you say this, because we pretty much took the opposite approach with guard nodes. That is, the plan is to extend their rotation period to 9 months (from the current 2-3 months). See: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/236-single-guard-node.txt I was even planning on writing an extension to rend-spec-ng.txt to specify how IPs should be picked and to extend their rotation period. That's for the same reason we do it for entry guards: Hi George, Is there an analysis somewhere of why it would be better to change IPs less frequently? I think it would be good for the performance of mobile hidden services, but I'm concerned about the attack waldo described eariler in this thread, in which a malicious IP breaks circuits until the service builds a circuit through a malicious middle node, allowing the attacker to discover the service's entry guard. Perhaps the attack could be mitigated by keeping the same middle node and IP for as long as possible, then choosing a new middle node *and* a new IP when either of them became unavailable? Then a malicious IP that broke a circuit would push the circuit onto a new IP. However, that might require all three nodes in the circuit to be picked from the high-uptime pool. Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJTb5hbAAoJEBEET9GfxSfMtwUH/jFE64dbgZAsi0QM0C5htVlU 3Wz932lW9QXYxQoPw8axPZY4WjpA/XQwp7T2CZE3vpd6zgMaRAvEvmhcyefdOkD8 fBQzaL0jBILZkbNKZKTnCAF5Te4qpg/wwAnbC1v7q2c/KS806Q6+/T0FkBTcIrib MbbHn0Cr301P1l5WMe1e7xNTArvSIiQsyVhebhNWdhbfwK20ek/YCKSdPblWVZwI WqLr/n8EWWw2OwmPBOHKl7nZHfPQ2OJ1Q0/hoAzDg0UmaQc8qBwW+k/TlfPyMVTC phRF8+9sIhVFYebXip2QKwM7sF5OL3CVMT80QJGlo6G2ADGD+9OFCUsx7oXUEjc= =u2Ph -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] Introduction Points and their rotation periods (was Re: Hidden Service Scaling)
Michael Rogers mich...@briarproject.org writes: On 10/05/14 21:09, George Kadianakis wrote: It's interesting that you say this, because we pretty much took the opposite approach with guard nodes. That is, the plan is to extend their rotation period to 9 months (from the current 2-3 months). See: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/236-single-guard-node.txt I was even planning on writing an extension to rend-spec-ng.txt to specify how IPs should be picked and to extend their rotation period. That's for the same reason we do it for entry guards: Hi George, Is there an analysis somewhere of why it would be better to change IPs less frequently? No, this analysis hasn't been done yet. I'd have to do the analysis before writing the patch to rend-spec-ng.txt and that's why I haven't written it yet. It's still unclear to me whether keeping IPs for longer periods of time is a good idea; I suggested it as a possible approach because we recently took a similar decision for guard nodes (see my previous mail). More analysis must be done. Also, note, that if the scaling ideas get implemented, the IPs become more important in the HS threat model. For example, many of the suggested scaling schemes allow the IPs to learn the number of HS nodes, or to decide which HS node should receive a given connection. I think it would be good for the performance of mobile hidden services, but I'm concerned about the attack waldo described eariler in this thread, in which a malicious IP breaks circuits until the service builds a circuit through a malicious middle node, allowing the attacker to discover the service's entry guard. I couldn't find the attack you described in this thread. This thread is quite big. However, I'm not sure how rotating IPs _more frequently_ can help against the guard discovery attack you described. It would seem to me that the contrary is true (the fewer IPs you go through, the less probability you have for one of them to be adversarial). Perhaps the attack could be mitigated by keeping the same middle node and IP for as long as possible, then choosing a new middle node *and* a new IP when either of them became unavailable? Then a malicious IP that broke a circuit would push the circuit onto a new IP. Also see https://lists.torproject.org/pipermail/tor-dev/2013-October/005621.html . Unfortunately, it seems to me that the 'virtual circuit' idea is messier than we imagine, and taking the 'guard layers' approach might be less dangerous and easier to analyze. ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] New OnionMail's fast Debian setup is out.
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 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] Finding the catch probability
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 ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Finding the catch probability
In the paper entitled *A new cell-counting-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 to find out the probability of selection of that entry node by changing the bandwidth of that node. Can anybody please tell me how to find out this graph using this simulator. Thanks, On Mon, May 12, 2014 at 11:15 AM, saurav dahal dahal.sau...@gmail.comwrote: 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 -- Saurav Dahal, Wireless communication and Networking lab, Dept. of Computer Engineering, Chosun University, 309 Pilmun-daero, Dong-gu Gwangju, 501-759 S.KOREA ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
