- tor-dev - lists.torproject.org

Re: [tor-dev] prop224: Ditching key blinding for shorter onion addresses
by Nick Mathewson 30 Jul '16

30 Jul '16

whoops, didn't reply-all. On Sat, Jul 30, 2016 at 1:00 PM, Nick Mathewson <nickm(a)alum.mit.edu> wrote: > On Sat, Jul 30, 2016 at 9:32 AM, George Kadianakis <desnacked(a)riseup.net> wrote: > [...] >> >> Please let me know in what way this scheme is completely broken! > > I think it has the same problem as the last one: there does not appear > to be a way to keep an attacker from putting their own record in place > using your query_key, and thereby performing a DoS on your hidden > service. > > > -- > Nick

1 0

[GSoC] CONIKS for Tor Messenger - status report #5
by Huy Vu Quoc 30 Jul '16

30 Jul '16

Hi everyone, These are things that I have been doing in the last two weeks: - I and my mentors have had a discussions for next steps for the project. We decided to reorganize our project’s repo [1]. All repos has been merged into one [1]. This helps us maintain and keep tracking the development easier. - A lot of issues and PRs have been resolved/merged. The merkletree library is almost done for now. - Thanks for Ismail and Arlo’s suggestions, the client library for crypto verifications (including the VRF verification, Ed25519 signature verification, auth path verification and so on) is implemented in Go and compiled with `c-shared` build mode [2]. This library then will be wrapped with js-ctypes to use in the add-on. I have successfully loaded the library into the add-on in Linux machines. There’s still some problem since Tor Messenger for OS X is compiled from a Linux machine, while the library is compiled from macOS, then when loading the library into Tor Messenger for OS X, Tor Messenger may crash. We will probably dig deeper on this issue. Windows’ DLL version of the library also should be taken care. Next steps are mostly to focus on the client-side, along with finishing the server reference implementation. Here’s thing I expect in the next weeks: - Merge the server-registration and registration-bots PR. - Merge the coniks-preference PR. - Merge the PR of client library. - Submit PR for client registration and lookup. I also expect to have a working version of project before August 15, including the functions which I described in my proposal. Best, Huy — [1] https://github.com/coniks-sys/coniks-go [2] https://github.com/coniks-sys/coniks-go/tree/client-cgo

1 0

[GSOC 16] Ahmia status update #5
by Ismael R 29 Jul '16

29 Jul '16

Hi everyone, I'm working on ahmia.fi, the hidden service search engine and you're reading status update #5. During the last two weeks I worked on improving search. It required working on a new index format and updating the crawler to fill this new index. Search now has these new features: - Token search is done in addition to pure full-text search. For instance, "foxes" and "fox" are different words but are indexed as the same token. Same for "running" and "run", "tor's and tor". - Associated words are also stored. For instance, "I’m not happy I’m working" have the same words than "I’m happy I’m not working", but the meaning is different. - Meaningful words have way more impact than frequent words. - The text used with a link (called anchor text) is now stored with the page which is the target of the link. Let's say a site A is linking a site B like that: <a href="B">B is a great search engine</a>. Searching "great search engine" is going to return B instead of A. These anchors could also replace a title in the results list if the site has no title (.txt files are like that). - A word present in the title, description, anchors has way more strength than a word present in the content of a page. - An authority score is computed for each page thanks to the pagerank algorithm. Important pages (like homepages) tends to appear first in the result list. It also solves problems we have with duplicated content. - The result list now returns pages instead of sites/domains. Before updating ahmia.fi, I need to finish porting the rest of the django site (API and statistics) to the new structure. I hope to finish this next week so you can try it. After this, here are the features I plan to implement in the remaining time: - Add a language to the search engine (site:msydqstlz2kzerdg.onion to specify a domain, -term to exclude a term, filetype:txt to specify a filetype, lang:fr to specify a language, etc). - Use If-Modified-Since HTTP header to avoid crawling unmodified pages. - Improve documentation - Add unit tests Also, I have some ideas I won't have the time to implement during GSoC. Hopefully, I will do it later because I plan to continue working with the Tor community :) A small list: - Improve search for languages other than english by making one index per language - Make the crawler better understand query parameters. Some are useful (?page=3), some are useless (?printable=1). - Better tokenize the url to extract words from it. - Add highlights to each result (especially for those without meta- description) to show the context in which query terms appears. - Make a script to make sure every indexed url is still online. - Make a true RESTful API. I see you in two weeks for the next status report and maybe sooner if I push something online. Cheers! Ismael

1 0

Implementation plan for prop271 "Another algorithm for guard selection"
by George Kadianakis 29 Jul '16

29 Jul '16

Hello people, our new guard algorithm proposal (prop271) is getting finalized and we are planning to move to implementation soon. You can find the proposal here: https://gitweb.torproject.org/torspec.git/tree/proposals/271-another-guard-… You can also find the STRIKE team's implementation of proposal 259 here: https://github.com/twstrike/tor_for_patching Ideally we should borrow as much code as possible from their implementation. To move forward with engineering, here follows an initial thirteen step implementation plan for proposal 271. Where it made sense, I tried to provide links to current functions that can be used, or to code that the STRIKE team wrote and can be reused or studied. Let me know what I should make clearer or where I should go further in depth. --- Design decisions: An initial design decision here is whether we should make a new file for this feature or use the old entrynodes.c file? A related question here is whether both algos should co-exist, or should the new one replace the old? I leave both decisions to the person who writes the code. --- Implementation plan: 1) Create main guard selection state data structure (instead of using global variables) ** Ideally there should be no global variables, so that in the future we can have multiple parallel guardsets (e.g. prop247) ** Thoughtworks: guard_selection_t 2) Sample SAMPLED_GUARDS from GUARDS ** Fill in state for each sampled guard (added_on_date, etc.) ** Save/load SAMPLED_GUARDS to/from state ** Unittests for sampling/saving/loading ** Thoughtworks function: fill_sampled_guards_from_entrynodes() ** Thoughtworks unittest: test_fill_in_sampled_set() 3) Derive FILTERED_GUARDS / USABLE_FILTERED_GUARDS from SAMPLED_GUARDS ** The filtering function can be called at any point (e.g. ON_CONSENSUS) ** Write unittests ensuring correctness of filtering ** See populate_live_entry_guards() ** Thoughtworks function: filter_set() / filter_sampled() 4) Maintain set of PRIMARY_GUARDS ** Functions to extract set of (live) primary guards out of FILTERED_GUARDS ** Unittest ** Thoughtworks function: retry_primary_guards() / next_primary_guard() ** Thoughtworks unittests: test_next_primary_guard() 5) Selecting guards for circuits ** Meant to replace choose_random_entry_impl() ** See section SELECTING in prop271 ** Add new circuit states to or_circuit_t ** Implement the guard selection logic ** Unittests on circuit state machine ** Unittests on guard selection logic 6) Update guard state when a circuit fails/succeeds ** Section ON_FAIL and ON_SUCCESS ** See entry_guard_register_connect_status() ** Unittest 7) Maintain CONFIRMED_GUARDS ** Add guard to CONFIRMED_GUARDS when circuit succeeds ** Fill in state info for each confirmed guard (confirmed_on_date, etc.) ** Migration from old state format to new ** Thoughtworks unittest: test_used_guards_parse_state() 8) Retry schedule for guards (section RETRYING) ** See entry_is_time_to_retry() ** Unittest 9) Update list of waiting circuits (section UPDATE_WAITING) ** Implementation of guard "higher priority" ordering (see CONFIRMED) ** Unittest 10) Update state whenever we get a new consensus (section ON_CONSENSUS) ** Update SAMPLED_GUARDS elements (section SAMPLED) ** Remove obsolete/expired guards ** See entry_guards_compute_status() / remove_obsolete_entry_guards() ** Thoughtworks function: entry_guards_update_profiles() 11) Bridge support ** Thoughtworks function: fill_in_from_bidges() 12) Separate state instances when EntryNodes/ExcludeNodes/etc are used ** See prop271 MEANINGFUL_RESTRICTION_FRAC etc. 13) Glue things together! ** Add clean and meaningful logging so that we can *heavily* field test the feature in our machines

1 0

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

29 Jul '16

Hi everyone, Here is my fifth status report for my GSOC project. Repository: https://github.com/plaperdr/fp-central Beta: https://fpcentral.irisa.fr 1 - Support of TBB versions for statistics through tags I have added the selection of TBB versions for the custom statistics page. In order to do that, I designed and developed the tag system that I planned to develop much later for the project. For those who do not know what tags are, it is a way to classify fingerprints and put them into different categories. By analyzing collected fingerprints, the system can assign one or more tags to them. After several iterations, I think I found a good balance between expressiveness and simplicity. You can find the documentation on how to add your own tag to the system here: https://github.com/plaperdr/fp-central/blob/master/fingerprint/tags/README.… I have added a command to refresh and recompute all tags in case a new one is added to the system or if the logic of one tag has been changed. Right now, the tag system is used to tag each fingerprint with the corresponding TBB version but it can be used later on for many different things like identifying the OS or the type of the browser. 2 - Better and more complete custom statistics page. The custom statistics page is now much more complete than before. In addition to the already-existing pie chart, I have added an HTML table which gives the complete list of data from the chosen attributes. You can sort the data and download it in several different formats. It is a handy feature if you want to put the fingerprints into a different software or if you want to copy/paste them for a thorough bug report. I've pushed the latest updates today to the beta server so that you can try them right now and send me feedback on them. My goal for the next two weeks is to iron things out in the beta and fix bugs. I still need to make sure that only TBB fingerprints are stored in the database. Feature-wise, it seems that I'm getting near the end on the list of features I wrote in my proposal. The only real big one that is left is to have a page to see if your complete TBB fingerprint is "acceptable" (right now, only several attributes are checked). Finally, for the final stretch in the second half of august, I'm planning on completing the documentation and the french localization while making sure that deployment and updates of the site are as easy as possible. Have a great week-end, Pierre

1 0

[GSoC 2016] Orfox - Report 5
by Amogh Pradeep 28 Jul '16

28 Jul '16

Hey guys, These are the things I’ve done in the past couple of weeks. 1) GetUserDataDirectoryHome in nsXREDirProvider. Looks like the blocker in nsXREDirProvider was the GetUserDataDirectoryHome function. https://trac.torproject.org/projects/tor/ticket/19706 <https://trac.torproject.org/projects/tor/ticket/19706> is the ticket opened to track updates regarding this. Once this is ready, we would be able to upstream all the Orfox patches to the tor-browser repo. 2) Commits clean up. I’ve made a couple of passes on the commits to Orfox that we have, to reorder them and merge them as much as possible. This will make it easier to maintain things in the future, and it would be easier to review code as we merge it with tor browser. 3) Disabling search widget. The search widget for Orfox has now been removed. https://dev.guardianproject.info/issues/7444 <https://dev.guardianproject.info/issues/7444> Commit: https://github.com/amoghbl1/tor-browser/commit/f415a732a8e50c2c34f43d905c36… <https://github.com/amoghbl1/tor-browser/commit/f415a732a8e50c2c34f43d905c36…> At this moment, I don’t see the advantage of having this feature and would prefer not supporting it, in order to make it easier to maintain Orfox. In other new, I am migrating this week from CET to IST! This might make it slightly harder to be online during most active hours, but I will try to be around. Hope you guys have a great weekend. Best, Amogh Pradeep amoghbl1(a)gmail.com

2 1

Further sandboxing Tor Browser (aka Tor + Firejail redux).
by Yawning Angel 22 Jul '16

22 Jul '16

I felt randomly inspired, so I spent some time poking at my firejail Tor Browser sandboxing effort, and made progress towards something more robust. In particular, I switched to using AF_LOCAL (aka AF_UNIX) sockets, via a brute force-ish approach, which seems to be working well, despite some caveats. In theory, this raises the difficulty of proxy bypass type things significantly (in that you need a sandbox escape sploit to use AF_INET/AF_INET6). In practice, who knows, for what it's worth the subterranean reptiloids who beam thoughts into my head from their satellite installations reassure me that it's safer. WARNING: * If you are not comfortable with running/configuring a system tor daemon, keeping it up to date, and keeping it in sync with the one shipped with Tor Browser when it diverges, stop reading, and wait for the Tor Browser people to come up with their own sandboxing solution. * If you expect me to provide any sort of help beyond "merging sensible patches", likewise stop reading, and wait for the Tor Browser people to come up with their own sandboxing solution. Really. Prerequisites: * A system tor daemon with the Control port and Socks port exposed as AF_LOCAL sockets, with permissions configured such that the user running Tor Browser can write to both. Due to torbutton quirks, having a SocksPort on 127.0.0.1:9050 is also a good idea, though not strictly necessary. * A recent version of firejail (nb: I did not test this with a USER_NS kernel. It may be better, it may be worse.). Setup: 1. Clone https://git.schwanenlied.me/yawning/tor-firejail 2. (Optional) Back up your Tor Browser install so you can go back to the way things used to be when you mess up. 3. Follow the instructions in the README.md, adjusting paths as appropriate. It should be self explanatory. If it's not, revert back to how things were, and wait for a more official solution. Depending on how your tor is setup, you probably need to set a bunch of env vars (At a minimum, TOR_SKIP_LAUNCH is required. Everything else depends on how the control/socks sockets are setup, and where they live, the modified start-tor-browser script has more documentation in comments.). 4. Run start-tor-browser, use lsof/netstat/whatever to verify that the AF_LOCAL sockets are being used. Caveats: * The security of this assumes that the firejail options I use to enforce address family restrictions work as advertised. * You need a system-wide tor, because if you tried to run the tor daemon inside the sandbox, it won't be able to access the network. * The firejail profile I provide disallows access to everything in the user's home directory except for the directory that actually contains Tor Browser. Edit the profile to change this if you care about it. I like the behavior for various reasons so I'm not going to change it. * The `about:tor` display falsely reports an error unless there's a SocksPort on 9050, due to torbutton. You can alternatively lie to torbutton about where the listener is if you engage in control port related tinfoil hattery. * You need to repeat parts of the installation steps after updating. How it works: * firejail's sandbox forbids all non-AF_LOCAL sockets. * A small stub is injected into the firefox process at runtime via LD_PRELOAD that fixes up socket calls to go to the system wide tor instance's AF_LOCAL sockets. Random thoughts: * The stub should be adequate for using other similar sandboxing solutions (eg: flatpak's bubblewrap, Google's thing, whatever). The code is compact, and is something anyone half way competent could write in 15 mins or so (it may have dumb bugs, dunno). Using the stub on it's own without the sandbox would be a horrible idea. * Assuming Tor Browser works as advertised, the only reason it needs control port access for this sort of use case is the circuit display (as of torbutton commit 36d849291ec0b20a58cccc2cd846fcd2540c9bbe, sending NEWNYM should be unnecessary if domain isolation is applied to everything). Regards, -- Yawning Angel

2 2

Tor with collective signatures
by Nicolas Gailly 22 Jul '16

22 Jul '16

Hi, First, thanks a lot both of you for your in-depth comments, I know it takes time, but they've been very helpful! Then I mean to ask you about what you said regarding the fallback directory keys. So keys are not embedded but only hashes, OK. As you pointed out, CoSi would need to download full descriptors in order to safely get the private keys of all the witnesses. This solution would need to clearly be defined as you said in order to be correct. However, there exists another solution and I'd like to know if it looks reasonable in the context of Tor . => Considering the two roles of Fallback directory mirrors are different (serving the consensus document to Tor / collectively signing on it), we thought it would make sense to create new keys for this role and embed those into the Tor source code. These keys would have to be ed25519 keys (same size as the ID), so the size overhead is minimal (32 bytes * 100 = 3.2KB vs 1.5MB). The only reason I can think of why Tor includes hashes instead of public keys is because of local storage: How does Tor consider an increase of storage need by 3.2KB ? Is it acceptable or not ? That would : * Bring down the need for exchanging the descriptors between the fallbacks / no more bandwidth / * No complex scenario such as "fallback key download mechanism" * Simplify the verification on the client side also (no need to get the keys if you already have them). * Add an additional steps for the relays operators where they would need to create that key and inform the Tor people about their public key. Maybe you thought of this solution and there's a reason why you did not mention it, or maybe you did not, then what do you think of it ? Cheers, Nicolas

4 7

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

22 Jul '16

unsubscribe On Fri, Jul 22, 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: Tor with collective signatures (isis agora lovecruft) > 2. Further sandboxing Tor Browser (aka Tor + Firejail redux). > (Yawning Angel) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 21 Jul 2016 15:05:07 +0000 > From: isis agora lovecruft <isis(a)torproject.org> > To: tor-dev(a)lists.torproject.org > Cc: Philipp Jovanovic <philipp.jovanovic(a)epfl.ch> > Subject: Re: [tor-dev] Tor with collective signatures > Message-ID: <20160721150507.GE8911(a)patternsinthevoid.net> > Content-Type: text/plain; charset="utf-8" > > Nicolas Gailly transcribed 59K bytes: > > Hi, > > > > Here's a new version of the proposal with some minor fixes discussed > > with teor last time. > > > > 0.4: > > - changed *included* to *appended* > > - 3.2: end of paragraph, a valid consensus document contains a > majority > > of CoSi signatures. > > - Acknowledgments include teor and Tom Ritter. > > > > As always, critics / feedbacks / thoughts are more than welcome :) > > > > Thanks ! > > > > Nicolas > > > > Ps: Our team and I are going to be at PETS this year, so if you don't > > have time now to > > > > read the whole thing, but you are still willing to know about CoSi and > > how it could improve > > > > Tor security, I/we will be happy to talk with some of you there also. > > Hello all, > > At PETS this afternoon, Nicolas Gailly, Philipp Jovanovic, Ismail Khoffi, > Georg Koppen, Nick Mathewson, and I met to discuss the collective signing > proposal. I'm just going to breifly summarise the discussion here. > > One of the major concerns voiced was that, if we made it mandatory that a > collective signature on a consensus be verifiable (for some N number of > signers, where N might be all of them but it's not important) for a client > to > accept and use a consensus, then attacks upon the witnesses (or any > disruption > to the witness signing system) will cause clients to no longer be able to > bootstrap. Conversely, if we made it so that it only emitted some warning > when the collective signature could not be verified, then (likely) no users > would see this warning (or even if they did, they'd treat it in the same > manner as a TLS certificate warning and simply click through it). > > There is also concern that, with enforcing collective signatures, that the > Tor > network has a larger attack surface w.r.t. (D)DoSing: an adversary could > DoS 5 > of the 9 DirAuths *or* they could DoS whatever necessary percentage of the > witness servers. Additionally, an adversary who controls some portion of > the > witness servers may DoS other witnesses in order to amplify the relative > proportion of the collective signature which they control. > > There was some discussion over whether to integrate this into core tor, or > rather to just use Nicolas' CoSi Golang tool in a separate process. > Everyone > agreed that rewriting something from Go to C is suboptimal. > > One idea was if we used CoSi, but rather than "don't trust/use a consensus > if > it doesn't have a good CoSi" we could use it as a mechanism for clients to > report (to some system somewhere? perhaps part of the prop#267 consensus > transparency logs?) when CoSis don't verify successfully. > > Another idea was to use CoSi to sign the metadata file which Firefox's > updater > uses to learn where to fetch updates so that a client would know that the > same > Tor Browser updates were being served to other different vantage points. > > Todo list: > > 1. It's not super necessary, but more analysis of the bandwidth overhead > for > running this protocol would be nice, i.e. network-wide overhead, not > just > the overhead for a single witness. > > 2. It would be nice to have some RFC-like description so that alternate > implementations could be created, e.g. include encodings, state > machines, > message formats. (We strive to maintain our specifications with the > delusion that there are secretly hundreds of other tor implementations > in > every existing language, and that any of them should be compatible if > they > follow the specification.) > > 3. Update the proposal to mention that each DirAuth would have their own > tree, thus the consensus document in the end would have somewhere > between > 5 and 9 CoSi signatures. > > 4. There's a typo in §5.2: s/witnesse's/witnesses'/ > > Thanks, everyone, for the great discussion! > > Best regards, > -- > ♥Ⓐ isis agora lovecruft > _________________________________________________________ > OpenPGP: 4096R/0A6A58A14B5946ABDE18E207A3ADB67A2CDB8B35 > Current Keys: https://fyb.patternsinthevoid.net/isis.txt >

1 0

Re: [tor-dev] [network-team] [doodle poll] Meeting to discuss guard proposal draft status
by George Kadianakis 18 Jul '16

18 Jul '16

Nick Mathewson <nickm(a)torproject.org> writes: > [ text/plain ] > Hi! > > We should do proposal discussion meetings again. In particular, we > should talk about this draft I've been working on for a revised > version of the twstrike team's revised version of Isis's revised > version of the guard selection and rotation algorithm. > > I've been tracking my work on ticket #19468: > https://trac.torproject.org/projects/tor/ticket/19468 > > There's some commentary happening on gitlab: > https://gitlab.com/asn/torspec/merge_requests/2 > > I expect I'll do another round of revision by Wednesday. > > I'm trying to schedule a time for us to get together to review this, > so that we can divide it up into tickets to implement it, ideally > based on the twstrike code that we have for the prior revision. > Hello! With Nick we settled on Thursday at 14:00 UTC as the time for this meeting! The plan is to finish the meeting in strictly less than 90 minutes. #tor-dev is the place :) See you there!

5 9

[GSoC] Tails Server - status report 5
by segfault 17 Jul '16

17 Jul '16

Hi everyone, this is the fifth status report on the Tails Server GSoC project. I did two batches of user tests in the last two weeks, with five participants each. The results were mixed, more skilled users had a better user experience than less skilled users. I will try to solve the problems discovered and make it more user-friendly for less skilled users. You can read my reports and the following discussions on the Tails-UX mailinglist [1]. [1] https://mailman.boum.org/pipermail/tails-ux/2016-July/thread.html Other things I did in the last two weeks: - Fix and improve the "clickable label"-widget I implemented - Implement the autostart feature - Write documentation - Make the application translatable - Refactor the code - Fix several bugs You can still download nightly images from here [2], but the recent images don't include the latest changes yet. They will be included in the next few days. Cheers!

1 0

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

16 Jul '16

Hi everyone, This is the fourth report for the 'Expand Nyx' project for GSoC 2016. I have been working on the following things since the past 2 weeks: * Added the history validation for the interpreter panel. * Added the tab completion for the interpreter panel. * Rebased code to include recent changes made by Damian. * Added some tests for the interpreter panel. The interpreter panel code ca be seen at: https://github.com/sammyshj/nyx/pull/12 In the next weeks, I will be adding rest of the tests for the interpreter panel and then start work on getting additional information provided by Onionoo. Hope everyone has a fun weekend! Thanks, Sambuddha

1 0

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

16 Jul '16

Hi everyone, Here is my fourth status report for my GSOC project. https://github.com/plaperdr/fp-central 1 - The beta for FP Central is live! You can visit it at this address: https://fpcentral.irisa.fr/ Don't hesitate to send us feedback so that we can improve the website to make it the best we can! I'm already fixing and tweaking several things on my end. Right now, I'm updating the website once a week so don't hesitate to come back to see newly added features! 2 - I've added two statistics pages on the website. I'm still tweaking how the data is being shown to the user but the goal is that anyone can select the attributes they are interested in and get the distribution for a given time period. I'm planning on adding new ways to visualize and download data so that developers can easily get access to what they want. My goal for the next two weeks is to improve the statistics page so that it works well and add support of TBB versions. I'll also make sure that only TBB fingerprints are stored in the database so that the current stats are not polluted by other browsers. Have a great week-end, Pierre

1 0

[GSOC 16] Ahmia status update #4
by Ismael R 15 Jul '16

15 Jul '16

Hi everyone, I'm working on ahmia.fi, the hidden service search engine and you're reading status update #4. The django part rewrite detailled in report #3 is nearly done. Next step is to synchronize the work done on crawler and index with the django app. I also want to add more tests and documentation. Because we are not storing hidden service information on SQL anymore, the main challenge will be to rethink how to get statistics from index. I will write about this in a later report, but I think it is doable with elasticsearch's metrics aggregation. A lot of code has been removed from the project (be it deprecated, duplicated, doable with django framework, or by elasticsearch). I think the project is going to be easier to improve, and the barrier to start being a contributor will be lower. Changes are not yet available upstream because the other projects (crawler and index) need work as well. This is what the other contributors and I are going to do during the next two weeks. See you in two weeks :) Ismael

1 0

[GSoC] CONIKS for Tor Messenger - status report #4
by Huy Vu Quoc 15 Jul '16

15 Jul '16

Hi guys, These are things that I have been doing in the last two weeks: 1. Continue implementing the libmerkletree library. The next module of the lib is a storage backend. The implementation is at [1]. Below is a brief description of my implementation: - In each update, both tree version and STR are entirely stored to the db. (this idea is mostly from Coname authors) - The developers now can construct the tree from db or do lookup in the STR which is stored in the persistent storage. The idea is when the server has been restarted, the developers can initialize the in-memory PAD (the history hash chain) with an existing tree; or whenever the developers needs to do a lookup from the db instead of the in-memory STR (the length of the history hash chain is limited by server’s configuration). 2. Implement the key lookup protocol. This function is not finished yet, since I’m still working on the client. The source code for the server is at [2]. For the client, since we are signing the STR using Ed25519 signature scheme, the client also needs a library for verifying the signature efficiently. I’m working on a C library that makes use of libgcrypt library (which also be used currently by libotr library). It takes me time to learn how to use libgrcrypt library. When this C library is finished, I can start working on key lookup and monitoring functions on the client part. In the next two weeks, I will try to have a working prototype (both key registration and key lookup) for Tor Messenger. Then I and my mentors can focus on refactoring and optimizing source code, as well as writing tests. Best, Huy — [1] https://github.com/coniks-sys/libmerkleprefixtree-go/tree/db [2] https://github.com/coniks-sys/libconiks-server-go/tree/lookup

1 0

[GSoC 2016] Orfox - Report 4
by Amogh Pradeep 15 Jul '16

15 Jul '16

Hey guys, These are the things that I’ve done in the past couple of weeks. 1) More progress with nsXREDirProvider. We had some build issues with the nsXREDirProvider. [0] Turns out that it was introduced due to an old patch that was included during the rebase. We’ve shifted to the right version but looks like that still breaks the apk. I’m currently working on isolating the tbb teams patch that breaks the mobile app and hope to have a fix for it soon. 2) Upstreaming to the official tor-browser repo. We plan to merge all the android specific patches into the tor-browser repo. In order to track this, we have a ticket. [1] With this in mind, I have started to organize the Orfox patches to make it easier to keep track of them in the future. 3) Official Builds soon! n8fr8 tells me that the official build systems are close to being ready to produce a build. This means that we should see an update soon on F-Droid and eventually the Play store! 4) Changes with Netcipher. Now that we have a stable build going, we’re looking into how we’re going to maintain NetCipher which is used in Orfox. Once we have this figured out, we can move on to working on improving the functionality of Orfox with Netcipher. Thats all for now. I will be at PETS in Darmstrad next week, if anyone wants to discuss something Orfox, you can find me there! Best, Amogh Pradeep amoghbl1(a)gmail.com [0] https://trac.torproject.org/projects/tor/ticket/19532 [1] https://trac.torproject.org/projects/tor/ticket/19675

1 0

GreatFire Circumvention Central: tests of speed and stability of circumvention tools in China
by David Fifield 13 Jul '16

13 Jul '16

https://en.greatfire.org/blog/2016/jul/greatfireorg-now-testing-vpn-speed-a… https://cc.greatfire.org/en "Our newest website, Circumvention Central (CC), aims to provide real-time information and data about circumvention solutions that work in China. Since 2011, we have been collecting data about blocked websites in China and now we will add data about the effectiveness of VPNs and other circumvention tools." They list various VPNs and other tools. Tor is on the list. (This page has JavaScript charts that aren't working for me in Tor Browser.) https://cc.greatfire.org/en/provider/Tor At the moment, these are the figures I see: Speed (kbps) Stability 1. HideMyAss 504 (+39%) 98% (-1%) 2. VyprVPN 445 (−33%) 98% (+11%) 3. FreeBrowser 440 (+13%) 88% (+1%) 4. XX-Net 356 (New) 97% 5. Astrill 294 (−32%) 97% (+1%) 6. Lantern 262 (+15%) 95% (+3%) 7. VPNSecure 259 (New) 87% 8. Psiphon 218 (+6%) 89% (+2%) 9. Ultrasurf 206 (+460%) 86% (−4%) 10. Freegate 188 (−29%) 91% (+1%) 11. PureVPN 151 (−25%) 94% (+1%) 12. Tor 112 (+237%) 96% (+1%) The test details have interesting values under the "Settings" header: https://cc.greatfire.org/en/provider/Tor#http-tests "0", "socks5", "是", "lantern-proxy", "lantern-proxy,no bridge", "lantern-proxy,meek-arzue", "proxy,no bridge", "lantern-proxy,obfs4", "obfs4", "否", "meek-arzue", "obfs4,sock5 proxy". There's a tool on the list I didn't know, XX-Net. Its GitHub page says "It uses google app engine (GAE) as a proxy server through the firewall" and "A Reborn GoAgent." https://github.com/XX-net/XX-Net

1 0

BSc Honor Track Research Topic
by Bram van den Heuvel 12 Jul '16

12 Jul '16

Dear all, I'm currently an undergraduate student double BSc Applied Mathematics/Computer Science. This year I'll be doing a small (~500 hour) research project as part of my Honor track. I'm looking for a suitable research question I can try to answer, preferrably by using mathematical modeling. To give you an idea what kind of research I was planning to do, I briefly described my current idea below. I was considering researching path selection, specifically the probability of selecting only faulty/malicious nodes and how this might be improved by including an extra reputation metric. This hypothetical reputation metric would be a "social" like reputation, based on for example real-world connections between people. In the most extreme case, one could choose a path of which all nodes are ran by real-world trusted people. As there might be a more usefull research question out there, I was wondering whether there are any questions that the Tor Project has that might be answered by using mathematical modelling. I could then consider to try and answer this question in my research project. Thanks in advance.

1 0

Re: [tor-dev] Using Tor Stealth HS with a home automation server
by Nathan Freitas 10 Jul '16

10 Jul '16

On Fri, Jul 8, 2016, at 10:38 PM, bancfc(a)openmailbox.org wrote: > On 2016-07-08 18:53, Nathan Freitas wrote: > > I've been working on some ideas about using Tor to secure "internet of > > things", smart devices other than phones, and other home / industrial > > automation infrastructure. Specifically, I think this could be a huge > > application for Tor Hidden Services and Onion sites configured with > > Hidden Service Authentication and "stealth" mode. > > > > Earlier this year, I published some ideas on the subject here > > https://github.com/n8fr8/talks/blob/master/onion_things/Internet%20of%20Oni… > > showing how you could use Orbot and IP Camera apps to build a > > cloud-free > > Tor-secured "Dropcam" style setup. > > > > Nice! An interesting Orbot feature to have is making QR Codes of > authenticated Hidden Service info so mobile devices can easily add each > other to a trusted network. That is a great idea. I am thinking of writing a module for the Home Assistant platform that would handle the tor install and setup, and it could autogenerate this QRcode as well. Any thoughts on a format? torhs://clientname:authcookie@foo.onion looks decent.

4 3

Using Tor Stealth HS with a home automation server
by Nathan Freitas 09 Jul '16

09 Jul '16

I've been working on some ideas about using Tor to secure "internet of things", smart devices other than phones, and other home / industrial automation infrastructure. Specifically, I think this could be a huge application for Tor Hidden Services and Onion sites configured with Hidden Service Authentication and "stealth" mode. Earlier this year, I published some ideas on the subject here https://github.com/n8fr8/talks/blob/master/onion_things/Internet%20of%20Oni… showing how you could use Orbot and IP Camera apps to build a cloud-free Tor-secured "Dropcam" style setup. Now, I've taken the first step to setup my own instance of Home Assistant "an open-source home automation platform running on Python 3. Track and control all devices at home and automate control. Installation in less than a minute." Instructions on this are below. It all seems to be working well, but I would love any feedback, comments, thoughts that you might have. I would also like to ensure that any work on next-gen HS designs includes these kinds of use-cases. *** Pull request for the new "Tor cookbook" example for Home Assistant: https://github.com/home-assistant/home-assistant.io/pull/627 *** Tor Onion Service Configuration This is an example about how you can configure Tor to provide secure remote access to your home assitance instance as an Onion site, through Tor’s Hidden Service feature. With this enabled, you do not need to open your firewall ports or setup HTTPS to enable secure remote access. This is useful if you want to have: Access your HA instance remotely without opening a firewall port or setting up a VPN Don’t want to or know how to get an SSL/TLS certificate and HTTPS configuration setup Want to block attackers from even being able to access/scan your port and server at all Want to block anyone from knowing your home IP address and seeing your traffic to your HA Background and Contact This configuration is part of an effort to apply strong cryptography technologies (like Onion Routing and End-to-End Encryption) to technology we increasingly depend on in our day to day lives. Just like when WhatsApp enabled end-to-end encryption messaging for everyone, every home automation and IoT platform should do the same, because A) the technology is all there, freely licensed and open-source and B) up to this point, all the commercial manufacturers have been doing a horrific job with security. You can learn more about how Tor can be used to secure home automation and IoT platforms through this short set of slides on the Internet of Onion Things This configuration was provided by @n8fr8 (github, twitter) of Guardian Project and Tor Project. You can send questions, feedback and ideas to support(a)guardianproject.info. Hidden Services and Onion Sites Tor allows clients and relays to offer hidden services. That is, you can offer a web server, SSH server, etc., without revealing your IP address to its users. In fact, because you don’t use any public address, you can run a hidden service from behind your firewall. Learn more about Hidden Services on the Tor Project website. Onion sites are websites that run on a Tor Hidden Service node. “dot onion” sites are an IETF recognized special use domain name. Setting up Tor on your Home Assistant First, install Tor. On a Debain-based system, you can install the package easily: > sudo apt-get install tor You can find more instructions for downloading and installing Tor on other platforms on the Tor Project Download Page. Next, modify Tor’s main configuration file /etc/tor/torrc to include the following lines: ... HiddenServiceDir /var/lib/tor/homeassistant/ HiddenServicePort 80 127.0.0.1:8123 HiddenServiceAuthorizeClient stealth haremote1 ... The “sleath” entry above ensures traffic to and from your HA instance over Tor, is hidden even from other nodes on the Tor network. The “haremote1” value is a generic client name entry that you can modify as you please. Then, restart Tor: >/etc/init.d/tor restart Then read the new generated authentication cookie from the Tor-generated hostname file: > sudo more /var/lib/tor/homeassistant/hostname The output of that command should look something like this, but with your own unique “dot onion” domain and authentication cookie: abcdef1234567890.onion ABCDEF1122334455667789 # client: haremote1 You are now done with the HA Tor server configuration. Make sure your HA instance is running, and now you can move to client configuration. Tor Client Access Setup Using this setup, you can access your HA instance over Tor from your laptop or mobile device, using Tor Browser and other software. Add the authentication cookie to your torrc client configuration on your laptop or mobile device. Using the sample values from above, it would look like this: HidServAuth abcdef1234567890.onion ABCDEF1122334455667789 For Tor Browser on Windows, Mac or Linux, you can find the torrc file here: <tor browser install directory>/Browser/TorBrowser/Data/Tor/torrc-defaults Once you have added the entry, restart the browser, and then browse to the “dot onion” site address to connect to your HA instance. For Orbot: Tor on Android, add it in Orbot->Menu->Settings to the “Torrc Custom Config” entry. Restart Orbot, and then use the Orfox browser app, and browse to the “dot onion” site name to access your HA instance. You can also use Orbot’s VPN mode, to enable Tor access from any application on your device, such as Tasker or Owntracks. On iOS, we have not fully tested this yet, but you should be able to add custom torrc entries on Onion Browser, Red Onion or TOBY browsers, all available in the iTunes App Store. Some More Advanced Ideas With this configuration, only you can access your HA instance Onion site through Tor, and no one else. You can share the authentication cookie with multiple devices and users, or you can generate a unique one for each - up to you! If you have multiple, say for an industrial, business or corporate configuration, this would provide an easy way to revoke access to a specific user or device. If you always access your HA instance via Tor, you can easily run this on an isolated “IoT” network segment at your install site, keeping your internal home network traffic seperate from any potentially compromised devices (like cheap “smart” lightbulbs with backdoors!). You could also use Tor as a means to connect your HA instance to a remote device, sensor or other service that you do not want to or connect provide a direct, open IP connection to. Again, Tor provides authenticated and confidential routing (aka “privacy and encryption”) by default, without having to setup TLS/SSL or VPN. It is just important to secure IoT nodes within your network, as it is to secure remote access! As mentioned, with Orbot on Android, you can enable a “full device” VPN mode, that allows any app you have to tunnel through Tor, even if it is not Tor or proxy aware. This means you should be able to enter your “dot onion” Onion site address into any app you want to access to your HA instance, and it should work.

2 1

Re: [tor-dev] Using Tor Stealth HS with a home automation server
by Nathan Freitas 08 Jul '16

08 Jul '16

Now published here: https://home-assistant.io/cookbook/tor_configuration/ On Fri, Jul 8, 2016, at 12:53 PM, Nathan Freitas wrote: > I've been working on some ideas about using Tor to secure "internet of > things", smart devices other than phones, and other home / industrial > automation infrastructure. Specifically, I think this could be a huge > application for Tor Hidden Services and Onion sites configured with > Hidden Service Authentication and "stealth" mode. > > Earlier this year, I published some ideas on the subject here > https://github.com/n8fr8/talks/blob/master/onion_things/Internet%20of%20Oni… > showing how you could use Orbot and IP Camera apps to build a cloud-free > Tor-secured "Dropcam" style setup. > > Now, I've taken the first step to setup my own instance of Home > Assistant "an open-source home automation platform running on Python 3. > Track and control all devices at home and automate control. Installation > in less than a minute." > > Instructions on this are below. It all seems to be working well, but I > would love any feedback, comments, thoughts that you might have. I would > also like to ensure that any work on next-gen HS designs includes these > kinds of use-cases. > > *** > Pull request for the new "Tor cookbook" example for Home Assistant: > https://github.com/home-assistant/home-assistant.io/pull/627 > > *** > > Tor Onion Service Configuration > > This is an example about how you can configure Tor to provide secure > remote access to your home assitance instance as an Onion site, through > Tor’s Hidden Service feature. With this enabled, you do not need to open > your firewall ports or setup HTTPS to enable secure remote access. > > This is useful if you want to have: > > Access your HA instance remotely without opening a firewall port or > setting up a VPN > Don’t want to or know how to get an SSL/TLS certificate and HTTPS > configuration setup > Want to block attackers from even being able to access/scan your port > and server at all > Want to block anyone from knowing your home IP address and seeing your > traffic to your HA > Background and Contact > > This configuration is part of an effort to apply strong cryptography > technologies (like Onion Routing and End-to-End Encryption) to > technology we increasingly depend on in our day to day lives. Just like > when WhatsApp enabled end-to-end encryption messaging for everyone, > every home automation and IoT platform should do the same, because A) > the technology is all there, freely licensed and open-source and B) up > to this point, all the commercial manufacturers have been doing a > horrific job with security. > > You can learn more about how Tor can be used to secure home automation > and IoT platforms through this short set of slides on the Internet of > Onion Things > > This configuration was provided by @n8fr8 (github, twitter) of Guardian > Project and Tor Project. You can send questions, feedback and ideas to > support(a)guardianproject.info. > > Hidden Services and Onion Sites > > Tor allows clients and relays to offer hidden services. That is, you can > offer a web server, SSH server, etc., without revealing your IP address > to its users. In fact, because you don’t use any public address, you can > run a hidden service from behind your firewall. Learn more about Hidden > Services on the Tor Project website. > > Onion sites are websites that run on a Tor Hidden Service node. “dot > onion” sites are an IETF recognized special use domain name. > > Setting up Tor on your Home Assistant > > First, install Tor. On a Debain-based system, you can install the > package easily: > > sudo apt-get install tor > > You can find more instructions for downloading and installing Tor on > other platforms on the Tor Project Download Page. > > Next, modify Tor’s main configuration file /etc/tor/torrc to include the > following lines: > > ... > HiddenServiceDir /var/lib/tor/homeassistant/ > HiddenServicePort 80 127.0.0.1:8123 > HiddenServiceAuthorizeClient stealth haremote1 > ... > The “sleath” entry above ensures traffic to and from your HA instance > over Tor, is hidden even from other nodes on the Tor network. The > “haremote1” value is a generic client name entry that you can modify as > you please. > > Then, restart Tor: >/etc/init.d/tor restart > > Then read the new generated authentication cookie from the Tor-generated > hostname file: > > sudo more /var/lib/tor/homeassistant/hostname > > The output of that command should look something like this, but with > your own unique “dot onion” domain and authentication cookie: > abcdef1234567890.onion ABCDEF1122334455667789 # client: haremote1 > > You are now done with the HA Tor server configuration. Make sure your HA > instance is running, and now you can move to client configuration. > > Tor Client Access Setup > > Using this setup, you can access your HA instance over Tor from your > laptop or mobile device, using Tor Browser and other software. > > Add the authentication cookie to your torrc client configuration on your > laptop or mobile device. Using the sample values from above, it would > look like this: > HidServAuth abcdef1234567890.onion ABCDEF1122334455667789 > > For Tor Browser on Windows, Mac or Linux, you can find the torrc file > here: > <tor browser install > directory>/Browser/TorBrowser/Data/Tor/torrc-defaults > Once you have added the entry, restart the browser, and then browse to > the “dot onion” site address to connect to your HA instance. > > For Orbot: Tor on Android, add it in Orbot->Menu->Settings to the “Torrc > Custom Config” entry. Restart Orbot, and then use the Orfox browser app, > and browse to the “dot onion” site name to access your HA instance. You > can also use Orbot’s VPN mode, to enable Tor access from any application > on your device, such as Tasker or Owntracks. > > On iOS, we have not fully tested this yet, but you should be able to add > custom torrc entries on Onion Browser, Red Onion or TOBY browsers, all > available in the iTunes App Store. > > Some More Advanced Ideas > > With this configuration, only you can access your HA instance Onion site > through Tor, and no one else. You can share the authentication cookie > with multiple devices and users, or you can generate a unique one for > each - up to you! If you have multiple, say for an industrial, business > or corporate configuration, this would provide an easy way to revoke > access to a specific user or device. > > If you always access your HA instance via Tor, you can easily run this > on an isolated “IoT” network segment at your install site, keeping your > internal home network traffic seperate from any potentially compromised > devices (like cheap “smart” lightbulbs with backdoors!). > > You could also use Tor as a means to connect your HA instance to a > remote device, sensor or other service that you do not want to or > connect provide a direct, open IP connection to. Again, Tor provides > authenticated and confidential routing (aka “privacy and encryption”) by > default, without having to setup TLS/SSL or VPN. It is just important to > secure IoT nodes within your network, as it is to secure remote access! > > As mentioned, with Orbot on Android, you can enable a “full device” VPN > mode, that allows any app you have to tunnel through Tor, even if it is > not Tor or proxy aware. This means you should be able to enter your “dot > onion” Onion site address into any app you want to access to your HA > instance, and it should work. > _______________________________________________ > tor-dev mailing list > tor-dev(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

1 0

metrics-lib/DescripTor 1.3.0 is released
by Karsten Loesing 07 Jul '16

07 Jul '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello devs, we just released metrics-lib/DescripTor 1.3.0: https://dist.torproject.org/descriptor/1.3.0/ - From the change log: # Changes in version 1.3.0 - 2016-07-06 * Medium changes - Parse "package" lines in consensuses and votes. - Support more than one "directory-signature" line in a vote, which may become relevant when authorities start signing votes using more than one algorithm. - Provide directory signatures in consensuses and votes in a list rather than a map to support multiple signatures made using the same identity key digest but different algorithms. - Be more lenient about digest lengths in directory signatures which may be longer or shorter than 20 bytes. - Parse "tunnelled-dir-server" lines in server descriptors. * Minor changes - Stop reporting "-----END .*-----" lines in v2 network statuses as unrecognized. Another, less visible improvement is that we're down to 0 checkstyle complaints! Happy descriptor parsing! All the best, Karsten -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJXfqObAAoJEC3ESO/4X7XBI3QIALoBgBHfrQCKKe2qrFfFFSh9 T0CAFTA4XDb/O+/4KJcSfglktD5jyhShVcwvdKyqQ1h0SHW9Zk+luWJju+h7JWpH DOu1ixG9Foh/CLFRrMs6UWaHQGbbU5mKrp1bqWplcWDC9nqbs/PNJg47JYjSke/J yx5U/ONxs6KhhSkQmLCxeN2xy0J6BntxaTZ6MyVWrSKv0af2JcruG7r1R7rQ6TEL k0wbV5riZmZeHY5XPYJup41oAvEB9S+AkECipSIBEHy9RhtFYUnYdEARvBMyA5yA 2QbJxD2aqlhUfGkL8S6qYWGfdREM7b9diMYwj/XDUxXt6gisuMPT+pM4HjEKkVk= =9yCN -----END PGP SIGNATURE-----

1 0

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

05 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