- tor-dev - lists.torproject.org

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

Proposal 231: Migrating authority RSA1024 identity keys
by Nick Mathewson 08 Apr '14

08 Apr '14

This is a companion proposal to 230. Filename: 231-migrate-authority-rsa1024-ids.txt Title: Migrating authority RSA1024 identity keys Authors: Nick Mathewson Created: 8 April 2014 Target: 0.2.? Status: Draft 1. Intro and motivation We'd like for RSA1024 identity keys to die out entirely. But we may need to migrate authority identity keys before that happens. 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 authorities to migrate ASAP. Migrating authority ID keys is a trickier problem than migrating router ID keys, since the authority RSA1024 keys are hardwired in the source. We use them to authenticate encrypted OR connections to authorities that we use to publish and retrieve directory information. This proposal does not cover migrating RSA1024 OR identity keys for other nodes; for that, see proposal 230. 2. Design When an authority is using a new RSA1024 key, it retains the old one in a "legacy_link_id_key" file. It uses this key to perform link protocol handshakes at its old address:port, and it uses the new key to perform link protocol handshakes at a new address:port. This should be sufficient for all clients that expect the old address:port:fingerprint to work, while allowing new clients to use the correct address:port:fingerprint. Authorities will sign their own router descriptors with their new identity key, and won't advertise the old port or fingerprint at all in their descriptors. This shouldn't break anything, so far as I know. 3. Implementation We'll have a new flag on an ORPort: "LegacyIDKey". It implies NoAdvertise. If it is present, we use our LegacyIDKey for that ORPort and that ORPort, for all of: * The TLS certificate chains used in the v1 and v2 link protocol handshake. * The certificate chains and declared identity in the v3 link handshake. * Accepting ntor cells. 4. Open questions On ticket #11448, Robert Ransom suggests that authorities may need to publish extra server descriptors for themselves, signed with the old identity key too. We should investigate whether clients will misbehave if they can't find such descriptors. If that's the case, authorities should generate these descriptors, but not include them in votes or the consensus; or if they are included, don't assign them flags that will get them used.

1 0

Request for feedback on public hidden services: shroud
by Alan Shreve 08 Apr '14

08 Apr '14

Hi Tor devs! I’d like your feedback on a new system to provide public hidden services that I call "shroud”. By “public hidden services”, I mean services whose network location cannot be determined (like Tor hidden services) but are accessible by any client on the internet (like hidden services + Tor2Web). I’ve linked to what I think is pretty comprehensive documentation at the end of this message, but here’s a brief summary: Shroud runs over Tor with zero changes to the protocol but *does not* use the Tor hidden service protocol. At a very high level, shroud creates something like a reverse ssh tunnel *over* Tor from a local service to a public proxy. You then point DNS for a domain to the public proxy servers so that internet clients can talk to it. The public proxy servers multiplex TLS connections by inspecting the SNI data and forward the connection through to the appropriate shrouded service over its reverse tunnel. Obviously, shroud makes a number of tradeoffs compared to traditional hidden services and Tor2Web, the most important being: - Shrouded services have real hostname addresses and look just like any “ordinary” web service. - Shrouded services (anecdotally) have better latency characteristics than Tor hidden services - Shrouded services provide no anonymity for clients - Shrouded services are dependent on their public proxy servers being available - Shrouded services rely on DNS and are at the mercy of DNS providers and registrars (excepting things like modifying your /etc/hosts) - Public proxies can not inspect or modify the connections they proxy because they are TLS-encrypted with keys they don’t own Shroud is still very early in development, so I’m looking for feedback from the community on all aspects of the system from overall architecture to UI. In particular, I have a number of questions that I’m researching that I could use guidance on from those of you already steeped in Tor: 1. Shrouded services open up a single long-lived connection TLS connection to their public proxy. Is this a risk that could make it easier to de-anonymize a service? Would it be more difficult for an attacker to locate the service if the service opened a new connection over a new circuit every X seconds? Would it be more difficult for an attacker if the shrouded service communicated with the public proxy over multiple connections over multiple circuits simultaneously? 2. Right now shroud only allows you to tunnel TLS connections on domains you control with the idea that it eases the burden on public proxy operators (namely me). This is kind of akin to having an exit node with a policy that it only allows TLS connections out. Am I worrying too much about the consequences proxying traffic that could be inspected? Allowing non-TLS services would make it *far* easier to set up a shrouded service because a shrouded service provider would 1. not have to own a domain, and 2. not need to create TLS key pairs and acquire certificates. 3. Is this a useful system? I feel like tor2web validates that there are use cases that could benefit from this type of asymmetric anonymity where only the service provider is anonymous, but perhaps someone else can indicate whether this is a path worth pursuing. Links: Source code and documentation: https://github.com/inconshreveable/shroud More in-depth documentation on shroud’s architecture: https://github.com/inconshreveable/shroud/blob/master/docs/ARCHITECTURE.md Pre-built binaries (just for testing/demonstration): Linux: http://dl.shroud.io/linux_386/dev/shroud.zip OS X: http://dl.shroud.io/darwin_amd64/dev/shroud.zip Windows: http://dl.shroud.io/windows_386/dev/shroud.zip Thanks! - alan

1 0

Re: [tor-dev] [RFC] Proposal draft: The move to a single guard node
by Nicholas Hopper 07 Apr '14

07 Apr '14

On Mon, Apr 7, 2014 at 11:34 AM, George Kadianakis > So, based on your response, IIUC, the idea is that because young > guards are underutilized, we want to increase the probability of them > being chosen in non-guard positions, so that they become more utilized > till more people pick them as guards? Right. > Some questions on the terminology you used: > > a) What do you mean by 'last rotation period'? When you say "for > fraction k of the last rotation period", you mean that if the > authorities read consensuses for the past 12 months, and the relay R > was up as a guard for 6 months, then k would be 6/12 == 0.5? The "rotation period" is the average length of time between choosing guards. For example, with the current parameters (IIRC), clients discard a guard and choose a new one at a time uniformly chosen between 30 and 60 days. So the rotation period is 45 days = 45*24 hours = 1080 consensus votes, and essentially in each of those hours, 1/1080 of the clients choose a new guard. So the last rotation period's worth of status documents should be the only ones that matter for figuring out how heavily a node is used as a guard. For example, if a relay has had the guard flag for 15 days (=360 consensus documents) out of the last 45, then that relay has about k=360/1080 of the number of clients using it as a guard as it would have, if it had been a guard for the full 1080 hours. (N.B. I'm making an assumption that guard rotations will be uniformly distributed over the period. This should be safe in equilibrium, but might get kind of shaky when the period first increases to 9 months or whatever the final decision is) > b) By (weight with the guard flag) you mean the result of: > <consensus BW> * <consensus weight> ? > > Is that right, or did I misunderstand you? Yes. > Assuming the above terminology assumptions, I began trying to > understand your formula. First of all, I was wondering how you ended > up with it? Is this some standard form? I'm not very familiar with > these things. Well, the way the weights work is that they compute what fraction of guard bandwidth should be used for middle and exit traffic, assuming that the rest will be all used up by client-guard connections. That is, the weights are telling us to use (1-(<consensus middle weight> + <consensus exit weight>)) fraction of the guard's bandwidth for these connections. But if a relay has only fraction k of its "guard bandwidth" used up this way, then (1-k) of this bandwidth should go back into the pool for other positions. I think that's what the formula does, but I could have it wrong. Does that make sense? -- ------------------------------------------------------------------------ Nicholas Hopper Associate Professor, Computer Science & Engineering, University of Minnesota Visiting Research Director, The Tor Project ------------------------------------------------------------------------

1 0