April 2014 - tor-dev - lists.torproject.org

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

Pluggable transports meeting today (Friday 11th of April 2014)
by George Kadianakis 11 Apr '14

11 Apr '14

Greetings humans, this is an email to remind you that the regular biweekly pluggable transports meeting is going to happen today. Place is the #tor-dev IRC channel in OFTC. Time is 17:00 UTC. Cheers!

1 0

Has there been a security evaluation of the Hola routing software?
by Virgil Griffith 10 Apr '14

10 Apr '14

www.hola.org First impression it looks they aim to do the same things Tor does.

2 1

bulb: a tor relay web status dashboard
by Arlo Breault 08 Apr '14

08 Apr '14

There's not much to it yet, but I thought I'd share. https://github.com/arlolra/bulb Contributions welcome! Arlo

1 0