- tor-dev - lists.torproject.org

consensus-health.torproject.org
by Michael Wolf 19 Apr '14

19 Apr '14

I think I can make some improvements to the consensus-health page (mostly removing redundant formatting code in the HTML), but I can't seem to find the git repo for the project listed at https://gitweb.torproject.org/ Could someone point me in the right direction? I another pertinent question would be: is anyone using any scripts that scrape this page, which might be broken if things are changed? An example of a change could be: since the flags in the "Consensus" column seem to always be blue, remove all the <font color="blue"> tags, (and closing tags) in the consensus column, and replace them with one class per <td> in that column. I estimate that this change alone would save about 575KiB in the uncompressed HTML. That's about 10% of the document's uncompressed size, without even using any CSS3 trickery. -- Mike Wolf

2 1

Please try 3.5.4-meek-1 bundles (covert HTTPS pluggable transport)
by David Fifield 18 Apr '14

18 Apr '14

A while back I wrote about a pluggable transport called meek that routes your traffic through a third-party web service in a way that should be difficult to block. There are now experimental bundles featuring this transport, ready for somewhat wider testing. Please try: https://people.torproject.org/~dcf/pt-bundle/3.5.4-meek-1/ The files are signed with my key 0xC11F6276 from: https://www.torproject.org/docs/signing-keys https://www.bamsoftware.com/david/david.asc You don't have to do anything in the configuration. Just click "Connect". What you'll see, if you look at your network traffic, is a lot of HTTPS requests to www.google.com. (And no connections to any Tor bridge, nor anything speaking the Tor protocol.) Behind the scenes, Google is passing the requests on to our web app, which then forwards them to a Tor bridge. More on how the whole system works is at https://trac.torproject.org/projects/tor/wiki/doc/meek. Another thing to know is that starting the browser will run a second, headless instance of Firefox. The second browser is used as a tool for making HTTPS requests. It's the same Firefox binary used by Tor Browser (so it doesn't increase the size of the bundles), but it has a special configuration and an extension that allows it to access the network directly. When you're using meek, this browser extension is in fact the only thing that touches the network, but you never interact with it directly--it only takes orders from the client transport plugin. We do it this way so that the HTTPS requests look like they come from a browser, and are not fingerprintable as coming from some custom SSL program. The second browser should be completely invisible to you--except on OS X, where it creates a second dock icon (this is bug #11429). These bundles are experimental and you shouldn't use them to replace your main browser just yet. We're most interested in hearing about what didn't work for you or what was surprising. I'll write another post about code review and other things that need to happen before you'll see meek in a mainline bundle. David Fifield

1 1

[Flashproxy] Some sites filtering users?
by Griffin Boyce 18 Apr '14

18 Apr '14

Hey all, Got a report from a friend* who noticed that twitch.tv stops letting him watch broadcasts while flashproxy is in an active state. He uses Cupcake, which shows flashproxy's status in the icon bar, and he only has an issue when the cupcake icon has a mustache. Has anyone noticed similar behavior when using flashproxy? ~Griffin * who is a hacker

1 0

Combining obfsproxy+scramblesuit with OpenVPN
by irregulator＠riseup.net 17 Apr '14

17 Apr '14

Hello people, I'm investigating how may we combine the traffic obfuscation provided by obfsproxy+scramblesuit with OpenVPN instead of Tor. I completely understand how this combination does not provide anonymity, but nevertheless I think it will be of some use. In the recent past there have been some interest in this combination [1], [2], [3], mainly cause of VPN traffic blocking in various countries or networks. OpenVPN supports only Socks5 proxy but current obsfproxy's version doesn't have a Socks5 listener, see ticket #9221 [4]. Luckily yawning provided a patch some days ago [5], and I decided to test it. According to patch's comments, it implements a Socks5 proxy with authentication as in RFC 1928/RFC 1929. This authentication is gonna serve as a means to pass parameters to the pluggable transport, please correct me on this one. Firstly, does this patch and generally obfsproxy development takes in consideration other clients except for Tor, e.g. OpenVPN or OpenSSH ? I think it would be very nice to have a way to combine OpenVPN with Scramblesuit as stated in the latter's paper. But then I'll understand if that's not a priority for obfsproxy's developers. So, while testing OpenVPN with obfsproxy and the latest patch, the vpn client enters the authentication phase. Do the credentials depend on the pluggable transport in use by the obfsproxy? If so, what credentials should the vpn or the ssh socks client provide when talking with scramblesuit? Will vpn client have to provide the session ticket or other pre-shared secret through socks authentication? Thanks in advance for any answers. Alex [1] http://community.openvpn.net/openvpn/wiki/TrafficObfuscation [2] http://www.dlshad.net/?p=135 [3] https://www.void.gr/kargig/blog/2012/10/05/bypassing-censorship-devices-by-… [4] https://trac.torproject.org/projects/tor/ticket/9221 [5] https://trac.torproject.org/projects/tor/attachment/ticket/9221/0001-Use-SO…

7 12

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