- tor-dev - lists.torproject.org

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

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

Some fun build farm docs
by MSvB 07 Apr '14

07 Apr '14

Hi folks, Actually it was suggested that I introduce myself since I'm just getting started so here it is. Since I want to improve third party cookie logic (increase granularity & improve intuitive UI) and remove nasty clipboard temp files left around, I'm starting by getting to know the TBB build process. ...and compiling documentation of irregularities as well as requirements. The requirements will eventually help improve gitian/check-prerequisites.sh in order to automate and avoid long builds ending in failure. That's all to say for now. If you come across a build problem that you think new developers might come across, please add a a comment to ticket #11420 [1]. [1] https://trac.torproject.org/projects/tor/ticket/11420/ Cheers, Michael -- Michael Schloh von Bennewitz Software Development Engineer Europalab Networks R&D, Munich Office: +49(89)44239885 UTC+1 Mobile: Same as 'Office' VoIP: sips:michael@schloh.com Web: http://michael.schloh.com/

1 0

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

07 Apr '14

I think I'll have more to say later, but... On Wed, Mar 26, 2014 at 11:36 AM, George Kadianakis <desnacked(a)riseup.net> wrote: > 1.3. Age of guard as a factor on guard probabilities > > By increasing the guard rotation period we also increase the lack > of clients for young guards since clients will rotate guards even > more infrequently now (see 'Phase three' of [1]). > > We can try to mitigate this phenomenon by giving higher priority to > young guards to be picked as guards: > > To do so, everytime an authority needs to vote for a guard, it > reads a set of consensus documents spanning the past NNN months, and > calculates the age of the guard; that is, in how many consensuses > its public key has been included in the past. > > The authorities include the age of each guard by appending > '[SP "Age=" INT]' in the guard's "w" line. > > When a client picks a guard, it applies the age of each guard as a > weight on its guard probability. XXX unspecified how I'm pretty sure this section has it backwards from what was the intent of the discussion of "guard age" at the dev meeting. The weight factor should be applied when choosing a "new guard" as a middle or exit node, because it is being underutilized as a guard. This makes it straightforward to apply: if relay R has had the guard flag for fraction k of the last rotation period, then its weight for some other position should be k*(weight with the guard flag) + (1-k)*(weight without the guard flag) -- ------------------------------------------------------------------------ Nicholas Hopper Associate Professor, Computer Science & Engineering, University of Minnesota Visiting Research Director, The Tor Project ------------------------------------------------------------------------

3 2

Re: [tor-dev] Stegotorus Challenge - Inheriting from FileStegMod
by vmon＠riseup.net 07 Apr '14

07 Apr '14

Hey Noah, Thanks a lot for the patch. You are doing a great job. I commited your changes here: https://github.com/zackw/stegotorus/commit/a92f977259dd3aaabe9f5812f79bbe73… Please pull the branch f--file-stegize-swf-js-pdf and continue work there. Few comments: 1. Our main point is two get rid of redundant http_handle_client_SWF_receive, http_server_SWF_transmit (you undid deleting them). When you finish moving all modules the following "switch" in http_steg_t::http_client_receive (and in http_steg_t::transmit) will be discarded/disappear: switch(type) { case HTTP_CONTENT_SWF: rval = http_handle_client_SWF_receive(this, conn, dest, source); break; case HTTP_CONTENT_JAVASCRIPT: case HTTP_CONTENT_HTML: rval = http_handle_client_JS_receive(this, conn, dest, source); break; case HTTP_CONTENT_PDF: rval = http_handle_client_PDF_receive(this, conn, dest, source); break; default: log_debug(conn, "receiving a payload of type %i", type); rval = config->file_steg_mods[type]->http_client_receive(conn, dest, source); break; } and we will only need this line (the default case): log_debug(conn, "receiving a payload of type %i", type); rval = config->file_steg_mods[type]->http_client_receive(conn, dest, source); But for now, for any type that you move to FileStegMod structure, you just need to drop the case from this switch, because in new structure it will be taken care of in the default case, (so you don't get those src/steg/http.cc:697:67: error: 'http_handle_client_SWF_receive' was not declared in this scope errors you mentioned). 2. In http.cc, add a line to http_steg_config_t::init_file_steg_mods() to create the SWFSteg: void http_steg_config_t::init_file_steg_mods() { // we can't call this in constructor cause //it should be called after the payload server is initialized //initiating the steg modules //TODO: for now the first modules are set to void till their codes be //transformed into a FileStegMod child file_steg_mods[HTTP_CONTENT_JPEG] = new JPGSteg(payload_server, noise2signal); file_steg_mods[HTTP_CONTENT_PNG] = new PNGSteg(payload_server, noise2signal); file_steg_mods[HTTP_CONTENT_GIF] = new GIFSteg(payload_server, noise2signal); } 3. compare how PayloadScraper::PayloadScraper defines old modules and new modules, and modify for SWFSteg accordingly: _available_file_stegs[HTTP_CONTENT_SWF] = NULL; _available_stegs[2].type = HTTP_CONTENT_SWF; _available_stegs[2].extension = ".swf"; _available_stegs[2].capacity_function = PayloadServer::capacitySWF; vs. _available_file_stegs[HTTP_CONTENT_JPEG] = new JPGSteg(NULL); //We are only using the capacity function so we don't need a payload server _available_stegs[5].type = HTTP_CONTENT_JPEG; _available_stegs[5].extension = ".jpg"; _available_stegs[5].capacity_function = JPGSteg::static_capacity; //Temp measure, later we don't need to do such acrobat Also please look at my comment on the proposal. Bon courage, vmon Noah Rahman <selimthegrim(a)gmail.com> writes: > result of running git format-patch origin/tor-improve --stdout > swfsteg.patch > > On 4/6/14, Noah Rahman <selimthegrim(a)gmail.com> wrote: >> Success! Sending you the patch shortly... >> >> On 4/6/14, Noah Rahman <selimthegrim(a)gmail.com> wrote: >>> attaching new steg files for purely informational purposes, these are >>> the only ones I have modified - my guess is capacitySWF in payload >>> server should remain a stub? It seems like we would want to take the >>> capacity functions out of payload server... >>> >>> >>> >>> On 4/6/14, Noah Rahman <selimthegrim(a)gmail.com> wrote: >>>> Here's my current holdup, I don't think I changed these functions but >>>> will shelve what I have, restore, and do a diff. >>>> >>>> selimthegrim@Rimsky-Korsakoffee:~/stegotorus$ make >>>> make all-am >>>> make[1]: Entering directory `/home/selimthegrim/stegotorus' >>>> depbase=`echo src/steg/http.o | sed 's|[^/]*$|.deps/&|;s|\.o$||'`;\ >>>> g++ -I. -I./src -I./src/steg -I./src/steg/http_steg_mods >>>> -I./src/test/gtest -I./src/test/gtest/include -Wall -Wextra >>>> -Wno-missing-field-initializers -Wformat=2 -std=c++0x -g2 -O0 >>>> -std=gnu++11 -MT src/steg/http.o -MD -MP -MF $depbase.Tpo -c -o >>>> src/steg/http.o src/steg/http.cc &&\ >>>> mv -f $depbase.Tpo $depbase.Po >>>> src/steg/http.cc: In member function 'virtual int >>>> http_steg_t::transmit(evbuffer*)': >>>> src/steg/http.cc:562:75: error: 'http_server_SWF_transmit' was not >>>> declared in this scope >>>> rval = http_server_SWF_transmit(config->payload_server, source, >>>> conn); >>>> >>>> ^ >>>> src/steg/http.cc: In member function 'virtual int >>>> http_steg_t::http_client_receive(evbuffer*, evbuffer*)': >>>> src/steg/http.cc:697:67: error: 'http_handle_client_SWF_receive' was >>>> not declared in this scope >>>> rval = http_handle_client_SWF_receive(this, conn, dest, source); >>>> ^ >>>> make[1]: *** [src/steg/http.o] Error 1 >>>> make[1]: Leaving directory `/home/selimthegrim/stegotorus' >>>> make: *** [all] Error 2 >>>> >>>> >>>> On 4/6/14, Noah Rahman <selimthegrim(a)gmail.com> wrote: >>>>> Ok will use c_HTTP and restore the free block. I did read that text >>>>> file >>>>> and have made appropriate changes >>>>> On Apr 6, 2014 10:49 PM, <vmon(a)riseup.net> wrote: >>>>> >>>>>> Hey Noah, >>>>>> >>>>>> > size_t tmp_len = cover_len * 32; //assert here to prevent overflow >>>>>> This is probably prevented somewhere else, but it is always good to >>>>>> harden the code. >>>>>> >>>>>> > /*if (inf_len < 0 || >>>>>> > out_sz < inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN) >>>>>> > { >>>>>> > fprintf(stderr, "inf_len = %d\n", inf_len); >>>>>> > free(tmp_buf); >>>>>> > return -1; >>>>>> > }*/ >>>>>> Why did you get rid of this part? >>>>>> >>>>>> >//how to check max SWF size? c_HTTP_MSG_BUF_SIZE? >>>>>> Sure, there is a confusion between HTTP_MSG_BUF_SIZE and >>>>>> c_HTTP_MSG_BUF_SIZE but we should unite them and use one (the latter >>>>>> is >>>>>> better). >>>>>> >>>>>> > tmp_len= inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN; >>>>>> > //reassigned to existing variable >>>>>> > return (ssize_t)tmp_len; //added for new return type >>>>>> sure, you can do >>>>>> >>>>>> return (ssize_t)(inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN); >>>>>> >>>>>> But it isn't a big deal. >>>>>> >>>>>> Also please take a look at: >>>>>> >>>>>> >>>>>> doc/writing_new_file_steg_mod_for_http_steg.txt >>>>>> >>>>>> Best of luck, >>>>>> vmon >>>>>> >>>>>> Noah Rahman <selimthegrim(a)gmail.com> writes: >>>>>> >>>>>> > Have finished everything I think I need, trying now to compile a >>>>>> > patch >>>>>> > for SWF. Will start on JS once that is socked away. A few questions >>>>>> > though... (on tmp_len line, and commented out free block) >>>>>> > >>>>>> > ssize_t >>>>>> > SWFSteg::decode(const uint8_t *cover_payload, size_t cover_len, >>>>>> > uint8_t* >>>>>> data) >>>>>> > { >>>>>> > int inf_len; >>>>>> > size_t tmp_len = cover_len * 32; //assert here to prevent overflow >>>>>> > for large covers? >>>>>> > char* tmp_buf = (char *)xmalloc(tmp_len); >>>>>> > >>>>>> > for (;;) { >>>>>> > inf_len = decompress(cover_payload + 8, cover_len - 8, >>>>>> > (uint8_t *)tmp_buf, tmp_len); >>>>>> > if (inf_len != -2) >>>>>> > break; >>>>>> > tmp_len *= 2; >>>>>> > tmp_buf = (char *)xrealloc(tmp_buf, tmp_len); >>>>>> > } >>>>>> > >>>>>> > /*if (inf_len < 0 || >>>>>> > out_sz < inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN) >>>>>> > { >>>>>> > fprintf(stderr, "inf_len = %d\n", inf_len); >>>>>> > free(tmp_buf); >>>>>> > return -1; >>>>>> > }*/ //how to check max SWF size? c_HTTP_MSG_BUF_SIZE? >>>>>> > >>>>>> > memcpy(data, tmp_buf + SWF_SAVE_HEADER_LEN, >>>>>> > inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN); >>>>>> > tmp_len= inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN; >>>>>> > //reassigned to existing variable >>>>>> > return (ssize_t)tmp_len; //added for new return type >>>>>> > } >>>>>> > >>>>>> > On 4/5/14, vmon <vmon(a)riseup.net> wrote: >>>>>> >> >>>>>> >> >>>>>> >> Just make a patch of you changes and email me the patch: >>>>>> >> >>>>>> >> http://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git/ >>>>>> >> Envoyé depuis un mobile Samsung >>>>>> >> >>>>>> >> -------- Message d'origine -------- >>>>>> >> De : Noah Rahman <selimthegrim(a)gmail.com> >>>>>> >> Date :2014/04/05 19:11 (GMT-05:00) >>>>>> >> À : vmon(a)riseup.net >>>>>> >> Objet : Re: Stegotorus Challenge - Inheriting from FileStegMod >>>>>> >> >>>>>> >> Ok. I'll shoot for SWF and Js by turn and add that to a revised >>>>>> >> proposal for >>>>>> >> the challenge period. I have not heard back from Zack yet. I am in >>>>>> >> UTC+5 now >>>>>> >> so that leaves me all of my Sunday at least? >>>>>> >> >>>>>> >> On Apr 5, 2014 11:02 PM, <vmon(a)riseup.net> wrote: >>>>>> >> Hey Noah, >>>>>> >> >>>>>> >> Just keep in mind that I need to make a recommendation on your >>>>>> >> application by the end of the weekend. >>>>>> >> >>>>>> >> I also like very much if you can add "merging SRI branch of >>>>>> >> Stegotorus" >>>>>> >> to our Stegotorus as well, to the list of the deliverables of the >>>>>> >> proposal. >>>>>> >> >>>>>> >> Thanks, >>>>>> >> vmon >>>>>> >> >>>>>> >> Noah Rahman <selimthegrim(a)gmail.com> writes: >>>>>> >>> Yes, the capacities were a bit of a head scratcher. I'll try swf >>>>>> >>> first >>>>>> >>> and then js. My github ID is baronwolfenstein. >>>>>> >>> >>>>>> >>> Hey Noah, >>>>>> >>> >>>>>> >>> For committing: >>>>>> >>> I think Zack needs to give you write access. Please send your >>>>>> >>> github >>>>>> >>> id >>>>>> >>> to Zack (zackw(a)cmu.edu) and cc me. Once that is done, please >>>>>> >>> branch >>>>>> >>> out >>>>>> >>> of tor-improve and commit. If it takes Zack long to give you >>>>>> >>> permission, >>>>>> >>> you can just fork Zackw/stegotorus of course. Just please only >>>>>> >>> commit >>>>>> >>> compilable code (no syntax error etc), this way it is easier to >>>>>> >>> review >>>>>> >>> the commits. >>>>>> >>> >>>>>> >>> SWF would be easier than JS but if you like the JS it is cool with >>>>>> >>> me. For the swf, basically swf_wrap should go to encode, >>>>>> >>> swf_unwrap >>>>>> >>> to >>>>>> >>> decode and you need basically discard the http_server_SWF_transmit >>>>>> >>> and >>>>>> >>> http_handle_client_SWF_receive functions (these are >>>>>> >>> redundant). Just >>>>>> >>> be >>>>>> >>> careful that what is supposed to be send to each function, is it >>>>>> >>> the >>>>>> >>> payload without header? with header? etc. So just tweak the >>>>>> >>> swf_unwrap/swf_wrap to be compatible with what encode/decode. >>>>>> >>> >>>>>> >>> Capacity functions: >>>>>> >>> Then PayloadServer::capacitySWF should be implemented as >>>>>> >>> swfSteg::capacity. >>>>>> >>> However, You'll find 4 capacity functions and it is probably quite >>>>>> >>> confusing. >>>>>> >>> >>>>>> >>> capacity >>>>>> >>> headless_capacity >>>>>> >>> static_capacity >>>>>> >>> static_headless_capacity >>>>>> >>> >>>>>> >>> static vs virtual: >>>>>> >>> When all the modules are moved to the new model, we'll get rid of >>>>>> >>> static_capacity, static_headless_capacity but till then, we need >>>>>> >>> them >>>>>> >>> to >>>>>> >>> keep this old/new hybrid stegs model. Hence: >>>>>> >>> >>>>>> >>> capacity just calls static_capacity >>>>>> >>> headless_capacity just calls static_headless_capacity >>>>>> >>> >>>>>> >>> headless vs headfull: >>>>>> >>> headless_capcity: computes the capacity when the payload is given >>>>>> >>> without >>>>>> >>> http header (pure file). >>>>>> >>> >>>>>> >>> capacity: compute the capacity when the payload is given as an >>>>>> >>> HTTP >>>>>> >>> response (So it starts with >>>>>> >>> >>>>>> >>> HTTP/1.1 200 OK Server: Apache >>>>>> >>> Accept-Ranges: bytes >>>>>> >>> Content-Type: text/html; charset=utf-8 >>>>>> >>> Content-Length: 920 >>>>>> >>> Connection: keep-alive >>>>>> >>> >>>>>> >>> and then the file starts, so you just need basically to skip the >>>>>> >>> header >>>>>> >>> and call headless_capacity (we probably should implement the >>>>>> >>> capacity >>>>>> >>> in >>>>>> >>> the parent and only make headless_capacity pure virtual). >>>>>> >>> >>>>>> >>> If you take look at: >>>>>> >>> >>>>>> >>> jpgSteg::capacity >>>>>> >>> jpgSteg::headless_capacity >>>>>> >>> jpgSteg::static_capacity >>>>>> >>> jpgSteg::static_headless_capacity >>>>>> >>> >>>>>> >>> all I what say will sound less gibberish to you. >>>>>> >>> >>>>>> >>> Good luck et bon courage, >>>>>> >>> vmon >>>>>> >>> >>>>>> >>> Noah Rahman <selimthegrim(a)gmail.com> writes: >>>>>> >>> >>>>>> >>>> Laying over in Tokyo enroute to bkk, had a look at all the >>>>>> >>>> modules >>>>>> >>> and >>>>>> >>>> will start on the JS one on the plane. I have 24 hours in bkk so >>>>>> >>>> should be able to convert the Js and at least one of the other >>>>>> >>>> ones >>>>>> >>> if >>>>>> >>>> not both to inherit from the FileStegMod by the time I leave >>>>>> >>>> there. >>>>>> >>>> Should I submit the pr to your Tor-improve branch or zackw's? >>>>>> >>>> >>>>>> >> >>>>>> >>>>> >>>> >>> >>

1 0

Re: [tor-dev] Stegotorus Challenge - Inheriting from FileStegMod
by vmon＠riseup.net 06 Apr '14

06 Apr '14

Hey Noah, > size_t tmp_len = cover_len * 32; //assert here to prevent overflow This is probably prevented somewhere else, but it is always good to harden the code. > /*if (inf_len < 0 || > out_sz < inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN) { > fprintf(stderr, "inf_len = %d\n", inf_len); > free(tmp_buf); > return -1; > }*/ Why did you get rid of this part? >//how to check max SWF size? c_HTTP_MSG_BUF_SIZE? Sure, there is a confusion between HTTP_MSG_BUF_SIZE and c_HTTP_MSG_BUF_SIZE but we should unite them and use one (the latter is better). > tmp_len= inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN; > //reassigned to existing variable > return (ssize_t)tmp_len; //added for new return type sure, you can do return (ssize_t)(inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN); But it isn't a big deal. Also please take a look at: doc/writing_new_file_steg_mod_for_http_steg.txt Best of luck, vmon Noah Rahman <selimthegrim(a)gmail.com> writes: > Have finished everything I think I need, trying now to compile a patch > for SWF. Will start on JS once that is socked away. A few questions > though... (on tmp_len line, and commented out free block) > > ssize_t > SWFSteg::decode(const uint8_t *cover_payload, size_t cover_len, uint8_t* data) > { > int inf_len; > size_t tmp_len = cover_len * 32; //assert here to prevent overflow > for large covers? > char* tmp_buf = (char *)xmalloc(tmp_len); > > for (;;) { > inf_len = decompress(cover_payload + 8, cover_len - 8, > (uint8_t *)tmp_buf, tmp_len); > if (inf_len != -2) > break; > tmp_len *= 2; > tmp_buf = (char *)xrealloc(tmp_buf, tmp_len); > } > > /*if (inf_len < 0 || > out_sz < inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN) { > fprintf(stderr, "inf_len = %d\n", inf_len); > free(tmp_buf); > return -1; > }*/ //how to check max SWF size? c_HTTP_MSG_BUF_SIZE? > > memcpy(data, tmp_buf + SWF_SAVE_HEADER_LEN, > inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN); > tmp_len= inf_len - SWF_SAVE_HEADER_LEN - SWF_SAVE_FOOTER_LEN; > //reassigned to existing variable > return (ssize_t)tmp_len; //added for new return type > } > > On 4/5/14, vmon <vmon(a)riseup.net> wrote: >> >> >> Just make a patch of you changes and email me the patch: >> >> http://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git/ >> Envoyé depuis un mobile Samsung >> >> -------- Message d'origine -------- >> De : Noah Rahman <selimthegrim(a)gmail.com> >> Date :2014/04/05 19:11 (GMT-05:00) >> À : vmon(a)riseup.net >> Objet : Re: Stegotorus Challenge - Inheriting from FileStegMod >> >> Ok. I'll shoot for SWF and Js by turn and add that to a revised >> proposal for >> the challenge period. I have not heard back from Zack yet. I am in >> UTC+5 now >> so that leaves me all of my Sunday at least? >> >> On Apr 5, 2014 11:02 PM, <vmon(a)riseup.net> wrote: >> Hey Noah, >> >> Just keep in mind that I need to make a recommendation on your >> application by the end of the weekend. >> >> I also like very much if you can add "merging SRI branch of >> Stegotorus" >> to our Stegotorus as well, to the list of the deliverables of the >> proposal. >> >> Thanks, >> vmon >> >> Noah Rahman <selimthegrim(a)gmail.com> writes: >>> Yes, the capacities were a bit of a head scratcher. I'll try swf >>> first >>> and then js. My github ID is baronwolfenstein. >>> >>> Hey Noah, >>> >>> For committing: >>> I think Zack needs to give you write access. Please send your >>> github >>> id >>> to Zack (zackw(a)cmu.edu) and cc me. Once that is done, please branch >>> out >>> of tor-improve and commit. If it takes Zack long to give you >>> permission, >>> you can just fork Zackw/stegotorus of course. Just please only >>> commit >>> compilable code (no syntax error etc), this way it is easier to >>> review >>> the commits. >>> >>> SWF would be easier than JS but if you like the JS it is cool with >>> me. For the swf, basically swf_wrap should go to encode, swf_unwrap >>> to >>> decode and you need basically discard the http_server_SWF_transmit >>> and >>> http_handle_client_SWF_receive functions (these are >>> redundant). Just >>> be >>> careful that what is supposed to be send to each function, is it >>> the >>> payload without header? with header? etc. So just tweak the >>> swf_unwrap/swf_wrap to be compatible with what encode/decode. >>> >>> Capacity functions: >>> Then PayloadServer::capacitySWF should be implemented as >>> swfSteg::capacity. >>> However, You'll find 4 capacity functions and it is probably quite >>> confusing. >>> >>> capacity >>> headless_capacity >>> static_capacity >>> static_headless_capacity >>> >>> static vs virtual: >>> When all the modules are moved to the new model, we'll get rid of >>> static_capacity, static_headless_capacity but till then, we need >>> them >>> to >>> keep this old/new hybrid stegs model. Hence: >>> >>> capacity just calls static_capacity >>> headless_capacity just calls static_headless_capacity >>> >>> headless vs headfull: >>> headless_capcity: computes the capacity when the payload is given >>> without >>> http header (pure file). >>> >>> capacity: compute the capacity when the payload is given as an HTTP >>> response (So it starts with >>> >>> HTTP/1.1 200 OK Server: Apache >>> Accept-Ranges: bytes >>> Content-Type: text/html; charset=utf-8 >>> Content-Length: 920 >>> Connection: keep-alive >>> >>> and then the file starts, so you just need basically to skip the >>> header >>> and call headless_capacity (we probably should implement the >>> capacity >>> in >>> the parent and only make headless_capacity pure virtual). >>> >>> If you take look at: >>> >>> jpgSteg::capacity >>> jpgSteg::headless_capacity >>> jpgSteg::static_capacity >>> jpgSteg::static_headless_capacity >>> >>> all I what say will sound less gibberish to you. >>> >>> Good luck et bon courage, >>> vmon >>> >>> Noah Rahman <selimthegrim(a)gmail.com> writes: >>> >>>> Laying over in Tokyo enroute to bkk, had a look at all the modules >>> and >>>> will start on the JS one on the plane. I have 24 hours in bkk so >>>> should be able to convert the Js and at least one of the other >>>> ones >>> if >>>> not both to inherit from the FileStegMod by the time I leave >>>> there. >>>> Should I submit the pr to your Tor-improve branch or zackw's? >>>> >>

1 0

GSoC Proposal: Relay Web Status Dashboard
by Bang Hui Lim 05 Apr '14

05 Apr '14

Hi Damian, Thank you for your feedback and suggestions!! I have revised my proposal and uploaded it to melange. Cheers Bang

3 7

[RELEASE] Torsocks 2.0.0-rc7
by David Goulet 05 Apr '14

05 Apr '14

Hi everyone! This is the release candidate 7 for torsocks 2.x. Nothing major, fixes and some code refactoring went in. From this point on, the upstream torsocks git[1] is now updated with that new code in the master branch but no stable release yet. With that, my github repository will become a mirror for a while but I will close the issue tracker after I move all the issues to the tpo trac. I will update the list next week on the current status of torsocks and what's next about this project. Here is the change log for this version. 2014-04-04 torsocks 2.0.0-rc7 * Fix: fix NULL dereference on error * Fix: memory leak in connect error path * Delete old source directory * Fix: nullify constant that might be undefined * Refactor the connect() code flow for clarity * Tests: add connect() test * Tests: add socket() test * Fix: socketpair() denied for INET[6] socket * Fix: socket() type check SOCK_STREAM * Fix: add autogen.sh to installation procedures * Fix: change TSOCKS_LOOPBACK bitness * Fix: support kfreebsd for mmap() Again, as usual, and forever! *please* code review, test and most importantly report any issues. Contribution ftw! :) Thanks to everyone! Git: https://github.com/dgoulet/torsocks.git (mirror: https://gitweb.torproject.org/user/dgoulet/torsocks.git) Github tarball: https://github.com/dgoulet/torsocks/archive/v2.0.0-rc7.tar.gz TPO Tarball: https://people.torproject.org/~dgoulet/torsocks/torsocks-2.0.0-rc7.tar.bz2 (sig: https://people.torproject.org/~dgoulet/torsocks/torsocks-2.0.0-rc7.tar.bz2.…) Cheers! David [1] https://gitweb.torproject.org/torsocks.git

2 1

jtorctl
by Michael Rogers 04 Apr '14

04 Apr '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I have a patch to improve thread safety in jtorctl. How should I submit it? Cheers, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEcBAEBCAAGBQJTPT1vAAoJEBEET9GfxSfM0CMH+wais6E2jteMA0EnrAsV9+K1 jx08ypBNtE7qTYehe3m4s6vFwEGmw6lu2qYqi8XwPlD6PY/x1OtnDWjrTUsMfyWe OMZF2kqtMcpk47Y+SAL2c8P/BGYk88Wb2UMTZEGo3AjBZS2wQyHD+FMaSoDP02R9 MvCfwON+sn4a+AJxrnX/NsrI5FivJWR8obWX2sYpfCQaNIub/G/SGh9DtMbJFEjD tLc+MHyrrmmEmM1LN8kQp6QdBP7xIn/Cv+St3vzG920UuvQD5ZmHCYqiD3ddp74f vqfuKZs8GvnDFnND9mfy16l9lUu8dME1GWnoAO0l4jRmhBKwUCZMnjaLZvBVZiE= =6inv -----END PGP SIGNATURE-----

4 7

Re: [tor-dev] Stegotorus Challenge - Inheriting from FileStegMod
by vmon＠riseup.net 04 Apr '14

04 Apr '14

Hey Noah, For committing: I think Zack needs to give you write access. Please send your github id to Zack (zackw(a)cmu.edu) and cc me. Once that is done, please branch out of tor-improve and commit. If it takes Zack long to give you permission, you can just fork Zackw/stegotorus of course. Just please only commit compilable code (no syntax error etc), this way it is easier to review the commits. SWF would be easier than JS but if you like the JS it is cool with me. For the swf, basically swf_wrap should go to encode, swf_unwrap to decode and you need basically discard the http_server_SWF_transmit and http_handle_client_SWF_receive functions (these are redundant). Just be careful that what is supposed to be send to each function, is it the payload without header? with header? etc. So just tweak the swf_unwrap/swf_wrap to be compatible with what encode/decode. Capacity functions: Then PayloadServer::capacitySWF should be implemented as swfSteg::capacity. However, You'll find 4 capacity functions and it is probably quite confusing. capacity headless_capacity static_capacity static_headless_capacity static vs virtual: When all the modules are moved to the new model, we'll get rid of static_capacity, static_headless_capacity but till then, we need them to keep this old/new hybrid stegs model. Hence: capacity just calls static_capacity headless_capacity just calls static_headless_capacity headless vs headfull: headless_capcity: computes the capacity when the payload is given without http header (pure file). capacity: compute the capacity when the payload is given as an HTTP response (So it starts with HTTP/1.1 200 OK Server: Apache Accept-Ranges: bytes Content-Type: text/html; charset=utf-8 Content-Length: 920 Connection: keep-alive and then the file starts, so you just need basically to skip the header and call headless_capacity (we probably should implement the capacity in the parent and only make headless_capacity pure virtual). If you take look at: jpgSteg::capacity jpgSteg::headless_capacity jpgSteg::static_capacity jpgSteg::static_headless_capacity all I what say will sound less gibberish to you. Good luck et bon courage, vmon Noah Rahman <selimthegrim(a)gmail.com> writes: > Laying over in Tokyo enroute to bkk, had a look at all the modules and > will start on the JS one on the plane. I have 24 hours in bkk so > should be able to convert the Js and at least one of the other ones if > not both to inherit from the FileStegMod by the time I leave there. > Should I submit the pr to your Tor-improve branch or zackw's? >

1 0

Re: [tor-dev] Moving ownership to TheTorProject
by Zack Weinberg 04 Apr '14

04 Apr '14

On 02/20/2014 10:48 AM, vmonmoonshine(a)gmail.com wrote: > Hey Zack, > > I want to put up Stegotorus up for GSoC this summer. I was wondering if > you mind transfering the ownership of your Stegotorus repo: > > https://github.com/zackw/stegotorus > > To "TheTorProject" on github: > > https://github.com/TheTorProject > > ? (https://github.com/zackw/stegotorus/settings then Transfer) > > If you don't feel comfortable, we can fork it as well. [ Background for tor-dev: I am no longer involved in Stegotorus development. vmon and at least one other person are continuing to work on it; this is currently happening in non-default branches of the copy on my github account. There is also a copy of the repo on gitweb.torproject.org but it has not been updated in quite some time. ] I discussed this with Roger on IRC yesterday and we came to the conclusion that instead of transferring my Stegotorus repo to the "TheTorProject" organizational account, gitweb.torproject.org/stegotorus.git should be promoted to the master copy. I think right now I am the only person with write access to that copy, and I am not sure what the right procedure is for granting you access. I'm also not good enough at Git to know how to copy all branches of remote A into remote B (short of tedious manual actions and/or shell loops). I think this would also entail using Tor's Trac for issues instead of Github's issue tracker. zw

5 5

Prototype of a next-generation Tor control interface
by ra 04 Apr '14

04 Apr '14

Hi, all! Originally, I wrote the proposal for this year's GSoC, but nobody seems willing to mentor it and the idea most probably needs more time to shape. Hence, I post it on this list to get some feedback and let the idea evolve. (: Best, Robert Problem statement Tor's control protocol[0] facilitated the communication from other programs with a locally running Tor process, regardless of their programming language. It is used by various projects like GUI controllers, such as Vidalia or arm, research projects, or services for monitoring the Tor network, such as bandwidth scanners. The Tor control protocol is a message-based protocol which requires lots of message/string parsing when using it. Hence, to ease the use of that interface, libraries such as JTorCtl, TorCtl, Txtorcon, and Stem were developed. Today, some of those libraries can be considered outdated, such as JTorCtl and TorCtl - even though TorCtl is still in use. Stem and Txtorcon are state-of-the-art and heavily being used, provide thread safety, caching and a better interface, rendering string parsing unnecessary. However, both are Python libraries, restricting the use of the Tor control protocol to Python scripts only. While Python is a fine and very popular scripting language, actual restriction to use a specific programming language, prevents wider use of the Tor control interface. Proposal Therefore, I would like to propose a prototype of a next-generation Tor control interface, aiming to combine the strengths of both the present control protocol and the state-of-the-art libraries. It should provide (network) connectivity from other programs to a locally running Tor process, regardless of the programming language, while preserving thread safety, caching and a better interface. Before implementing in Tor itself, coding a prototype is substantially less work. The prototype should consist of a daemon running on the same machine as the Tor instance. The daemon implements a backend interface to the Tor instance through the Tor control protocol (via Stem) and a frontend interface providing JSON encoded data over HTTP (REST). Therefore, semi-structured data (JSON) can be accessed by any (HTTP-capable) programming/scripting language. HTTP compression and/or encryption can be implemented, too. Not having looked into Python REST frameworks yet in detail, Flask looks promising for this task. Until the new interface is implemented in Tor itself, it will require continual upkeep and maintenance. Therefore, as a long term goal, the new interface should be implemented in Tor itself, if the prototype proofs to be successful. [0] https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=control- spec.txt

1 1