- tor-dev - lists.torproject.org

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

Whonix's help_check_tor_bootstrap.py
by Damian Johnson 03 May '14

03 May '14

Hi adrelanos, I just noticed that Whonix uses Stem. That's great! Just a few quick thoughts... https://github.com/Whonix/Whonix/blob/master/whonix_shared/usr/lib/whonixch… > with Controller.from_port(port = p) as controller: > > if os.path.exists("/usr/share/whonix/whonix_gateway"): > controller.authenticate("password") You always need to authenticate the controller. Tor will balk if you omit the authenticate() call, even if it isn't using authentication... >>> from stem.control import Controller >>> c = Controller.from_port() >>> c.get_info('version') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "stem/control.py", line 960, in get_info raise exc stem.ProtocolError: GETINFO response didn't have an OK status: Authentication required. You should probably change this to... with Controller.from_port(port = p) as controller: controller.authenticate() There also isn't a reason to pass in 'password' unless you're actually using that as your controller password. ;) > b = bootstrap_status.split( ) > progress = b[2] > progress_percent = ( progress.split( "=" ) )[1] > exit_code=int(progress_percent) Operating by the positional argument is fine, but a little risky since Tor is perfectly allowed to rearrange those. I'd suggest the following instead... match = re.match('.* PROGRESS=([0-9]+).*', line) if match: exit_code = int(match.group(1)) Cheers! -Damian

2 3

Trac accounts and potential account compromise
by Erinn Clark 02 May '14

02 May '14

Dear Tor Trac users, We learned on recently that there was a bug in our Trac setup that allowed anyone to register a new user account for an existing user name, overwriting the existing user's password and thereby taking over the account [0]. A workaround was quickly implemented by weasel to prevent new user registration while we investigated how to re-enable it without encountering this problem again. Soon after, our configuration was fixed to allow new registrations without overwriting existing usernames. However, it's still possible that somebody has taken over your account in the past and you didn't notice because you didn't log in recently. We recommend users try to login and if you find you are unable to do so, you can reset your password here: https://trac.torproject.org/projects/tor/reset_password We apologize for any inconvenience this may have caused you! Please feel free to contact me with any questions. Erinn & the rest of the Tor Trac team

1 1

GSoC Project: A Lightweight Censorship Analyzer for Tor
by Jacob H. Haven 02 May '14

02 May '14

Hi Everyone, I'm a student completing my Bachelor's degree in Computer Science at Stanford. This summer I'm going to be working with Tor for Google Summer of Code 2014. I'll be packaging a tool to allow non-technical users to monitor censorship of Tor occurring in their country/network My project based on Phillip Winter's paper "Towards a Censorship Analyser for Tor" <http://www.cs.kau.se/philwint/pdf/foci2013.pdf> [1], and design requirements described in [2]. My main goals being to: - Implement a number of tests using OONI [3] Including reachability to directory authorities, the torproject.org, bridges.torproject.org and relays - Bundle tests into small binary that is easy to distribute and run - With user's consent, transmit (anonymized) data back to Tor Project - Leave no trace of use on user machine after tool removal. Obfuscate network traffic to attempt to hide analysis. - Produce user-friendly output so non-technical users gain better understanding of why Tor connections failing and perhaps possible remedies I'll be on IRC as jhaven, as QuicksilverJohny on GitHub<https://github.com/QuicksilverJohny>, and available via email at jacob(a)jhaven.me. Thanks to Philipp (phw) and Art (hellais) for helping me as mentors over the summer! [1] http://www.cs.kau.se/philwint/pdf/foci2013.pdf [2] https://research.torproject.org/techreports/censorship-analysis-tool-2013-0… [3] https://ooni.torproject.org/ ————————— Jacob H. Haven – http://jhaven.me <http://jhaven.me/> jacob(a)jhaven.me jhaven(a)cs.stanford.edu +1-(949)-415-6469

1 0