- tor-dev - lists.torproject.org

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 02 Jul '16

02 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

Improving hidden services on mobile phones
by George Kadianakis 01 Jul '16

01 Jul '16

Hey list, just for the record, during the past weeks we've been discussing how to improve hidden services hosted on mobile phones in this here trac ticket: https://trac.torproject.org/projects/tor/ticket/16387 Discussion has also spilled over ticket #18620. The discussion also has a design aspect as some suggested improvements would require protocol changes, hence I'm informing this list in case some people are interested in jumping in and participating. For example, for some use cases it might make sense to have an HS -> IP cell INTRODUCE2_ACK that acknowledges the receipt of INTRODUCE2 cells, so that the IP knows that the intro circuit is active and the HS received the introduction request before sending out its own INTRODUCE_ACK to the client. That's because mobile hidden services are unstable and their intro circuits break frequently, causing reachability issues. See the second part of https://trac.torproject.org/projects/tor/ticket/16387#comment:8 for more background. Have a good day :)

3 2

[GSoC16] Expand Nyx - Status Report 3
by Sambuddha Basu 01 Jul '16

01 Jul '16

Hi everyone, This is the third report for the 'Expand Nyx' project for GSoC 2016. I have been working on the following things since the past 2 weeks: * Added the basic interpreter panel. The interpreter panel now, internally uses Stem's interpreter panel. * Added help options to the interpreter panel. Appropriate error is shown when non-recognizable commands are entered. * The ANSI output from Stem's interpreter panel is now formatted to show appropriate color and attributes. * A scroll-bar has been added to the interpreter panel. The interpreter panel code that was added by me, can be seen at: https://github.com/sammyshj/nyx/pull/11 In the next weeks, I will be working on adding the history validation and tab completion for the interpreter panel. Hope everyone has a fun weekend! Thanks, Sambuddha

1 0

[GSoC] Tails Server - status report 4
by segfault 01 Jul '16

01 Jul '16

Hi everyone, this is the fourth status report on the Tails Server GSoC project. First off: There are nightly images of Tails with integrated Tails Server available for download [1]. Some notes if you want to test it: - Installation of the first service will take several minutes, because the APT package lists have to be downloaded - If you boot the image in a VM, the loading spinners won't spin. I couldn't yet figure out why. - The Gobby Service's status does not turn to "stopped", it remains in "deactivating" [1] http://nightly.tails.boum.org/build_Tails_ISO_feature-5688-tails-server/bui… Here is what I did in the last two weeks: * Work on the GUI * Implement three different approaches to edit the options. Discuss each of them on the tails-ux mailing list. Start conducting short user tests to get some data on which approach provides the best UX. * Implement a status line (this replaces the loading window I implemented previously) * Group the options * Rework the displayed connection info * A lot of smaller improvements * Use stem to create ephemeral hidden services instead of editing torrc * Implement reset of the onion address * Make Gobby Server work * Integrate Tails Server into Tails * Fix a lot of issues Next up is (still) writing a short documentation for the upcoming user tests. Then I will begin to conduct the user tests. Also, the autostart and client authentication features are still not implemented. And I plan to include some doxygen-like specification in the code. Cheers.

1 0

RelayAwards - incentives
by nusenu 01 Jul '16

01 Jul '16

> - We started this > website because we believe that competition can make more operators > improve their relay by following best practice. This would make the > whole Tor-network better if we have straight guidelines. > https://www.relayawards.com/ If it is about competing operators then you should aggregate an operator's tor instances not care to much about single tor instances of a given operator? You might just team-up with http://tor-roster.org/ Creating incentives for a high uptime would create incentives to run relays insecurely (never upgrade, never reboot, run vulnerable software longer). I wouldn't give away awards for low uptimes either - just leave it out of the equation? With over 94% CW [1] being routed by Linux relays, why is it good to run more Linux relays? I'd say create incentives for non-Linux relays. [1] https://github.com/ornetstats/stats/blob/master/o/os_share.txt How about anti-incentives? -5 for relays @ OVH added after a certain point in time?

1 0

[GSOC16] Fingerprint Central - Status report n°3
by Pierre Laperdrix 01 Jul '16

01 Jul '16

Hi everyone, Here is my third status report for my GSOC project. https://github.com/plaperdr/fp-central 1 - Following my last report, I've added the following elements to Fingerprint Central: - A page that detects the current level of the security slider of the Tor browser - A page that looks if the current fingerprint is "acceptable" compared to the Tor guidelines. This feature will evolve in the future to be more complete and to provide more feedback to users. - Support of users without JavaScript - Improvements of the code of the main FP page so that it reduces server load (by storing locally the information of the current fingerprint) I've also added support of Promises so that computation-heavy tests can be run without blocking the whole collection process. The added test on the AudioContext API is the first one to make use of that feature. 2 - We will launch a beta next week of FP Central to get early feedback on the project. Any ideas and suggestions will be welcome so that the website will be the best it can be for both users and developers. The server is online but I'm still making some final tweaks and bug fixes so that the launch will be smooth. I'll send an email early next week to this mailing list to inform everyone when it'll be ready. My goal in the next two weeks is to launch the beta of the website and start working on a great statistics page along with a more complete version of the "acceptable fingerprint" page. Have a great week-end, Pierre

1 0