- tor-dev - lists.torproject.org

Re: [tor-dev] tor-dev Digest, Vol 66, Issue 7
by Nathan Kettle 07 Jul '16

07 Jul '16

unsubscribe me please On Wed, Jul 6, 2016 at 10:00 PM, <tor-dev-request(a)lists.torproject.org> wrote: > Send tor-dev mailing list submissions to > tor-dev(a)lists.torproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > or, via email, send a message with subject or body 'help' to > tor-dev-request(a)lists.torproject.org > > You can reach the person managing the list at > tor-dev-owner(a)lists.torproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of tor-dev digest..." > > > Today's Topics: > > 1. Re: Adding depictor/stem to Jenkins (Tom Ritter) > 2. Re: GeoLite ASN Database broken (Jason Ketola) > 3. Re: GeoLite ASN Database (still) broken (nusenu) > 4. Re: GeoLite ASN Database (still) broken (Jason Ketola) > 5. Re: [network-team] [doodle poll] Meeting to discuss guard > proposal draft status (isis agora lovecruft) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 5 Jul 2016 14:48:43 -0500 > From: Tom Ritter <tom(a)ritter.vg> > To: tor-dev(a)lists.torproject.org > Subject: Re: [tor-dev] Adding depictor/stem to Jenkins > Message-ID: > < > CA+cU71mHtgMRnfq3F51U+MTTDs9V9ySHgUfeyHWZ3gntuRf5eQ(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 5 July 2016 at 14:34, Damian Johnson <atagar(a)torproject.org> wrote: > > Hi Tom, just food for thought but another option would be a cron task > > that pulls the repos and runs that if there's a change. That's what I > > do for stem's website so it reflects the changes I push. > > I think that's a good model for webpages-backed-by-git, but less so > for integration/software testing. > > I could probably rig something up like that locally, but I'd have to > make it detect a crash and email me. The advantage of jenkins is it > will do that automatically, on infrastructure I don't have to worry > about maintaining[0], as well as making the crash details public. > There's a chance it might even detect a break in stem. > > -tom > > [0] A problem I've had a lot is that my 'email me stuff' scripts will > stop emailing... and I never find out they're failing! > > > ------------------------------ > > Message: 2 > Date: Tue, 5 Jul 2016 17:40:20 -0400 > From: Jason Ketola <jketola(a)maxmind.com> > To: tor-dev(a)lists.torproject.org > Subject: Re: [tor-dev] GeoLite ASN Database broken > Message-ID: > <CADrFj5Aw7b0SVMmo=M33-+zdHOUKbrNr= > p3zs4crUj_067agsw(a)mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hello, > > I'm writing on behalf of MaxMind. We believe we have addressed the issues > you noted in the latest update of our GeoLite ASN database: > http://dev.maxmind.com/geoip/legacy/geolite/#Downloads. > > Thank you for bringing the issues to our attention. > > Regards, > Jason > > -- > Jason Ketola > Vice President, Operations > MaxMind, Inc. > www.maxmind.com > 617-500-4493 x807 >

1 0

Torsocks workalikes
by grarpamp 06 Jul '16

06 Jul '16

I remember a survey list of torsocks workalikes somewhere (where?). This one's for windows and I don't remember it. Whoever maintains that list can add it for reference. https://github.com/cpatulea/TorCap2

1 0

Re: [tor-dev] GeoLite ASN Database broken
by Jason Ketola 06 Jul '16

06 Jul '16

Hello, I'm writing on behalf of MaxMind. We believe we have addressed the issues you noted in the latest update of our GeoLite ASN database: http://dev.maxmind.com/geoip/legacy/geolite/#Downloads. Thank you for bringing the issues to our attention. Regards, Jason -- Jason Ketola Vice President, Operations MaxMind, Inc. www.maxmind.com 617-500-4493 x807

2 2

Adding depictor/stem to Jenkins
by Tom Ritter 05 Jul '16

05 Jul '16

Hi all, Hoping someone can help me out here... I'd like to add a job to jenkins that runs the depictor command (`python write_website.py`) whenever a commit is made to the dev repo master branch[0] OR stem's master branch. (If I could only have one I'd pick stem's.) Historically, one of the reasons consensus-health has lagged a little bit has been because in the past there was some tiny change in Stem that wound up breaking it. I don't think that's happened lately, but it's caused me to be conservative about upgrading stem, and usually the changes I need are the latest one added to master. A jenkins job would give me a bit more confidence and enable a bit more proactivity on fixing it for breaking changes. Who runs jenkins? What would I need to do to set this up? The good news is there's only three commands needed to go from zero to index.html: git clone https://git.torproject.org/user/tom/depictor.git cd depictor git clone https://git.torproject.org/stem.git ./write_website.py -tom [0] https://gitweb.torproject.org/user/tom/depictor.git/

2 2

A meta-package for Pluggable Transports?
by Nima Fatemi 05 Jul '16

05 Jul '16

It’s currently difficult for bridge operators to keep up with the changes in pluggable transports world. You’ve to be following tor development and censorship-war very closely to know which transport is needed currently and how to run them. There are many people who are still running vanilla bridges thinking they’re helping people in censored networks. Unfortunately those bridges are not anyone any good while burning operator’s resources. After some discussion on #tor-project a little while ago, the idea of having a meta-package that includes all or the most recent transports came up. Where people would install this meta package and it would automatically take care of the required steps to get the latest obfsproxy and set it up. From a UX perspective, ideally you’d set up a bridge with small and consistent steps like this: $ sudo apt-get install tor-bridge $ tor-bridge —-setup OR $ tor-bridge-setup and then it will automatically get the most recommended PT (eg obfs4), tor itself (if not installed), config your torrc, do a reachability test, publish the bridge to bridgdb automatically and give you the result in stdout: # Congrats! your bridge is up and running on $port # Your bridge is published in BridgeDB. # Thanks for fighting censorship! Additionally we can have more flags for different transports, ip, port and so on. For example if you want to run obfs4proxy on an specific port and not publish it, I imagine running something like this should get you there: $ tor-bridge-setup —-private —-obfs4 —-ip 1.2.3.4 —-port 5000 # Congrats! your bridge is up and running on port 5000 # You have chosen to not to publish your bridge. Users would need to manually copy and paste the following line in their Tor Browser to use your bridge. # # bridge obfs4 1.2.3.4:5000 C73ADBAC8ADFDBF0FC0F3F4E8091C0107D093716 cert=gEGKc5WN/bSjFa6UkG9hOcft1tuK+cV8hbZ0H6cqXiMPLqSbCh2Q3PHe5OOr6oMVORhoJA iat-mode=0 The purpose of this email is to see whether this is a good approach (if not, how can we improve it), and what is needed to move towards it. Feedback from everyone, specially packagers and relay operators are encouraged and welcome :) Best, -- Nima 0X58C4B928A3E218F6 | @mrphs "I disapprove of what you say, but I will defend to the death your right to say it" --Evelyn Beatrice Hall

5 9

Re: [tor-dev] A meta-package for Pluggable Transports?
by Valentin Sundermann 05 Jul '16

05 Jul '16

> I've heard that the Chinese government tests suspected bridges by > attempting to connect to them and seeing if they respond to the Tor > protocol. Whether China is actually doing this or not, it would not be a > terribly difficult thing for any competent censor to do. It was probably the talk from Philipp Winter at the 32c3. Just for reference on this list or people who find it interesting. I think there is no general answer for what should be the default config/setup for a bridge. Maybe a (ncurses) menu at the install would be the best. The menu could inform new bridge operators about what is good/bad and why or even what types of proxies are currently needed more. Or provide at least a link to a wiki article (which should be written :)) [1] https://media.ccc.de/v/32c3-7196-how_the_great_firewall_discovers_hidden_ci…

1 0

Fingerprint Central - Testers needed!
by Pierre Laperdrix 05 Jul '16

05 Jul '16

Hi everyone, As part of my GSOC project, the beta for Fingerprint Central is finally live! Here is the link: https://fpcentral.irisa.fr For the moment, we are interested in testing the core feature of the project which is the collection of fingerprints. Other features are in development and will be added when they are ready (notably, the statistics page). There are two main pages available now: - "View my fingerprint": On this page, you can execute the tests that have been added in Fingerprint Central. If you have JavaScript enabled, you can use the Dashboard to see the generated data and review them before you send it to our server. The "%" column indicates the percentage of collected fingerprints that share the same value as you. - "Tor": This page will give you several advice related to Tor guidelines and will try to detect the level of your security slider. We are interested in feedback and bug reports! If you feel something is missing or is not right, tell us so that we can improve the website. Unfortunately, we don't have data to correctly kickstart the database so the percentage shown to the first users won't be really interesting. Thanks in advance for your help! Pierre

1 0

Re: [tor-dev] [GSoC] CONIKS for Tor Messenger - status report #3
by Huy Vu Quoc 03 Jul '16

03 Jul '16

Hi everyone, This is my third status report on the CONIKS for Tor Messenger project. These are things that I have been doing in the last two weeks: 1. Continue implementing the Merkle prefix tree module. Currently, the STR source code are under review. This module takes a lot of time since it is probably the biggest components. There are a lot of discussions over the development to make sure everything is on right track (e.g. the proof of absence …) 2. Continue working on libconiks library. This library currently consists of several modules: - CONIKS server construction from config file - TLS socker listener - Request handler I submitted a pull request for the registration implementation [1]. 3. Registration implementation (Tor Messenger-specific module). This work includes both server & client modules: - Server modules: the registration bot acts as a proxy between the client and the CONIKS server. Account verification is performed by comparing the fingerprint (base64 encoded) included in registration request and the DM sent to CONIKS twitter account. - Client modules: the client module consists of a preferences UI and coniks module which sends the request. Currently, the policies setting of each user is stored in a sqlite database. (source code of client module is pushed to [2]) - The server will return base64 encoded string of the temporary binding (TB). This would be changed when we start working on monitoring & key lookup modules. (i.e. returning more data along with TB) - The verification message (Twitter direct message) format is: ?CONIKS?b64Encode(fingerprint) The registration protocol can be illustrated as follows: Client - Registration bot (listening on port 3000) - CONIKS server (listening on port 3001) 1. Client sends a DM to CONIKS Twitter handle 2. Client sends a registration request to registration bot 3. Registration bot verifies the request 4. If it is valid, the bot forwards the request to the CONIKS server 5. The server returns a TB for the requested user 6. The bot forwards the TB to the client. The source code is available for review [3]. After some discussions with my mentors (Arlo and Marcela), we also came up with an improved account verification scheme. In the original proposal, the client would send the public key to the registration bot and the signed public key to the twitter handle. However, that doesn't always make much sense, since the Merkle tree really stores an opaque blob, not just a key. The verification protocol could be simplified by letting the client send the fingerprint to both registration bot and the twitter handle. Then we can do a comparison these two messages for the verification. The new verification scheme seems more effective in case of Tor Messenger and OTR protocol. Best, Huy — [1] https://github.com/coniks-sys/libconiks-server-go/pull/3 [2] https://github.com/c633/ctypes-otr/tree/coniks-registration [3] https://github.com/c633/tor-messenger-coniks/pull/1

1 1

[GSOC 16] Ahmia status update #3
by Ismael R 03 Jul '16

03 Jul '16

Hi everyone, I'm working on ahmia.fi, the hidden service search engine and you're reading status update #3. Since last time, I've been moving forward with the django "rewrite". A little context: The current main goal of the project is too regroup all data related to search into our elasticsearch index (sites content, tor2web stats) so we can use it to give better search results. Since I'm focusing on the django part, I'm removing a lot of search logic which is now done by elasticsearch. For instance, banned websites will be store in our main index and elasticsearch will filter them before returning search results. This is a different behaviour from now, where banned websites are stored in a PostgreSQL database and filtered at the django level. I'm also taking advantage of this rewrite to accomplish the following goals: - Compartimentalize what should be in apps : I plan to do three apps : search, stats and api - Remove deprecated code/files - Remove every linter error/warning : I worked on this one, but some warning could not be remove without a rewrite. - Update django version : We are using Django 1.7 which is not supported anymore. - Use a more coherent url scheme (while keeping retro-compatibility) - Use a more coherent API behaviour (also while keeping retro- compatibility) - Write more tests to verify correctness After this rewrite, we will have three apps in our Django website: Search will focus on pages related to search results, querying our index to get results. It will be later improved with !bang syntax or some other keywords to specify a date range, a specific .onion website, etc. Stats will focus on statistic visualization (most popular .onion, etc). It could be later improved with a "Ahmia trend" interface to view searches over time. Api will focus on the API part of the website. I have a couple ideas but will discuss them in a later report. During the next two weeks, I will continue my work on this rewrite. See you in two weeks :) Ismael

2 1

[GSoC '16] Exitmap Improvements Project - Status Report #3
by Mridul Malpotra 02 Jul '16

02 Jul '16

Hi everyone! For the past week, I have shifted my focus to the main sub-project of continuous scanning in Exitmap. What we'll be trying to achieve is having the Exitmap utility running in the background and running the various modules. This report recounts one week worth of work since my 2nd report was on 26th June. Work done: --------------- 1. Wire-framed the structure of how continuous scanning will work. Major components that will be focused on are (a) Periodically updating the network consensus to scan for new or previously invisible exit nodes for malicious behaviour, (b) A mechanism that keeps a close eye on some exit nodes while does not care much for nascent exit relays or well established guard nodes, and (c) Add as much randomization as possible for these scans to make it more difficult for a malicious exit relay to distinguish regular traffic from scanner activity. 2. IRC meeting with my primary mentor Philipp Winter (phw) to discuss some of the features and how will go about implementing them. Some points arrived at from the discussion: a. Need to create an asynchronous element for periodically fetching consensus data and to integrate the element with the existing Exitmap functionality. b. Find a way to update the Tor micro-descriptors and use new consensus for the modules. I still need to find a way to programmatically force the Tor client to update its consensus at the moment specified. Damian Johnson (atagar) advised me to use the FetchDirInfoEarly parameters that helps. If anyone has any more information about this, it would help a lot. I will be scouring through the control-spec for the same. c. Create an algorithm to give more weightage to some exit nodes from consensus depending on what the criteria is. We need to come up with a selection mechanism that selects nodes visible in the say 0-24 hours time frame but is not a node that has just come or has been around the Tor network for some time. Some research still needed on this aspect. Have a great weekend everyone! -- Mridul (mtyamantau) ============================= PGP keyID: 0xb716e33ab6d0a653

1 0