- tor-dev - lists.torproject.org

[GSoC 2016] Orfox - Report 6
by Amogh Pradeep 16 Aug '16

16 Aug '16

Hey guys, Things have been a little slow the past couple of weeks with moving back to college and all the related formalities. But these are the things that I’ve been up to. 1) Tor Button I’ve been looking into the tor button repo and trying to wrap my head around it. Porting this to the new convention of extensions to make it work with mobile was part of my plan. But I think this needs to be discussed more. 2) Official Build Plugins Looks like mozilla has some new checks for the plugins that get installed on shipment. This makes our build fail as the plugins we had weren’t being signed before installation. Trying to figure out what might be best to do next regarding this. Thats it from me for now, will catch up on lost time for the last leg of this years GSoC. Best, Amogh Pradeep amoghbl1(a)gmail.com

1 0

txtorcon 0.15.0
by meejah 15 Aug '16

15 Aug '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm happy to announce txtorcon 0.15.0: * added support for NULL control-port-authentication which is often appropriate when used with a UNIX domain socket * switched to https://docs.python.org/3/library/ipaddress.html instead of Google's ipaddr; the API should be the same from a user perspective but **packagers and tutorials** will want to change their instructions slightly (``pip install ipaddress`` or ``apt-get install python-ipaddress`` are the new ways). * support the new ADD_ONION and DEL_ONION "ephemeral hidden services" commands in TorConfig * a first stealth-authentication implementation (for "normal" hidden services, not ephemeral) * bug-fix from https://github.com/david415 to raise ConnectionRefusedError instead of StopIteration when running out of SOCKS ports. * new feature from https://github.com/david415 adding a ``build_timeout_circuit`` method which provides a Deferred that callbacks only when the circuit is completely built and errbacks if the provided timeout expires. This is useful because :doc:`TorState.build_circuit` callbacks as soon as a Circuit instance can be provided (and then you'd use :doc:`Circuit.when_built` to find out when it's done building). * new feature from https://github.com/coffeemakr falling back to password authentication if cookie authentication isn't available (or fails, e.g. because the file isn't readable). * both TorState and TorConfig now have a ``.from_protocol`` class-method. * spec-compliant string-un-escaping from https://github.com/coffeemakr * fix https://github.com/meejah/txtorcon/issues/176 You can download the release from PyPI or GitHub (or of course "pip install txtorcon"): https://pypi.python.org/pypi/txtorcon/0.15.0 https://github.com/meejah/txtorcon/releases/tag/v0.15.0 Releases are also available from the hidden service: http://timaq4ygg2iegci7.onion/txtorcon-0.15.0.tar.gz http://timaq4ygg2iegci7.onion/txtorcon-0.15.0.tar.gz.asc You can verify the sha256sum of both by running the following 4 lines in a shell wherever you have the files downloaded: cat <<EOF | sha256sum --check f2e8cdb130aa48d63c39603c2404d9496c669fa8b4c724497ca6bfa7752a9475 dist/txtorcon-0.15.0.tar.gz a359fb5e560263499400018262494378b3d347cd04a361adb08939df95ecedf6 dist/txtorcon-0.15.0-py2-none-any.whl EOF thanks, meejah -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJXl/KEAAoJEMJgKAMSgGmn76gH/1du7i9dmkMpr2PJrexVeXSo 9mSaeX/7KKaW71pEMmaCXfvhDJ6dMZDQpZ7saTM31zJZTp+MXjtHf0DZI2QTwgDw NYEBH+LO8PINN1ezPomgeZE6E4eJYlaDCyO6c7j3cOsEmohST+GPpvvdWdft+Sw2 hWvVf2+I4BV7vcIx6WQx4jKBS2gmlHbxuUv3LAnjj/Tn6oSYpft1IUK39pM66DX4 FzdYeBTloC6nzyH4sRTxnax+l9MfQJ2ZR+5alJi8uEvGlk580ciFASQNCVLaBY9r 4YALoipEg2Fm4BFA7qLsH0aFoLgx0lv7ng8lmpaP7XlPjUCuA7OcDp5jSqhGt2A= =hWml -----END PGP SIGNATURE-----

5 7

[GSoC] CONIKS for Tor Messenger - Status report #6
by Huy Vu Quoc 15 Aug '16

15 Aug '16

Hi everyone, This is my sixth status report for my GSOC project. There are not much for this recent weeks since we (my mentors and I) are concentrating on reviewing/refactoring code. 1- Development of the CONIKS protocol library: The pull for this issue is at https://github.com/coniks-sys/coniks-go/pull/64. It’s almost done. However, we opened new ticket for discussion over key lookup & key monitoring function (issue #70). 2- Starting integrating CONIKS into Tor Messenger There’re currently 2 pulls for the integration (https://github.com/arlolra/ctypes-otr/pulls) We also probably would do some refactoring on the cgo client library, the idea is to wrap all client tasks into this library, and then the server’s responses would be passed in the library instead of unmarshalling the response and passing them into separate functions as now. 3- Fixing bugs and making improvements based on our discussions/feedbacks Basically, there’re many things need to be done before the end of GSoC. We probably cannot merge all the implemented features into master branch before the end of GSoC, so I’m working on a separate branch that merged all pulls so far, the main purpose is to have a working prototype for my GSoC. Best, Huy

1 0

How to integrate an external name resolver into Tor
by wire321＠sigaint.org 14 Aug '16

14 Aug '16

Blockchain addressing has some serious issues that will stand in the way of wide adoption. The need for payment already makes this out of reach for many users. Lack of anonymous payment is a privacy challenge until Zcash comes into the picture. The need to download a blockchain on embedded devices is a deal breaker. Battery life, storage space and storage life expectancy are tight constraints. How are you going to deal with this?

2 1

[GSOC 16] Ahmia status update #6
by Ismael R 13 Aug '16

13 Aug '16

Hi everyone, I'm working on ahmia.fi, the hidden service search engine and you're reading status update #6. During the last two weeks, I finished porting the django app to the new structure. I'm also working on last minute things before shipping the new site online. I will continue updating documentation and add some unit tests to the project. The code is not merged yet but you're welcome to check it on my forks. [1] [2] Since this status report is short, here is a list of goals I had in my initial project proposition and what work has been done on each. Review code and infrastructure: - Split the project in several repositories - Improve documentation - Automate testing (Travis.CI) - Track code quality (Landscape.IO) - Track requirements (Requires.IO) - Refactor each subproject Improve search results: - Better use of elasticsearch (use of stemmers, shingles, term-centric search) - Search results are now pages instead of domains. Improve UI/UX: Not much work has been done for this goal. The website has been in the process of porting old pages to a new design. All pages are now using the new design. Gather more statistics: - Pagerank is now used to compute an authority score for each page - I suggested that we could use a self hosted statistics framework like piwik [3] but no decision has been made. Use stats to better rank search results: - Results are ranked by authority score. Make sense of the indexed info to understand a search meaning: - Shingles enable us to differenciate these two queries: "i'm not happy i'm working" and "i'm happy i'm not working". - Synonyms could be used by the search algorithm if we provided a synonym dictionnary. No work has been done at making this work. Make a google trend-like interface to visualize searches over time: No work has been done to reach this optional goal. Even some stats fonctionnalities were dropped in the new site because they were "domain- centric" when a search engine needs to be "page-centric". We could probably index searches in elasticsearch and use Date Histogram Aggregation [4] to display trends. Make stats available with the API: No work has been done to reach this optional goal. Some API endpoints were also dropped because they were domain-centric. It would be great to have an API with a coherent url scheme. I think Django Rest Framework can help design that API while keeping the code simple. That's it for this week, Have a nice weekend. Ismael R. [1] https://github.com/iriahi/ahmia-site [2] https://github.com/iriahi/ahmia-crawler [3] https://piwik.org/ [4] https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggr… [5] http://www.django-rest-framework.org/

2 1

[GSOC16] Fingerprint Central - Status report n°6
by Pierre Laperdrix 13 Aug '16

13 Aug '16

Hi everyone, Here is my sixth status report for my GSOC project. Repository: https://github.com/plaperdr/fp-central Beta: https://fpcentral.irisa.fr 1- Development of the "Acceptable" feature When a user sends his fingerprint to the server, he can now see for each attribute if the collected value is "acceptable" or not (i.e., if it is an expected one). If the server returns that a value is not an acceptable one, this means that it is something to investigate. Does it come from a simple misconfiguration of the browser or could it be a genuine difference between TBB browsers that should be fixed? Right now, it is a simple Yes/No answer but I'll add more feedback so that a user understands the information that is presented. 2- i18n support with documentation I have finished the FR version of the website. Not everything is localized since some libraries I use for the front-end are only in English but the majority of FP Central is now translatable. I have written a small guide if anyone wants to contribute (https://github.com/plaperdr/fp-central/tree/master/translations) The process is pretty simple: you generate a file that references all the strings that need to be translated and you complete it with your translations. 3- Multiple bug fixes and improvements I fixed multiple bugs in the customStats page that were caused by the way I structured data in the page and it should be much smoother now. I'm sure other bugs are lurking in the code so do not hesitate to visit the beta website and report to me any bugs you may find. In terms of features, I have normally developed everything I wrote in my proposal. So my focus for the final stretch of the coding period is to clean the code, fix bugs, improve the website and write even more documentation. I'll also start planning the post-GSOC period to see what interesting features could be added in the future and to make sure that FP Central is ready for prime time for users and developers. Have a great week-end, Pierre

1 0

First CollecTor Release 1.0.0
by iwakeh 12 Aug '16

12 Aug '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi there! A while ago I wrote about the CollecTor improvement project [0]. Since July we intensified work there to prepare the very first release of CollecTor, which is now available here: https://dist.torproject.org/collector/1.0.0/ CollecTor itself is much older, the git repository dates back at least six years and there is even data from the year 2004 available [1]. The three most significant changes for release 1.0.0: * CollecTor consists of a single executable Java jar now. * CollecTor schedules all modules without the help of any crontab like service. * Configuration is done via one file and all important settings were made configurable. CollecTor is only a download away now :-) Cheers, iwakeh [0] https://lists.torproject.org/pipermail/tor-dev/2016-April/010742.html [1] https://collector.torproject.org/archive/relay-descriptors/tor/?C=N;O=A -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAles67AACgkQsANAxTOj/ab/GQEAl/KUq2by8ooi2Nftw9RFh85L lLHf6uwzmHXD294lptQA/jHxOSCDUDUM4uEVV4HxvaUVbuToNNZ0mqbY45YbJz+r =rLeM -----END PGP SIGNATURE-----

1 0

https://gitlab.com/torproject
by Hans-Christoph Steiner 11 Aug '16

11 Aug '16

FYI I registered https://gitlab.com/torproject to claim the name in the gitlab namespace. I'm happy to hand it over to a more official Tor person if anyone wants. Or just let me know if anyone ever wants to actually use it. I've been using gitlab for a while now with F-Droid, and its quite nice. Guardian Project is going to move our stuff there too. .hc -- PGP fingerprint: EE66 20C7 136B 0D2C 456C 0A4D E9E2 8DEA 00AA 5556 https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE9E28DEA00AA5556

3 2

How to integrate an external name resolver into Tor
by Nick Mathewson 09 Aug '16

09 Aug '16

Hi, all! I've seen a couple of emails from people looking into new ways to do naming for onion services. That's great! Before anybody gets too far, I'd like to send this quick note to let you know that integrating stuff like this into Tor is actually easier than you think. Here's how you do it, using a Tor controller. (See control-spec.txt for protocol documentation. Also see one of the several friendly libraries, like steam, that exist to interface with Tor over this protocol.) First, you set the Tor option "__LeaveStreamsUnattached". This tells Tor that it shouldn't try to handle new client requests immediately, but it should instead let the controller take responsibility. In the controller, you make sure that you are watching STREAM events so that you find out about new streams. Whenever there's a new stream, you check its address. If the address is one that you don't want to rewrite, you just call ATTACHSTREAM on it, with a circuit ID of 0. (The 0 means "Tor, you figure out how to attach this one.". Otherwise, you do whatever magic dance you do in order to find out the real address for the stream. If the lookup operation is successful, you say "REDIRECTSTREAM (stream ID) (new address". And then you ATTACHSTREAM as above. If the lookup operation fails, you call "CLOSESTREAM (stream ID) 2". (The 2 means "resolve failed". And that's it for the Tor integration! All you need to do now is figure out how the name lookup works. cheers, -- Nick

5 7

Re: [tor-dev] Onioncat and Prop224
by str4d 08 Aug '16

08 Aug '16

On 08/08/16 01:22, Jeremy Rand wrote: >> And most certainly any external layer must be capable of having >> nodes binding natively in the Tor / I2P / etc networks, and >> preferably being strictly private entirely within them (like how >> private Tor / I2P / Bitcoin nets can be deployed by generating >> new authorities, keys, genesis, etc). Outproxy is not an option. > > Bitcoin and Namecoin nodes can be exposed as Tor hidden services (I > believe there's even code in there now for automatically configuring > such a hidden service via the Tor control port). I don't think there's > any built-in support for I2P (unless something was added since I last > looked), Not yet, but there's an open issue for adding I2P support (alongside support for Tor's HS2.0) [0]. See also an old Bitcoin fork with I2P support [1], and other relevant links in Zcash's I2P issue [2]. Any native I2P support would automatically set up the I2P Destinations, because that's how the SAM API operates [3]. > but if I2P can expose a local TCP service as an I2P service, Yes. > and if I2P allows such TCP services to be connected to by exposing a > SOCKS interface, Yes. > I'm guessing that it should mostly work (famous last > words). The only thing that would break that way is peer exchange: > Bitcoin and Namecoin nodes normally share peer addresses, and although > this works just fine with Tor hidden services, I don't think it would > work out of the box with I2P (unless someone's added that since I last > looked). The issue here is that I2P addresses (even B32s) are longer than the internal message fields for sharing addresses. Tor's HS2.0 will suffer from the same issue, because their proposed addresses are just as long as I2P's B32s. > > Although it is possible to deploy private Bitcoin and Namecoin networks > (I did it at a workshop I gave at DWS so that I could mine blocks on > demand), usually people do this for testing or demonstration purposes, > not for real-world applications. The reason is that blockchains' > security assumptions include the assumption that they have a reasonably > high hashrate from a reasonably diverse set of miners. An > Onioncat-specific Namecoin network would probably have a very low > hashrate compared to the main Namecoin network, which means that it > would be much easier to perform a 51% attack. Merged mining could, > hypothetically, raise the hashrate, except that to do merged mining, the > miners would have to be connected to the public Bitcoin network. In > addition, it's usually very unprofitable to mine Bitcoin or Namecoin > over Tor or I2P, because the additional latency causes much higher > orphan rates. (Most Bitcoin and Namecoin miners spend considerable > effort obtaining low-latency connections for relaying blocks to and from > other miners.) > > Might I ask what the motivation is for having a completely separate > Namecoin network inside Tor/I2P, that can't be satisfied by binding > participants' nodes to Tor/I2P hidden services while allowing some users > who don't want or need anonymity to relay transactions and blocks > between clearnet and Tor/I2P? One potential issue is that if the user's endpoint isn't configured correctly, Namecoin names that resolve to clearnet addresses could deanonymise the user (checks at the browser or app level wouldn't help here because all it would see is an IPv6-style address IIUC). It's not unavoidable, but a point to be wary of when considering the overall integration strategy. Using the global Namecoin blockchain also puts the bridging nodes into a position of importance and trust, that can only be lessened by greatly increasing the number of bridging nodes. This is more of a concern for I2P than Tor, as I2P-only peers can only reach the bridging nodes, whereas Tor-only peers can connect to clearnet Namecoin nodes too (although as with Bitcoin there is the issue of exit node traffic manipulation). str4d [0] https://github.com/bitcoin/bitcoin/issues/2091 [1] https://github.com/VirtualDestructor/bitcoin-qt-i2p [2] https://github.com/zcash/zcash/issues/1111 [3] https://geti2p.net/en/docs/api/samv3

1 0