- tor-dev - lists.torproject.org

Re: [tor-dev] Help hacking Mumble
by Matt 24 Feb '14

24 Feb '14

On Fri, 07 Feb 2014 09:54:35 +0400 meejah <meejah(a)meejah.ca> wrote: > What I would suggest: > > 1. change ConnectDialog so that it always uses not-yet-looked-up > QHostAddresses (perhaps only if a proxy is enabled). This still > won't help Tor, since they're sending UDP. > > 2. change Cert.cpp so it doesn't have to do a host-lookup. I sort-of > asked in my other email, but does this actually gain anything? > That is, does checking that the domain looks up "to something" really > accomplish anything useful? If the answer is "yes", then more > thinking; all I can think of is attempting a TCP/UDP connection > (again, with a not-yet-looked-up QHostAddress) to the server in > question (which will only work if there is a well-known port upon > which it should be listening to be considered valid). > I haven't actually confirmed that there is a DNS leak here. I've been focusing mostly on ConnectDialog, but mentioned Cert because it also had DNS-related code that I hadn't spent as much time with. > 3. suggest/document that Tor uses need to un-set the "show reachable" > (Settings::ShowReachable) option so that a server doesn't need a > valid ping-reply to show up in the list. > > Another option might be to factor out all the "ping" stuff to its own > class and simply not instatiate/use it when ShowReachable is off (or > have a separate option for pinging all the servers). > > Yet another different option might be to just have an option to turn > off the pinging of servers, leaving open the Cert.cpp question (which > one could also punt on by having an option). Then the game would be > to get Tor users to have the right options enabled ;) > I tried to do something like this in my branch; optionally turning off pings to Public and LAN servers was easy. Turning off pings to Favorite servers seemed a little trickier, especially if they are still to remain reachable. Thanks for all the pointers. A C++ developer volunteered to take a closer look at this issue. At this point, I think further discussion would most useful for all parties if it moved onto the bug ticket: https://github.com/mumble-voip/mumble/issues/1033

2 1

Weekly Tor dev meeting: Tuesday 25 Feb, 20:00 UTC
by Nick Mathewson 24 Feb '14

24 Feb '14

Hi, all! We're going to start trying to have a developer's meeting for working on the program "tor". (This won't cover all the other programs developed under the Tor umbrella.) My tentative plan is to do it on the #tor-dev IRC channel, unless the meeting turns out to be too disruptive for the rest of the channel or vice versa. We'll have a lot to do, and we won't get it all done: this will only go on for an hour or so. But we'll do another one next week. These meetings probably won't be very well run for a while. It will be 3pm EST and 12:00 noon PST. Unless I am mistaken, that's 20:00 UTC. but I've been travelling for a while, and adding five is hard. peace, -- Nick

5 4

Re: [tor-dev] GSOC Idea
by Devang Thakkar 24 Feb '14

24 Feb '14

Hi Damian, nice to know you. I wanted to suggest using Tor for web scraping, I mean, like creating a feature like Firebug/XPather are for Mozilla Firefox. That would easily help users to scrape easily and anonymously. Can this be considered as a valid idea for a GSOC project? Thanks, Devang

2 1

obfsproxy-0.2.6: Gentoo package
by George Kadianakis 24 Feb '14

24 Feb '14

Hey blueness, just wanted to say thanks for supporting obfsproxy-0.2.6 so quickly. I was about to send you an email, but I just noticed that obfsproxy-0.2.6 is already in portage. Just a small comment, the pkg_postinst() is a bit outdated since it references the old obfs2 transport (which we are starting to deprecate), and doesn't mention the new scramblesuit transport: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-proxy/obfsproxy… Maybe you could steal the post-install hook from the Debian packages? You can find it here: https://packages.debian.org/sid/obfsproxy http://ftp.de.debian.org/debian/pool/main/o/obfsproxy/obfsproxy_0.2.6-2.deb… specifically in the file README.Debian . Thanks :)

1 0

Re: [tor-dev] obfsproxy dns transport
by George Kadianakis 23 Feb '14

23 Feb '14

> > > George, > > I'd like to write a dns transport... and it seems to me the > obfsproxy api isn't designed for non tcp transports... > Maybe we again make some changes to the obfsproxy api? > It would transport IP packets using a tun device... > we can route it to a socks endpoint and proxy from there. > > I think there is a whole class of obfuscated transports that could benefit > from an obfsproxy plugin interface for vpns... transports that use a tun > interface... > > I'll have to take a closer look at the obfsproxy api and think about this > some more. > I was just curious to see if you had any thoughts on the subject. > > There is this interesting code to learn about dns transport here: > https://code.google.com/p/dnscapy/ > it uses the scapy automatom api instead of twisted. Could easily be ported > to twisted I think. > > Feel free to forward your response to the tor-dev mailing list. > No hurry. No worry. > > Cheers! > > David > Hello David! I won't be able to answer thoroughly atm since I'm at the dev meeting. I will be back home soon and be able to answer more smoothly. In general, a DNS transport would be great! A well designed DNS transport would be a PITA to block and would also work in most networks (even through captive portals etc.). The short answer is that obfsproxy is indeed not designed to facilitate PTs like DNS transports. It will probably require a considerable refactor of obfsproxy to write a DNS pluggable transport. It will probably require so much refactoring that I'm not sure if it would make sense to merge the changes back upstream (because the changes might not be useful for other PTs). The main reason you want to use obfsproxy is so that you don't have to write your own SOCKS code, or your own Extended ORPort code, or your own PT-protocol code. That said, here are two other approaches you can take: a) You can "fork" obfsproxy, perform your changes, and then we can deploy your fork as a standalone PT. Since obfsproxy's architecture is designed to support multiple PTs you might have to perform considerable changes to obfsproxy; but that's fine, since you will be the only one using that fork of obfsproxy. A small problem with this approach is that we will have to deploy two obfsproxy codebases which will increase the size of the bundle. The good news is that the size of the obfsproxy codebase in the latest TBBs prepared by David is only 350Kb which is not too much even if doubled. b) You can write your own Python code and selectively steal code from obfsproxy. You will have to steal the code that does networking, Extended ORPort, environment variable parsing (pyptlib), SOCKS, etc. This might not be too hard. Alternatively you can use Go, and use David's goptlib library [0] which does both Extended ORPort and SOCKS. Also, before you start writing code, it might be worth looking at the pt-spec and seeing if it can support DNS PTs as it is. BTW, do you know of any censorship circumvention tools that use DNS as a covert channel? [0]: https://gitweb.torproject.org/pluggable-transports/goptlib.git

4 8

Request for references for anonymous blocklisting (blacklisting)
by Virgil Griffith 23 Feb '14

23 Feb '14

I'm putting together a proposal for adding anonymous blocklisting into the Tor such that websites that block Tor can block single problematic users instead of all Tor exit nodes. Towards this end, I am looking for papers/prior work in this area to draw from. Pointers anyone? Enjoyed the Iceland conference. Thank you Roger for inviting me! I aim to be contributing to Tor more over the year. -Virgil

2 1

Proposal: namecoin-integration.txt
by Joe Foe 22 Feb '14

22 Feb '14

Filename: namecoin-integration.txt Title: Improve security and usability by Namecoin integration Author: Maxim Novoselov Created: 06-Feb-2014 Status: Open Overview: This document describes enchantments of hidden services domain names with integration of namecoin domains. Motivation: Currently user must lookup hidden service domain name in various directories. This directories are owned not by the hidden service owner so hidden service address can be easily spoofed by owners of this directories. Found service name is immemorable so user tends to add it to the bookmarks which leads to (maybe)harmful trails. This adds ability to use also original .bit domains and improves tor's ecosystem in general. Design: Hidden service owner registers special domain name using namecoin and binds it to the .onion hidden service. That way he anonymously claims that this service owned by him and he can control it using namecoin system. This special domain name tld must differ from .bit and .onion to avoid confusion because they are already used by clear-web sites(.bit) and deep-web ip-address surrogate(.onion). Hidden service client lookup domain name at namecoin and connects to the resolved .onion domain. Security implications: Proposed changes improve total security by decentralizing directory services and give ability to hidden service owners to claim their names. Also it makes end-user more anonimous by forcing him not to use bookmarks. Specification: Compatibility: Implementation: This can't be implemented using namecoin DNS'es because they are operated by third-party and may be forged. Good way is to use namecoin-rpc to query domain names. Its easy but requires namecoin software running which is storage space intensive. So not every user have ability to support namecoin server and we have to provide a choice: use local copy of bitcoin-rpc or remote. Even better would be to integrate namecoin-rpc into production but only for nodes or bridges and use this nodes as internal DNS alternative for enduser-tor-clients. -- Best regards

1 0

Proposal 227: Include package fingerprints in consensus documents
by Nick Mathewson 21 Feb '14

21 Feb '14

Here's a new proposal for a thing that Mike wants for TBB. Please review! Filename: 227-vote-on-package-fingerprints.txt Title: Include package fingerprints in consensus documents Author: Nick Mathewson, Mike Perry Created: 2014-02-14 Status: Open 0. Abstract We propose extending the Tor consensus document to include digests of the latest versions of one or more package files, to allow software using Tor to determine its up-to-dateness, and help users verify that they are getting the correct software. 1. Introduction To improve the integrity and security of updates, it would be useful to provide a way to authenticate the latest versions of core Tor software through the consensus. By listing a location with this information for each version of each package, we can augment the update process of Tor software to authenticate the packages it downloads through the Tor consensus. 2. Proposal We introduce a new line for inclusion in votes and consensuses. Its format is: "package" SP PACKAGENAME SP VERSION SP URL SP DIGESTS NL PACKAGENAME = NONSPACE VERSION = NONSPACE URL = NONSPACE DIGESTS = DIGEST | DIGESTS SP DIGEST DIGEST = DIGESTTYPE "=" BASE64 NONSPACE = one or more non-space printing characters BASE64 = one or more base-64 characters, with trailing =s removed. SP = " " NL = a newline Votes and consensuses may include any number of "package" lines, but no vote or consensus may include more than one "package" line with the same PACKAGENAME and VERSION values. All "package" lines must be sorted by PACKAGENAME, and then by VERSION, in lexical (strcmp) order. If the consensus-method is at least (TBD), then when computing the consensus, package lines for a given PACKAGENAME/VERSION pair should be included if at least three authorities list such a package in their votes. (Call these lines the "input" lines for PACKAGENAME.) That consensus should contain every "package" line that is listed verbatim by more than half of the authorities listing a line for the PACKAGENAME/VERSION pair, and no others. These lines appear immediately following the client-versions and server-versions lines. 3. Recommended usage Programs that want to use this facility should pick their PACKAGENAME values, and arrange to have their versions listed in the consensus by at least three friendly authority operators. Programs may want to have multiple PACKAGENAME values in order to keep separate lists. These lists could correspond to how the software is used (as tor has client-versions and server-versions); or to a release series (as in tbb-alpha, tbb-beta, and tbb-stable); or to how bad it is to use versions not listed (as in foo-noknownexploits, foo-recommended). Programs MUST NOT use "package" lines from consensuses that have not been verified and accepted as valid according to the rules in dir-spec.txt, and SHOULD NOT fetch their own consensuses if there is a tor process also running that can fetch the consensus itself. For safety, programs MAY want to disable functionality until confirming that their versions are acceptable. To avoid synchronization problems, programs that use the DIGEST field to store a digest of the contents of the URL SHOULD NOT use any URLs whose contents are expected to change while any valid consensus lists them. 3.1. Intended usage by the Tor Browser Bundle Tor Browser Bundle packages will be listed with package names 'tbb-stable, 'tbb-beta', and 'tbb-alpha'. We will list a line for the latest version of each release series. When the updater downloads a new update, it always downloads the latest version of the Tor Browser Bundle. Because of this, and because we will only use these lines to authenticate updates, we should not need to list more than one version per series in the consensus. After completing a package download and verifying the download signatures (which are handled independently from the Tor Consensus), it will consult the appropriate current consensus document through the control port. If the current consensus timestamp is not yet more recent than the proposed update timestamp, the updater will delay installing the package until a consensus timestamp that is more recent than the update timestamp has been obtained by the Tor client. If the consensus document has a package line for the current release series with a matching version, it will then download the file at the specified URL, and then compute its hash to make sure it matches the value in the consensus. If the hash matches, the Tor Browser will download the file and parse its contents, which will be a JSON file which lists information needed to verify the hashes of the downloaded update file. If the hash does not match, the Tor Browser Bundle should display an error to the user and not install the package. If there are no package lines in the consensus for the expected version, the updater will delay installing the update (but the bundle should still inform the user they are out of date and may update manually). If there are no package lines in the consensus for the current release series at all, the updater should install the package using only normal signature verification. 4. Limitations and open questions This proposal won't tell users how to upgrade, or even exactly what version to upgrade to. If software is so broken that it won't start at all, or shouldn't be started at all, this proposal can't help with that. This proposal is not a substitute for a proper software update tool.

3 3

Re: [tor-dev] Registering special-use domain names of peer-to-peer name systems with IETF
by John Bond 20 Feb '14

20 Feb '14

Hello All, Im writing to the list in response to IETF submission made by christian. This has created much debate on the DNSOPS mailing list[1] and has also seen another draft to be proposed[2]. I will start by saying I see merit in both drafts being proposed[3][4] and don¹t necessarily see them as being mutually exclusive. However the discussions on the list seem to keep coming back to one question would it be feasible for you to retrospectively change the anchor of .onion to some other TLD. E.g. .onion.arpa. There is much speculation on this questions however it appears that the question has not been directly asked on this list. Therefore I would like to ask the following. - What would be the barriers both, technical and political, for tor to change the anchor it uses from .onion to something else (whatever that may be)? - If such a change where to happen what would be an acceptable timeline for new software to stop supporting the old anchor? - If the .onion is unsuccessful in its request to be reserver under the mechanism laid out in rfc 6761[5]. Would there be any motivation to change the anchor so that it conformed to a different policy and therefore allow operators and developers to prevent leakage of this name on the internet - Are there any privacy concerns caused by .onion names leaking on to the internet in the form of a DNS QNAME by software trying to resolve the name - If an organisation where to obtain the .onion name under the gTLD programme are there any privacy concerns considering the organisation could now answer the DNS queries mentioned above. I.e. If a user requested notatrap.onion without tor configured instead of getting no response the could be redirected to a site controlled by the new owner of the .onion domain. Thanks John [1]http://www.ietf.org/mail-archive/web/dnsop/current/msg10785.html [2]http://www.ietf.org/mail-archive/web/dnsop/current/msg11074.html [3]http://tools.ietf.org/html/draft-grothoff-iesg-special-use-p2p-names-01 [4]http://tools.ietf.org/html/draft-wkumari-dnsop-alt-tld-00 [5]http://tools.ietf.org/html/rfc6761

2 2

Future pluggable/lib obfus transport?
by grarpamp 20 Feb '14

20 Feb '14

> The short answer is that obfsproxy is indeed not designed to > facilitate PTs like DNS transports. It will probably require a > considerable refactor of obfsproxy to write a DNS pluggable > transport. It will probably require so much refactoring that I'm not > sure if it would make sense to merge the changes back upstream > (because the changes might not be useful for other PTs). Re the above from George, and some talk I see about obfs versions, am I right that obfsproxy is not yet a general pluggable transport tool? As in a library and/or standalone proxy that two endpoints put in front of themselves, choose from a menu of (or negotiate) obfus and say go in a nearly automatic fashion? A C/python library interface would be interesting, as would deciding what the standalone proxy might be among socks5, transparent firewall redirection, tun interface, etc. In addition to DNS, people have written HTTP, IRC, ICMP, raw IP, etc tunneling tools in the past.

2 1