- tor-dev - lists.torproject.org

Relays that change their fingerprints a lot
by Philipp Winter 02 Mar '15

02 Mar '15

Inspired by Gareth's 31C3 talk [0], I taught sybilhunter [1] to calculate the amount of unique fingerprints a Tor relay used over time. Armed with that feature, I extracted the top 10 relay IP addresses that had the most fingerprints for every month since 2007 [2]. While most IP addresses show up only once in the monthly top 10, three IP addresses showed up more than ten times. Address Count Owner Total changes ---------------------------------------------------------------- 193.19.77.145 11 times ISP in France (DDO) 163 71.57.5.24 11 times ISP in the US (Comcast) 430 141.70.22.69 12 times University in Germany 293 Note that being present in the monthly top 10 isn't necessarily suspicious because it can be attributed to misconfiguration. For example, if a Tor process' data directory is set to /tmp, you get a new fingerprint every time you reboot. A better metric is the amount of unique fingerprints, so I extracted the IP addresses that changed their fingerprint the most [3]. One IP address in Comcast's network, 98.212.74.104, changed its fingerprint several hundred times. That happened from August to December 2010. Below is one of the relay's descriptors. Note that the nickname suggests that the relay was running on OpenWRT. @type server-descriptor 1.0 router openwrt 98.212.74.104 9001 0 0 platform Tor 0.2.1.26 on Linux mips opt protocols Link 1 2 Circuit 1 published 2010-09-10 01:42:42 opt fingerprint 90BD DDA6 D716 D36A D236 03A7 06A9 887E FFEE DFED uptime 915 bandwidth 102400 102400 55670 Unfortunately, it's difficult to make meaningful conclusions from this data. Relays that change their fingerprint a lot might still be honest unless the distribution of their fingerprints clearly deviates from a uniform distribution or correlates with Tor's DHT structure in some way. I also uploaded the raw data [4]. [0] <http://media.ccc.de/browse/congress/2014/31c3_-_6112_-_en_-_saal_2_-_201412…> [1] <https://gitweb.torproject.org/user/phw/sybilhunter.git/> [2] <http://www.nymity.ch/hunting_sybils/multiple_fingerprints/accumulated_top10…> [3] <http://www.nymity.ch/hunting_sybils/multiple_fingerprints/accumulated_top10…> [4] <http://www.nymity.ch/hunting_sybils/multiple_fingerprints/monthly-statistic…> Cheers, Philipp

1 0

Fwd: Tor Weather - bug in email text
by Pablo Brasero Moreno 27 Feb '15

27 Feb '15

Hello all, I recently found a small problem with Tor Weather, and I wasn't sure what can be done to get it fixed. I hope this is the right forum. The problem is in the "[Tor Weather] Confirmation Successful" email, and it's about the links on the body. Specifically, these links and the text descriptions next to them are mixed up. Where it says "change your Tor Weather notification preferences here", the link presented is the unsubscribe link. Likewise with the "unsubscribe" text and the preferences link. Incidentally, I've been looking for the code repository, but what I found ( https://gitweb.torproject.org/weather.git) has different messages. Is this the actual repo? Regards, -- Pablo Brasero Moreno pablo(a)pablobm.com

1 0

tor and libressl
by Tyrano Sauro 27 Feb '15

27 Feb '15

I got tor build with libressl. it works. Is this a good idea? TY

4 5

Priorities for Onionoo development
by Karsten Loesing 25 Feb '15

25 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi iwakeh, cc'ed Tor devs, now that we're down to 0 defect tickets in the Onionoo component (not counting that one ticket in needs_review that I hope to resolve before the weekend), ... time for a little applause... I went through the 20 open Onionoo enhancement tickets in an attempt to categorize and prioritize them. Mind going through the list below and commenting on summaries and priorities? And is there a ticket that you'd want to work on? Here's the list, where (--) means low priority and (++) means high priority: === Functional enhancements, user-facing features === #9778 Adding votes documents to Onionoo (-) Processing votes and adding a new document type are major enhancements. The result might turn out to be really useful, but this takes quite some effort. Not super urgent, I'd say. #11041 Add new document type with monthly relay and bridge statistics to Onionoo (-) This is a major feature, and I didn't hear back from the people who originally suggested it. I'd say put on hold until somebody really wants this. #11430 Add new field last_running for "seen in a network status with the Running flag" in addition to last_seen for "seen in a network status" (-) Not many people will care about this distinction, though it's technically a good thing to make it. #11432 Start a bridge's uptime history when it was first listed in a status Similar to #11430, not many people will care about this. But it's still a good idea. #13137 Historical data (+) Without reading the whole ticket, this sounds worthwhile, though time-consuming. #13424 Add new `descriptor` parameter that returns relays or bridges by digest of recently published descriptors This feature would only be used by a very small subset of people, though those people help debug the Tor network. Maybe this isn't terribly difficult to implement. #13425 Add new document type `debug` that includes digests of recently published descriptors and statuses they're referenced from (--) Unclear if people would actually use this. Lowest priority. #14879 add platform search support to onionoo (+) Useful feature, but we should first think about related features and whether we should add them at the same time. === Refactorings, documentation, non-functional enhancements === #11573 Ponder using a database for Onionoo rather than keeping indexes in memory and contents on disk (--) I don't see the clear advantage of switching to a database. There's the risk that it will not perform (much) better or even worse than the file system based design. In any case, we can easily spend lots and lots of hours on this, and even if we're successful, there's no/hardly any visible change to users. Lowest priority. #12944 onionoo protocol/client api and base implementaion (-) I'm unclear what the benefit will be. And unfortunately, patches have aged quite a bit by now. #13003 Figure out a better strategy to avoid concurrent Onionoo executions (+) Unclear what's left to do here, but the summary sounds reasonable. #13080 Add Ant tasks for measuring coverage, dependencies, etc. (++) Without reading the ticket body, this would be great to have. #13088 Versioning and Releases (++) Sounds like a great thing to do, but I need help with this. #13334 improve DetailsDocument (-) Subticket to #12944, same priority. #13362 Make Onionoo's logs more useful (-) Unclear what's left to do, though making logs more useful sounds good. Depending on how much time we can sink into this, though. #13561 logging documentation (-) Seems useful, but if we start documentation logging configuration, we'll soon write much more documentation. This can of course be useful. But it's a huge time sink. #13562 additional logging for backend and frontend components (-) Better log statements would be great, but see the concerns about related tickets. #13600 Improve bulk imports of descriptor archives (+) We're in a good position to complete this ticket. And while it only affects very few people (Onionoo operators), it's worthwhile. #13616 define jmeter testcase(s) ant ant task(s) (+) Sounds useful to have some baseline data and then see how performance changes as new features are added. #14201 Configure out/ directory path somewhere else than in web.xml. (+) Sounds trivially useful. And here's the Trac query that this list is based on: https://trac.torproject.org/projects/tor/query?status=!closed&status=!needs… By the way, thanks for all your hard work by submitting and reviewing Onionoo patches! Many people use your work every day without even knowing it. All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJU7ebnAAoJEJd5OEYhk8hIUOYH/3AP2iu8hnCYtbcDOSkzqbDT rSe/S5MewtrRlD4cnZID/TqGXGZLJofWbd4Ly4SOg0QpoT8uq47k/vmbeeOBXSqx O3Qxu/e7L9z8/NJeuym3nwTAcFnIQv7K1JkqvPSyB8wrMFhJe+mll+UHS38f5C4z dKdCLs5gsmGJljqbr17tMr2y0hm38u1ID8lzlqmU3H/vI+5dvKK7DPfdsRNLbvmc tA5ATufehYya3xbHJPy8K9W0P706n3Dg4qHBrZ2AnxB4mmX/k3x842WJhnIYapyI kPiM2i2RVdumZA91kHUEu2dYMY0P3OzJK3K9cn9eNFtxMhnMmI1zttkOsIg7mWw= =ZHaC -----END PGP SIGNATURE-----

1 0

Hello, I am a Tor user in China.
by Li Xiaodong 25 Feb '15

25 Feb '15

Hello, I am a Tor user in China. When will StegoTorus be deployed on Tor software? Thank you very much.

1 0

Tor Project Idea for GSOC 2015
by Gautham Nekkanti 24 Feb '15

24 Feb '15

Hi, I am Gautham (icodemachine from IRC and TRAC). I am willing to participate in GSoC 2015. I was brainstorming for project ideas and thought of this useful project idea. I want to put forward a project idea of Simple analytics tool for HIDDEN service providers. Although, there are already thousands of third-party traffic statistic tools, most of them require javascript and just defeats the whole purpose of server anonymity. This project is a little similar to Arm, instead it involves in listening how many users are connected to our site and parsing it. Advanced metrics like IP addresses of visitors, countries, e.t.c. wouldn't be available as it is pointless in our case (Since the IPs reflect the IPs of exit nodes). So, it basically displays the number of visitors and a few other metrics. Historic data will be presented graphically. The data will be accessible through a localhost website and Historic data would be stored in a local database. Although, it is not nearly as advanced as other statistic tools, it would still be an essential tool for Hidden service providers to analyze their traffic figures. How would it be? Please share your views. Thanks, Gautham

4 3

Tor 0.2.6.x now has its own branches
by Nick Mathewson 24 Feb '15

24 Feb '15

Hi, all! Work on the Tor 0.2.6.x release series will proceed on the "maint-0.2.6" branch; releases will be build against "release-0.2.6". The master branch new has Tor 0.2.7.0-alpha-dev. cheers, -- Nick

1 0

Fwd: Orbot v15 alpha 4
by Nathan Freitas 23 Feb '15

23 Feb '15

----- Original message ----- From: Nathan of Guardian <nathan(a)guardianproject.info> To: guardian-dev(a)lists.mayfirst.org Subject: Orbot v15 alpha 4 Date: Mon, 23 Feb 2015 13:17:26 -0500 More progress on better bridge support and "full device" VPN mode... and a bit of a UI update, too! APK: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-4.apk ASC: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-4.apk.asc On the bridge front, we now support QR code scanning, since the https://bridges.torproject.org/ site now displays bridge info as QR codes optionally. You can also display your current bridge config as a QR code, so that your friends can easily scan/set it up for themselves. To use the "Meek" bridge, you just turn on bridges w/o having any config (press the new [BRIDGE] button on the main screen), and it will use the Meek Azure bridge by default. If you set the config info to 1 you can use the Google Cloud bridge, 2 = Azure and 3 = Amazon AWS. If you want to learn more about why you would send your Tor traffic through Google, Microsoft or Amazon, read here: https://trac.torproject.org/projects/tor/wiki/doc/meek Finally, the VPN mode is working well, but you can't use bridges with VPN mode together yet... still trying to make that work smoothly. ***** * Better Bridge Support fb9a6c9 support for sharing/display bridge config as QR code this is needed for sharing of bridge data between people in the same phy 068cd05 more bridge and proxy configuration clean up 31053ad add support for scanning QR codes for bridges f22978e update pluto bff6d0f add support for meek PT 266c297 update to latest pluto for meek-client 22e75a3 update pluto to latest 431dff5 remove integrated pluto code * Full Device VPN Mode dd09c6b tuning boot code to work with VPN b2ec768 more work to get bridge VPN mode to work f2490d9 handle all exceptions in socks proxy 9c77526 move HTTP VPN bypass proxy to 9998 096eae7 implementing http server for meek-client VPN bypass 1e5651e improve VPN clean-up code a2662c3 improve VPN activation c220ec9 re-enable DNS settings after you start Tor 6832363 use IP instead of "localhost" name 7f42265 launch the internal or system browser depending upon VPN mode 1852cde enable local DNS listen on 10.0.0.1 for VPN service also add support for stopping VPNBuilder instance ec4350e update VPN to toggle button 9467d7d clean VPN proxy settings before startup d63d10d massive cleanup of merged code from Ony fork removal/comment out of LoggerFactory log system a78e458 Merge branch 'ony-dev' into v15-dev 5c80572 Merge branch 'master' of https://github.com/SuppSandroB/Ony into ony-dev 4c49822 clarify vpnprotect code and add basic debug log 1464901 added badvpn as local folder 72a0173 delete as it should not be as subproject 90db557 clone of badvpn for dns fix 1472b4e some missing files added to git repo 08c220f clean up VPNBuilder setup code 91a72ef add in basic debug output fb3e27b more clean-up of VPN service code * Integrated Orweb simple browser 5a8aa88 add new gitmodules for orweb and pluto support 40b8f48 set to lib_orweb branch -- Nathan of Guardian nathan(a)guardianproject.info

1 0

OONI weekly dev meeting today Monday 23rd of February 18:00 UTC
by Arturo Filastò 23 Feb '15

23 Feb '15

Hello Oonitarians, We have skipped the last two weekly dev meetings because of various necessities, but I am going to suggest we try and make it today. There are a lot of interesting things to discuss and think about together. These are the topics that I have in mind, feel free to append to this list if you think that there is something else: * Discuss the outcome of the "Future of OONI" thread: https://lists.torproject.org/pipermail/ooni-dev/2015-February/000246.html * Updates on the migration of the pipeline * Discuss how to get 1.2.3 released on debian * Updates on libight and iOS integration * Finishing the bridge reachability study The meeting will happen as usual on the #ooni channel on irc.oftc.net at 18:00 UTC (19:00 CET, 13:00 EST, 10:00 PST). See you soon! ~ Arturo

1 0

Re: [tor-dev] Tor Project Idea for GSOC 2015 (icodemachine)
by Gautham Nekkanti 23 Feb '15

23 Feb '15

Thanks Paul for your valuable input. Yes, i think tracking the Geo-Location (country) would also be useful to understand the network although it might not benefit the onion service provider. Hope someone would mentor me on this. Cheers, Gautham

1 0