tor-dev June 2016

tor-dev@lists.torproject.org

64 participants
53 discussions

[GSoC] Tails Server - status report 3
by segfault 17 Jun '16

17 Jun '16

Hi everyone, this is the third status report on the Tails Server GSoC project. I had to omit the previous report because personal difficulties were getting in the way. So here is what I achieved in the last four weeks: * Revamp the GUI * Replace the status panel with a config panel * Add a loading window * Implement the persistence feature * Refactor the code * Many more changes in the code, you can look at my commit messages if you want more details * Keep discussing the design of the GUI on the Tails-UX mailing list The prototype is actually working now. The persistence feature works without dirty hacks now, because anonym kindly implemented a new feature in Tails' persistence (regular files can be bind-mounted now). Because Tails Server now relies on this feature, it will only work properly in this patched Tails version. I will integrate Tails Server in this branch and send a link to a nightly ISO image on tor-dev and tails-dev in the next few days, so you can test it. Next up is some more polishing of the GUI and writing a short documentation to be able to do some initial user tests. And then there are still a lot of features to implement, like autostarting the services, onion address regeneration, client authentication (not necessarily in scope of the GSoC, but I want it anyway), and many more. And I will have to refactor the code some more. Cheers!

1 0

Re: [tor-dev] [GSoC 2016] Orfox - Report 2
by Nathan Freitas 17 Jun '16

17 Jun '16

On Thu, Jun 16, 2016, at 10:37 PM, Tom Ritter wrote: > On 16 June 2016 at 18:45, Amogh Pradeep <amoghbl1(a)gmail.com> wrote: > Is a code audit the most efficient and reliable way to look for proxy > leaks? (At least at this stage?) I think he means a few things by this, or at least we have a few tasks underway: - mentor (me) reviewing code quality and implementation choices for how proxy features were added - inspection of esr45 Android Java code for new network code and other potentially leaky / deanon features - review of tor browser, noscript and other mobile relevant extensions for portability to android > I would do dynamic analysis by setting up a bridge and a proxy, > exercising lots of different functionality of the app (HTTP, HTTPS, > FTP, update checking, safebrowsing disabling/enabling, extension > installation, extension update checking, extension calls to third > party APIs, etc), and looking for any traffic not going to the single > bridge configured. We use NoRoot firewall on Android for doing this in a quick manner. It is like LittleSnitch. Thanks for the feedback Tom!

1 0

[GSoC 2016] Orfox - Report 2
by Amogh Pradeep 17 Jun '16

17 Jun '16

Hey guys, This is my second status report for GSoC 2016. I’ve finally managed to rebase things to ESR 45.2.0 :D [0]. But unfortunately, I think that what it is build on is unstable, so we don’t have an ask ready yet. I will continue to work on this, and hopefully have a successful build soon. Next up is a code audit. Once we have a stable application built on ESR 45, I can move on to the code audit phase. In this phase, I would go through the android code, looking for all the network code, and making sure that it is proxied fine. Hope you guys have a fun weekend. Best, Amogh Pradeep amoghbl1(a)gmail.com [0] https://github.com/amoghbl1/tor-browser/tree/orfox-tor-browser-45.2.0esr-6.…

2 1

GSoC: Tails Server
by segfault 14 Jun '16

14 Jun '16

Hi everyone, I'm a Tails contributor since a few months and I'm excited that I will work on the Tails Server [1] project during this year's Google Summer of Code. This project aims at providing a user-friendly interface to start onion services in Tails. My mentors are anonym (of Tails) and asn. I will start with this project four weeks early, which means I start next Monday (April 25th) and finish at the end of July. Most of the discussion on this project will happen on the appropiate Tails communication channels, i.e. the mailing lists tails-dev(a)boum.org and tails-ux(a)boum.org and the tails-dev channels on irc.oftc.net and conference.riseup.net. Regarding Tor specific questions, I will write to this list or ask in the tor channels on irc.oftc.net. I'm segfault1 on OFTC. I will send bi-weekly status reports to this list and tails-dev(a)boum.org. Cheers! segfault [1] https://tails.boum.org/blueprint/tails_server/

4 4

Error while building
by AKASH DAS 13 Jun '16

13 Jun '16

I am getting the following errors while building tor-messenger. Building project docker-image - 2c313aacbaf4 Error: Error starting remote: exec format error time="2016-06-13T02:01:24+05:30" level=fatal msg="Error response from daemon: Cannot start container ddb958b4c46730bd1173e8ee10ebbccbfe769bfff9a5042d4c7a5ac533353924: [8] System error: exec format error" any help would be greatly appreciated

2 1

Comments on Yawning's Draft proposal for Debian
by bancfc＠openmailbox.org 12 Jun '16

12 Jun '16

I thought the proposal [1] is well written but there is one major point it should include: Sometimes apt/dpkg can contain remotely exploitable bugs which s a big risk when updates are fetched over HTTP. As it happens, anyone could have been in a position to poison the update process and take over the machine because of [CVE-2014-6273] in apt-get [2]. What makes this bug crippling is that updating apt to fix it would have exposed it to what the fix was supposed to prevent. The safest option this time was to manually download the fixed package out of band. Updating from an Onion Service would protect systems from any tampering/attacks at the Exits while bringing all the usual benefits of package metadata privacy. *** While there's been some progress to setup Debian APT Onion Services [3][4], its still a long way away from being enabled as a safe default. This problem along many others summarized in the Debian wiki [5] (such as upstream patching of chatty apps that leak system information like pip [6]) would make great talking points at the next DebConf. [1] https://yawnbox.com/index.php/2016/05/03/draft-proposal-for-debian/ [2] http://security-tracker.debian.org/tracker/CVE-2014-6273 [3] http://richardhartmann.de/blog/posts/2015/08/24-Tor-enabled_Debian_mirror/ [4] http://richardhartmann.de/blog/posts/2015/08/25-Tor-enabled_Debian_mirror_p… [5] https://wiki.debian.org/TorifyDebianServices [6] https://lists.debian.org/debian-security/2016/05/msg00059.html

1 0

remotor - control console that can also notify into a chatroom
by carlo von lynX 12 Jun '16

12 Jun '16

Hi there. Here's a fine new little console-based perl script that lets you control your Tor, monitor circuits as they happen, issue commands like changing your identity etc, and forward critical events to a chatroom using the PSYC protocol. I found vidalia too heavy and arm too confusing and didn't see a simple tool that would leverage the Tor control protocol without excessive nuisances, just a bit of noise reduction and text coloring. Also I like notifications to show in my chat client. The notification feature works with a psyced running on the same host. I just committed a "remotor" chatroom which is preset to receive messages from the tool, all you need to do is install psyced and use your IRC client to join #remotor. You can git remotor and the rest of the perlpsyc library from torify git clone git://cheettyiapsyciew.onion/perlpsyc or git clone git://git.psyced.org/git/perlpsyc If you're a lucky owner of a Gentoo system, you can emerge both Net-PSYC and psyced from http://youbroketheinternet.org 's overlay. remotor should work pretty much out of the box. For a quick little glimpse into the perl script, click http://perl.psyc.eu/navigate/bin/remotor If anyone is interested, I can easily add the ability to control the Tor node from the chatroom. http://perl.psyc.eu tells you of the other tools included such as git2psyc for commit notifications in your developer chatroom, syslog2psyc, psycfilemonitor, psycmail, psycmp3... you get the idea. There's also a tarball for download, no wait, it's a zip. -- E-mail is public! Talk to me in private using encryption: http://loupsycedyglgamf.onion/LynX/ irc://loupsycedyglgamf.onion:67/lynX https://psyced.org:34443/LynX/

1 0

Bridge Directory Consensus
by Nicholas R. Parker (RIT Student) 07 Jun '16

07 Jun '16

I've got a quick question for you all. I have a functioning bridge directory authority and a bridge that's presumably pushing its descriptor to the authority (presents no error messages at all). My question is this: How do I confirm an update to the "bridge master list" on the authority? It doesn't appear on the general ip/tor/status-vote/consensus page, but that would make sense. Is there a bridge list generated to hold the descriptors? Nicholas R. Parker Rochester Institute of Technology

2 1

Paper: SoK: Towards Grounding Censorship Circumvention in Empiricism
by bancfc＠openmailbox.org 07 Jun '16

07 Jun '16

A paper presented at the Security and Human Behaviour 2016 conference examining how Tor pluggable transports old up against dozens of detection techniques. Censors focus more on detecting circumvention techniques during the setup phase than after the fact - opposite of most academic work in this area. http://internet-freedom-science.org/circumvention-survey/sp2016/sok-sp2016.…

2 1

DescripTor 1.2.0 is released
by Karsten Loesing 06 Jun '16

06 Jun '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello devs, I just released DescripTor 1.2.0: https://dist.torproject.org/descriptor/1.2.0/ - From the change log: # Changes in version 1.2.0 - 2016-05-31 * Medium changes - Include the hostname in directory source entries of consensuses and votes. - Also accept \r\n as newline in Torperf results files. - Make unrecognized keys of Torperf results available together with the corresponding values, rather than just the whole line. - In Torperf results, recognize all percentiles of expected bytes read for 0 <= x <= 100 rather than just x = { 10, 20, ..., 90 }. - Rename properties for overriding default descriptor source implementation classes. - Actually return the signing key digest in network status votes. - Parse crypto parts in network status votes. - Document all public parts in org.torproject.descriptor and add an Ant target to generate Javadocs. * Minor changes - Include a Torperf results line with more than one unrecognized key only once in the unrecognized lines. - Make "consensus-methods" line optional in network statuses votes, which would mean that only method 1 is supported. - Stop reporting "-----END .*-----" lines in directory key certificates as unrecognized. - Add code used for benchmarking. In particular the full rewrite of Javadocs was painful but hopefully useful to people here, not necessarily just DescripTor users but anyone working with Tor network data. Here's the compiled web version until DescripTor has its own website: https://people.torproject.org/~karsten/volatile/descriptor-docs-2016-05-31/ Many thanks to iwakeh for helping with most of these changes! All the best, Karsten -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJXTeNUAAoJEC3ESO/4X7XB208IAKwyJF2jgjvuREfYKkI9UFva ZoMbXgITXfTNJ4hXSc5x30jMw56xVummaWMMgBKwscPyhJAdngUjxQt//8ZOwFx/ hezHbRGxxRZquiROvIMW1mLIfnvSnkZAVL6tPuQmiKfqcR2ExMs3KCZsdCcfI/KR ZB9tHnGsSqhME+XPxQNAhT/OgBNnaq4Y7WFMhLuOHDm4/sCIjeoeix8aF1ve27ue FdOvaxjY1iBipxNdKkup5SXmL1tBmQ7bwTV59EduLatq+30tMnE7Xyat9MeQMyGI Bs9/5h+f29zREzyPp6kPd/m0eN1udvXF8nqa34QqAk0YHECE1BoIRDRo7qkixx4= =xs8m -----END PGP SIGNATURE-----

3 5

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev June 2016