- tor-dev - lists.torproject.org

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

test_status.c on MSVC
by Gisle Vanem 10 May '14

10 May '14

The test/test_status.c fails to compile using MSVC since the statement: log_global_min_severity_ = LOG_DEBUG; Ref. https://gitweb.torproject.org/tor.git/commit/3ce3984772b673b82a87aded1bc8a1… This 'log_global_min_severity_' variable should not be only for GNU-C? So this patch fixed it for MSVC: --- common/torlog.h.orig 2014-05-09 23:20:36 +0000 +++ common/torlog.h 2014-05-10 13:06:15 +0000 @@ -156,9 +156,9 @@ int tor_log_get_sigsafe_err_fds(const int **out); void tor_log_update_sigsafe_err_fds(void); -#if defined(__GNUC__) || defined(RUNNING_DOXYGEN) extern int log_global_min_severity_; +#if defined(__GNUC__) || defined(RUNNING_DOXYGEN) void log_fn_(int severity, log_domain_mask_t domain, const char *funcname, const char *format, ...) CHECK_PRINTF(4,5); --gv

1 0

TBB: default setting for security.tls.version.max prevents use of TLS 1.2
by Maciej Soltysiak 09 May '14

09 May '14

Hi, It's my first post in tor ml, hope it's the right place to write this. I am using the latest TBB. The default setting for the maximum version of TLS (comming from Firefox) is TLS 1.0 (security.tls.version.max = 1) ssllabs.com tests would confirm the result: TLS 1.2 No TLS 1.1 No TLS 1.0 Yes SSL 3 Yes SSL 2 No That's not very good, considering we're aiming for the top notch security here. When I set security.tls.version.max = 3 (meaning try to negotate TLS 1.2 first) I got: TLS 1.2 Yes TLS 1.1 Yes TLS 1.0 Yes SSL 3 Yes SSL 2 No Test it out yourselves. Anyway, I would like to propose we make TBB have security.tls.vesion.max=3 to make use of TLS 1.2 Best regards, Maciej Soltysiak

2 1

OnionMail.info 1.4.4.281B is out - Nobody is forced to use 16 chacracters dot onion in the tor network!
by Liste 08 May '14

08 May '14

OnionMail (ver 1.4.4.281B) implements the new protocol VMAT: Virtual Mail Address Translator Your address 123456789abcdef.onion is translated to a normal internet mail address (mail(a)example.org) into the tor network. Update your OnionMail server: http://onionmail.info/download/ (Remeber to clear your maildir/server/feed directory before update). Source code: https://github.com/onionmail/onionmail OnionMail Paper: http://onionmail.info/paper.html Get your OnionMail here: http://louhlbgyupgktsw7.onion/reqmail.html (Require TOR). OnionMail Project http://onionmail.info

1 0

Pluggable transports meeting tomorrow (Friday 9th of May 2014)
by George Kadianakis 08 May '14

08 May '14

Hello friends, just wanted to remind you that the regular biweekly pluggable transports meeting is going to occur tomorrow at 16:00 UTC. Place is the #tor-dev IRC channel in the OFTC network. Please note that we recently *changed* the time from 17:00 to 16:00 UTC. Thanks!

1 0

Re: [tor-dev] Panopticlick summer project
by Gunes Acar 06 May '14

06 May '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry everyone for the long pause. I wrote down a proposal (and some code) to address issues raised by Mike and George: https://securehomes.esat.kuleuven.be/~gacar/summer_2014.pdf Looking for your comments and critics... On 03/21/2014 11:39 PM, Peter Eckersley wrote: > I think we're fine with open sourcing under the Affero GPLv3. > > > On Tue, Mar 18, 2014 at 12:28:12PM -0700, Mike Perry wrote: >> Yan Zhu: >>> On 03/17/2014 04:41 AM, Gunes Acar wrote: >>>> Hi Yan, >>>> >>>> Glad that you're interested in the project. It'd be very nice >>>> collaborate with you on this. >>>> >>>> Indeed, we've been corresponding with Peter for a related >>>> project and I mentioned my intention to work as a middleman >>>> between EFF and Tor. >>>> >>> >>> Great, it seems that Peter and I are both interested and >>> willing to help. >>> >>> Regarding >>> https://trac.torproject.org/projects/tor/ticket/6119#comment:10, >>> Peter says he has some reluctance to open source the project >>> (not the data) because it might make it easier for some >>> websites to track visitors without their consent. >> >> This might have been a valid concern 5 years ago, but now it's >> just a joke. The tests on Panopticlick are ancient, widely known, >> easy to reproduce, and since then much more severe and invasive >> mechanisms of fingerprinting have since been developed/deployed >> in modern browsers. >> >> Moreover, only 2 of the tests it performs actually apply to Tor >> Browser users. >> >> Banks in particular have already deployed some of the techniques >> we've fixed that the EFF study entirely predates. And these >> techniques are far higher entropy than browser resolution (such >> as localhost open port enumeration, OS theme fingerprinting, and >> HTML5+WebGL canvas rendering+extraction+hashing). >> >> Not only should we (as Tor) publicly provide tests and >> easy-to-deploy working PoC code for all of these vectors, we >> should also endeavor to detail cases where major browser vendors >> are ignoring or exacerbating this problem, and make it easy for >> everyone to test and observe this behavior themselves. >> >> Not sure if that means the EFF now has a conflict of interest >> with this project for some ridiculous reason, but frankly any >> attempt at trying to "hide" these techniques is downright silly. >> They are too well known (most are publicly documented elsewhere, >> or at least on our bugtracker), and there's waaay too much money >> on the other side of the fence in terms of incentives to develop >> and deploy working attacks. >> >> Further, starting the from EFF codebase might also be a hindrance >> to us. It is not designed for measuring the effects of defenses. >> In fact, its measurement mechanisms actively penalize any attempt >> at defense development (because any approach to alter browser >> behavior instantly makes you more unique than the previous >> userbase). >> >> I actually think Panopticlick has of late done more to prevent >> browser fingerprinting defense development than to encourage it. >> I would really like to see it DIAF. >> >> Here's hoping we can make something better! >> >> -- Mike Perry > > > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTUg4mAAoJEPb7JcMmVt4gQjwIALCsTOxvUFP3HY0N8Ap9fpKW GD193EW32X80iH6VY54AIWA29wxKaKEM4vBJBVLkhYt8s68OAqaV1vMNtmEev26h 2yg9us2HNYjBzaxFQpX7qhmDCiucpe3zVZZXq9T34OhjxscWc90JdvWA5D8Eiqto exJzqi3k5djFU66apzfFAwYpk8E0Og582XFg5TOQFYGo6LvNyT69LH7+jlNsHL65 atspVO47wKH4+0nhoG22tsMdZRzhmgSbSB1gx2a7Esf3dOBf+R0BBw+qcZptqq8Z NPyobAecQzmV/SXgjDF4PaE12A4IkK4nCWUax7ksE6YbCNhAKBlcAt+/q2JeOt8= =i+/g -----END PGP SIGNATURE-----

5 13

GSoC: Stegotorus Security enhancement
by Noah Rahman 05 May '14

05 May '14

Hi all, I'm an entering PhD student in the department of physics at Tulane University. In the past I studied chemistry at Caltech, went for a master's at UCSB, and worked in the software industry at various positions, including a stint as a contractor in Intel's Verification and Test division. This summer I will be working on refactoring Stegotorus more along DRY lines as well as enhancing and updating various handshaking protocols, and getting it ready to merge in upstream changes from its originators at SRI. My mentors this summer will be vmon and as support, Zack Weinberg (zackw) I am available on github (https://github.com/BaronWolfenstein) and via gmail (selimthegrim(a)gmail.com) Happy hacking everyone! I look forward to a long and productive summer. Best Noah Rahman

1 0

GSoC: Implement consensus diffs
by Daniel Martí 05 May '14

05 May '14

Hello everyone, My name is Daniel and this summer I'll be working on consensus diffs [0], heavily based on proposal 140 [1]. This should allow for quicker and scalable consensus udpates, which will have more weight as the consensus grows larger. I've never gotten involved in Tor before, so I'm really looking forward to this summer. My intention is to use a simplified ed format as described on proposal 140, but I am open to alternatives and suggestions. As far as the diff creation algorithm, I plan on using a dynamic programming algorithm for the Longest Common Substring problem. Like before, comments are very welcome. I will spend the following couple of weeks looking at alternative diff formats and algorithms, rather than start coding this early. It would be appreciated if any ideas regarding any of the two aspects were posed during this time, so that afterward I can start their implementation. I will always be lurking on #tor-dev, #tor-project and #tor under the nick 'mvdan'. I am also subscribed to the tor-dev and tor-talk mailing lists. And lastly, my PGP fingerprint is below - encrypted mail is welcome :) Regards. [0] https://www.torproject.org/getinvolved/volunteer.html.en#consensusDiffs [1] https://gitweb.torproject.org/torspec.git/blob_plain/refs/heads/master:/pro… -- Daniel Martí - mvdan(a)mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C

3 3

GSoC Project tor daemon mutlicore implentation
by Белоус Михаил 04 May '14

04 May '14

Hello, every body I'm a student completing my Specialist's degree in Programming Enginer at Saint-Petersburg State University and Computer Science in Computer Science Center. This summer I'm going to be working with Tor for Google Summer of Code 2014. In my project I want to implement mutlicored version of tor daemon. My mail goals is: Create tests and benchmarks for tor daemon. Implement threadpool using pthreads Using threadpool make tor faster I'll be on IRC as towelenee, in github as towelenee, and you want to contact me please write at belous.mikhail at gmail.com.

1 0