- tor-dev - lists.torproject.org

Named pipes with tor
by carlo von lynX 17 Apr '14

17 Apr '14

Hiya. Been around the tor dev community a bit, but today is my first day on the legendary tor-dev mailing list. I am asking if it makes sense to apply a minor patch to Tor source, but first, the use case: tor is very adamant at scrubbing the addresses that are being connected to in the logs, but I have the opposite wish case were I would like to have a terminal show me the addresses my tor is connecting to in real-time. Could be that the "arm" app would be able to do that without taking up the screen space that vidalia takes, but for some irrelevant reasons I am not using that. What I do is "Log [app]debug file /dev/shm/tor-log.txt", then run "tail -f /dev/shm/tor-log.txt | grep asked" to extract the "Client asked for <hostname>:<port>" lines, so I even get to see DNS requests independently from actual virtual circuits. I also have "SafeLogging" set appropriately. Needless to say, the RAM disk fills up quickly, so the usefulness is limited. This is a case screaming for unix named pipes as follows: mkfifo /dev/tor-log grep asked /dev/tor-log But tor refuses to write to such a FIFO pipe because it can't seek to the end of it. Couldn't open file for 'Log /dev/tor-log': Illegal seek ./or/config.c calls ./common/log.c's add_file_log which calls ./common/compat.c's tor_fd_seekend to make sure the stuff is appended at the end of a log. In the case of a FIFO pipe this returns an ESPIPE code which currently makes tor throw up. In my understanding it should be safe to ignore it, instead. We should expect the user to know what she is doing if she puts a pipe where the log should be. Or am I missing something? There is also a similar case of calling tor_fd_seekend in ./common/util.c which suggests there may be other use cases of mkfifo which are currently impeded by this. So the question is, would it be okay to catch ESPIPE in all cases, thus having it ignored in tor_fd_seekend, or just catch it in add_file_log? Or is there a reason to impede the use of unix named pipes under all circumstances? Best sockets from Berlin, CvL. -- http://youbroketheinternet.org ircs://psyced.org/youbroketheinternet

3 5

Improving the structure of indirect-connection PTs (meek/flashproxy)
by Ximin Luo 17 Apr '14

17 Apr '14

## Background Pluggable Transports are proxy programs that help users bypass censorship. [App client] -> XXX EVIL CENSOR HAS YOU XXX ACCESS DENIED XXX [App client] -> [PT client] -> (the cloud!) -> [PT server] -> [App server] The structural design, on the client side, is roughly: 1. App client specifies an endpoint to reach 2. PT client receives an instruction, via SOCKS, to connect to this endpoint 3. PT client does its thing, magic happens (intentionally vague) ## In Tor Each endpoint is specified by a Bridge line, in the form of an IP address and an optional fingerprint (for authentication). This point is not made more important in existing docs, but is important for the topic of this email: both the IP address and the fingerprint are potential *identifiers* of the endpoint. The former is an impure name, the latter a pure name. Currently, we have two main types of PT: - direct PTs - connect to the endpoint directly via a TCP connection - these PTs don't try to hide the fact that you're contacting X on addrX. - instead, they usually transform the traffic so it's not identifiable - e.g. obfs3, fte, scramblesuit - indirect PTs - connect to the endpoint indirectly, via special means - flashproxy - connects via an ephemeral browser proxy - meek - connects via an online web service I will now argue that indirect PTs should do things in a specific way, which is *not* the way meek and flashproxy currently does things. ## Meek and flashproxy Meek and flashproxy provide an indirect way of accessing Tor. Instead of connecting directly to a Bridge (which might be blocked), the client connects via a midpoint that is harder to block. Very very roughly, (meek/fp controller) [meek/fp client] -> [meek/fp midpoint] -> [freedom!] The Bridge line in the user's torrc is completely ignored, we use a dummy value, like: Bridge flashproxy 0.0.1.0:1 Instead, it is the controller that decides which endpoint (which Bridge) the midpoint should connect to. (In meek, the controller is the same entity as the midpoint, but it helps our analysis to consider the two functions separately.) ## The problem The problem with the above structure, is that it is incompatible with the metaphor of connecting to a specific endpoint. This is what the PT spec is about, even though it does not explicitly mention this viewpoint. Instead, meek and flashproxy provide the metaphor of connecting to a global homogeneous service. This has positive consequences, such as the user no longer having to bother to find Bridges, but also has several negative consequences: 1. The Tor client can no longer authenticate the endpoint. Although currently Tor makes this optional, it is strongly recommended, to prevent a MitM between the client and the server. Even if the midpoint does this, this is not end-to-end authentication that we would require for strong security. 2. Since the endpoints are not chosen by the user, this may have consequences for anonymity. IANAAR, but this has not yet been looked into. 3. The Tor client (and other applications that use the PT spec) internally use the endpoints metaphor. They may make performance assumptions based on endpoints being configured with different addresses. (Perhaps also security assumptions, although perhaps not due to having to defend against the sybil attack anyway.) Breaking this metaphor is not a good design principle. 4. An application like i2p, where each peer cares much more about *exactly which* endpoint it connects to (e.g. because e2e fingerprint authentication is mandatory), means the metaphor of endpoints even more important. They will not be able to take advantage of these indirect-connection PTs. 5. Chaining a PT that *requires* strong identification (e.g. scramblesuit, for c2s auth) is impossible under this scheme, since the end client cannot select the right server to authenticate against. ## The solution The solution is simple: the indirect PT client simply has to actually *make use* of the Bridge line, instead of totally dropping this information. The meek/flashproxy controllers offer service to a finite set of Bridges. [A] The client should be able to select one of these, specify its fingerprint and any other shared secrets, on their torrc Bridge line, and the indirect-PT will tell the controller to connect *to specifically this Bridge*. The controller should honour this request. If it doesn't and the fingerprint is specified, it will be caught out by the Tor client. So instead of having, as currently: (old, hacky) Bridge flashproxy (dummy addr) We would have the following cases: (1) Bridge flashproxy (real addr) (2) Bridge flashproxy (real addr) (fingerprint) (3, not-ideal) Bridge flashproxy (dummy addr) (fingerprint) Option (3) is quite nice, since in indirect PTs the actual address is irrelevant - the Tor client never tries to connect to it. I suggest that we have a special syntax for it though, to explicitly discourage hacks that {use dummy addresses but which are treated as real addresses by the underlying application}, since this breaks assumptions of the PT spec. For example, (3, better) Bridge flashproxy - (fingerprint) We would add to the PT spec, something like: "-" is a special hostname syntax in Bridge lines. It means that the address of this Bridge does not concern the underlying application (e.g. Tor), since it will be indirectly reached by the PT client. (If a fingerprint is given, it will still be checked by Tor.) Using this syntax, we would have conscious application-level awareness for the current behaviour: (old, hacky) Bridge flashproxy (dummy address) (4) Bridge flashproxy - for clients that really don't care about the exact endpoint, nor strong e2e authentication. This can be taken by the controller to mean "give me any endpoint, I really don't care". However, we should distinguish this from the error case: (5) Bridge flashproxy (real addr, but not in whitelist) (*) (6) Bridge flashproxy (*) (fpr, but not in whitelist) In these cases, the user is asking for something the controller cannot give them. Instead of falling back to the "give-me-any" behaviour of (4), the PT client should raise an error. (However, returning an error from the controller is not possible with flashproxy's design; it's not clear what the ideal behaviour in this case would be.) X Note: I had previously filed a ticket for this, though it is only recently that I realised that it had many more consequences (the topic of this email): https://trac.torproject.org/projects/tor/ticket/10196 It currently misses out some of the more advanced solutions I presented. [A] Currently these are finite sets pre-selected by the controller. There is a security issue with simply allowing users to specify *any* IP address for the midpoint to connect to. [1] So whitelisting is the simplest approach, for now. In the future we may think about ways to allow access to "any Tor Bridge", but there are security implications here as well. [1] https://trac.torproject.org/projects/tor/ticket/10196#comment:1 -- GPG: 4096R/1318EFAC5FBBDBCE git://github.com/infinity0/pubkeys.git

3 8

Heard of the Net Mundial meeting next week?
by MSvB 16 Apr '14

16 Apr '14

Hello list, There's a meeting [1] of one or two dozen delegate countries relating to Internet governance in Sao Paulo next week. A typical discussion topic is UNESCO's proposal [2] (search for 'privacy' or 'anonymity'.) Maybe a little off topic here, but this could be considered of peripheral interest given that states influence regional IP registries and sometimes attempt gatekeeping of border routes. [1] http://www.netmundial.br/ [2] http://content.netmundial.br/contribution/unesco-comprehensive-study-on-int… Regards, Michael

3 3

Tor Challenge for onboarding developers?
by Helder Ribeiro 16 Apr '14

16 Apr '14

The Eudyptula Challenge is for kernel hacking and was inspired by the Matasano Challenges. I hear that several patches are already being submitted to the Linux kernel thanks to its "onboarding process" nature. http://eudyptula-challenge.org/ Would something like this make sense for Tor? Is there any active work under way on improving developer onboarding? Thanks. Cheers, Helder

2 1

Proposal 230: How to change RSA1024 relay identity keys
by Nick Mathewson 15 Apr '14

15 Apr '14

Here's a design for what to do to support a massive RSA1024 relay key migration, if we need to do another one in the future. (I'm not sure whether this is timely for responding to CVE-2014-0160 or not; possibly not.) Filename: 230-rsa1024-relay-id-migration.txt Title: How to change RSA1024 relay identity keys Authors: Nick Mathewson Created: 7 April 2014 Target: 0.2.? Status: Draft 1. Intro and motivation Some times, a relay would like to migrate from one RSA1024 identity key to another without losing its previous status. This is especially important because proposal 220 ("Migrate server identity keys to Ed25519") is not yet implemented, and so server identity keys are not kept offline. So when an OpenSSL bug like CVE-2014-0160 makes memory-reading attacks a threat to identity keys, we need a way for routers to migrate ASAP. This proposal does not cover migrating RSA1024 OR identity keys for authorities. 2. Design I propose that when a relay changes its identity key, it should include a "old-identity" field in its server descriptor for 60 days after the migration. This old-identity would include the old RSA1024 identity, a signature of the new identity key with the old one, and the date when the migration occurred. This field would appear as an "old-id" field in microdescriptors, containing a SHA1 fingerprint of the old identity key, if the signature turned out to be value. Authorities would store old-identity => new-identity mappings, and: * Treat history information (wfu, mtbf, [and what else?]) from old identities as applying to new identities instead. * No longer accept any routers descriptors signed by the old identity. Clients would migrate any guard entries for the old identity to the new identity. (This will break clients connections for clients who try to connect to the old identity key before learning about the new one, but the window there won't be large for any single router.) 3. Descriptor format details Router descriptors may contain these new elements: "old-rsa1024-id-key" NL RSA_KEY NL Contains an old RSA1024 identity key. If this appears, old-rsa1024-id-migration must also appear. [At most once] "old-rsa1024-id-migration" SP ISO-TIME NL SIGNATURE NL Contains a signature of: The bytes "RSA1024 ID MIGRATION" [20 bytes] The ISO-TIME field above as an 8 byte field [8 bytes] A SHA256 hash of the new identity [32 bytes] If this appears, "old-rsa1024-id-key" must also appear. [At most once]. 4. Interface To use this feature, a router should rename its secret_id_key file to secret_id_key_OLD. The first time that Tor starts and finds a secret_id_key_OLD file, it generates a new ID key if one is not present, and generates the text of the old-rsa-1024-id-key and old-rsa1024-id-migration fields above. It stores them in a new "old_id_key_migration" file, and deletes the secret_id_key_OLD file. It includes them in its desecriptors. Sixty days after the stored timestamp, the router deletes the "old_id_key_migration" file and stops including its contents in the descriptor.

3 3

updated two tor-spec proposals
by Virgil Griffith 14 Apr '14

14 Apr '14

The URLs are the same. They are: (1) http://dl.dropbox.com/u/3308162/230-quicken-tor2web-mode.txt (2) http://dl.dropbox.com/u/3308162/231-remittance-addresses.txt I clarified them a bit and corrected the formatting. Previously people asked for more details such as what other specs will be affected, there are the two references in 230 and in 231 there is no interaction with existing specs. If more changes need to be made please state so. Otherwise I request these be merged. -V

2 1

Proposal 232: Pluggable Transport through SOCKS proxy [was Re: ideas/xxx-pluggable-transports-through-proxy.txt]
by Nick Mathewson 14 Apr '14

14 Apr '14

On Fri, Apr 11, 2014 at 2:16 AM, Yawning Angel <yawning(a)schwanenlied.me> wrote: > Hello, Thanks! I've applied your patch and turned the writeup into proposal 232. It's currently marked as targeting 0.2.6, since that's where #8402 is now. (please comment on that ticket if it's really really super important to shove it into 0.2.5.) best wishes, -- Nick

1 0

Implications of openssl bug on directory authorities
by Roger Dingledine 14 Apr '14

14 Apr '14

Part one: Facts as I understand them ------------------------------------ There are 9 directory authorities, and clients only believe a consensus networkstatus if it's signed by a majority (5) of them. Two (moria1 and urras) of the directory authorities were unaffected by the openssl bug, and seven were affected. Zero of the seven have generated new relay identity keys, because current clients expect them to be at their current IP:port:fingerprint and would scream in their logs and refuse to connect if the relay identity key changes. Five of the seven have upgraded their openssl, and two (turtles and dannenberg) are offline pending an upgrade. Three of the seven (maatuska, gabelmoo, Faravahar) have generated new directory signing keys, and four haven't yet. More specifically, Have new signing key: maatuska old expires 2014-06-11 09:25:09 gabelmoo old expires 2015-01-11 16:26:31 Faravahar old expires 2015-01-16 03:52:30 Need new signing key: tor26 current expires 2015-02-11 17:19:09 dannenberg current expires 2014-07-17 11:10:09 turtles current expires 2014-04-20 20:01:01 dizum current expires 2014-08-12 10:18:26 So until 2014-07-17 an adversary who stole the signing keys of gabelmoo, Faravahar, tor26, dannenberg, and dizum could fabricate a convincing consensus. I've confirmed that in fact Tor clients are happy to receive a consensus signed by old signing keys (until we've fixed #11458). It would be a bit tricky in practice to deliver a fake consensus to clients, since they check the relay identity keys of the directory authorities if they're bootstrapping from them. But we could imagine that the same attack that got the directory signing key might get the relay identity key too. Also, clients that use evil bridges, or that have already bootstrapped and happen to go to an evil directory mirror, are other avenues for attack. And finally, there are zero known cases of anybody extracting relay identity keys from relays using this attack. Some people have tried a bit and failed. Part two: One way forward ------------------------- It is a leap to assume that >=5 signing keys are in the hands of the adversary, but it's also a leap to assume they're not. Here is plan 1: A) All seven of the vulnerable directory authorities generate new long-term authority identity keys. B) They use their old authority identity keys as legacy signers, a la proposal 136: https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/136-legacy-k… (Remember the good old days when we had warning about horrible bugs and could design a fix beforehand?) C) They run their new authorities on different IP:ports, with a fresh relay identity key, so as not to conflict with the old IP:ports. D) We change the code to point to the new IP:ports:fingerprints and put out new Tor releases. E) Authority operators run a new normal relay on the old IP:ports, using the old relay identity key, and with torrc options like FetchDirInfoExtraEarly. These relays either run sufficiently new Tor versions, or set their DirServers lines to point to the new authorities. I haven't tried 'E' yet, and it might break horribly to have a normal relay serve all the directory authority documents. But it seems doable. For comparison, here is plan 2: We wait until 2014-07-17 and hope that in the mean time nobody gets attacked by the keys that surely no adversary actually has. Anybody have a plan 3? --Roger

2 3

Minor Onionoo specification changes in bandwidth and uptime documents
by Karsten Loesing 13 Apr '14

13 Apr '14

Hello everyone, I'm pondering to make the following possibly backward-incompatible changes to the Onionoo specification: - Make write_history and read_history in bandwidth documents optional. We need to make sure that all known Onionoo clients can handle this change and don't break if these formerly required fields go away. - While doing so, let's make uptime in bridge uptime documents optional. That will also make it consistent with relay uptime documents. This change is not directly related to this bug, but leaving this field required seems inconsistent. More details on this ticket: https://trac.torproject.org/projects/tor/ticket/11428 Please let me know before Wednesday, April 16, if these changes would cause major issues with processing Onionoo data. Thanks! All the best, Karsten

1 0

ideas/xxx-pluggable-transports-through-proxy.txt
by Yawning Angel 11 Apr '14

11 Apr '14

Hello, The topic of routing pluggable transports through other proxys (SOCKS and HTTP CONNECT) has come up a few times recent, both as bug reports from users and as something that probably should be done to round out the pluggable transport concept since they will be included in the browser bundle by default. Relevant bugs: * #8402 - Tor should help its transport proxy use a proxy, if needed. * #8956 - obfsproxy should use a SOCKS proxy if Tor wants it to * #11409 - Obfsproxy through HTTP proxy There is one change that also needs to be made to the idea document (diff attached) that changes one of the return codes to be slightly more in line with the rest of the PT protocol chatter. As far as code support goes: * tor done, not merged, needs review by nickm or similar (branch linked from #8402). It *may* have rotted since it got triaged as a 0.2.6 thing right before I started working on this, but if that's the case I will update it as needed. * pyptlib, done not merged. Waiting on #8402. * obfsproxy, SOCKS4/5 done, not merged. HTTP CONNECT is a work in progress, needs the pyptlib changes. Regards, -- Yawning Angel From 3ad31e8727b46ef46b73d11764ca5fec15c5b57c Mon Sep 17 00:00:00 2001 From: Yawning Angel <yawning(a)torproject.org> Date: Fri, 11 Apr 2014 06:12:32 +0000 Subject: [PATCH 1/1] Change "PROXY true" to "PROXY DONE" for consistency. --- proposals/ideas/xxx-pluggable-transports-through-proxy.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/proposals/ideas/xxx-pluggable-transports-through-proxy.txt b/proposals/ideas/xxx-pluggable-transports-through-proxy.txt index 3fc7754..e03a6b9 100644 --- a/proposals/ideas/xxx-pluggable-transports-through-proxy.txt +++ b/proposals/ideas/xxx-pluggable-transports-through-proxy.txt @@ -69,7 +69,7 @@ Specifications: Tor Pluggable Transport communication If the pluggable transport proxy detects that the TOR_PT_PROXY environment variable is set, it attempts connecting to it. On - success it writes to stdout: "PROXY true". + success it writes to stdout: "PROXY DONE". On failure it writes: "PROXY-ERROR <errormessage>". If Tor does not read a PROXY line or it reads a PROXY-ERROR line -- 1.9.2

2 1