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

Re: [tor-dev] Python Only Tor Client?
by Jacob Garber 21 Apr '14

21 Apr '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 4/21/14, Fabio Pietrosanti (naif) <lists(a)infosecurity.ch> wrote: > Hi all, > > does anyone know of any work to make a Python Only Tor Client, that just > enable to expose a Tor Hidden Service? > > It would be very cool if it would be possible to avoid "Tor binary" as a > dependency for Globaleaks, making it pure Python application code. > > The questions are: > > - Are there projects that foresee to do something like that? > > - From a Tor Project perspective, does it make sense? > > - From a Security perspective, are there strong security implications in > doing so? > I have been considering such a project, though my purpose for pursuing it would be to both learn Python and to come to a better understanding of the internals of Tor. Perhaps not the best circumstances for a solid implementation... For the time being my implementation is just going to be an experiment with trying to speak the Tor protocol, but assuming that I can get some of the basic building-blocks working I'll be pursuing a Tor rewrite in my spare time (I'm currently a student, and as such still sorting out my schedule). I'll probably be in and out of IRC and these mailing lists asking questions every now and again (and trying not to ask stupid ones). - - ajtgarber (0xEFDA75F9) A190 2527 2D58 6A2B 8108 CB66 D57A A16A EFDA 75F9 -----BEGIN PGP SIGNATURE----- Version: n/a iQIcBAEBAgAGBQJTVV/4AAoJEEyLqVBnwH7XGu0P/3e0ZI+y067si2PItq4xWsaq +NLIzEymUjoSEM8iaYkZVumcOofY+yD1vCEGIvUroCvymC0YWFH+FYw5jkiffjRX 6wmc/d25ARtT/wVP59Nrmi+P9ZpD1fMaNaQ68eS3rnIPbZHc/ONsemXnW3g/m49Q zPViKtXNu3/1pmix33yS2SSU8uJIPd9j7NWDV3lxZ9fOlFfv0TocgJgvYdx0gVJC QGXiK6dprGgXhEy4+pzxDroUbKynh0pwd6N5ZiwlCbhcSAeIps87zGPldnasb8cA ZHEcyG8Gvlsoat/kQAVI7EwLYS3HCXiqKnhmoB1hXllDG6pJpYK1FufwGYyvlUZM ds1s0OQymmuftgEFcAbuInBlbqKihwllspMGdoz6SjBj50+iYqG3K/XP5yhyiZBx fk6X4LhAPh+GCClSRPn7ZV6oPDqrc/T3yodcUfGoKAlZiFQkCkX/DZUITr59Sb1g Hy7CKBIUdrzvK0B4XLf9gdVpf/pZCy0CTUikZbnke2ctyEseKkQbiZGLYIC5+ueT VJTGYtlFxZtblz3dh+lfwEI5HAPQRaa/cR6yRJd4yxvIOGlFNNAyn4E4HXuI4K+L VoWaDoFQQButYMlx8LiYt228HGVQkfxPpwX5OWH8u2BJpRYqKblGWpGu2bvkgiyw ZpsBF6B/8v+FTLN0fMk6 =s4ji -----END PGP SIGNATURE-----

2 1

Potentially n00b question about Tor Cloud & Heartbleed
by Peter B 21 Apr '14

21 Apr '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 hi all, As I understand, there are two steps to mitigating the Heartbled bug for Tor bridges: 1. Upgrade OpenSSL 2. rm -rf /var/lib/tor/keys/* and restart the tor procses While the bridges on Tor Cloud (and therefore Access' Global Proxy Cloud) are configured to automatically fetch updates, there is no way to complete step 2 with SSH access, correct? If so, is there any plan to deal with instances that were set up with the vulnerable version of OpenSSL, but whoever set up the instance has not or cannot regenerate the keys. - -- Peter Bourgelais Circumvention and Network Interference Technologist Access | accessnow.org | rightscon.org PGP ID: 0x1C16F6D8 Fingerprint: EC9B 18C2 EBF4 07E0 37C6 E306 6592 DE70 1C16 F6D8 Github: https://github.com/pbourgel -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJTVUToAAoJEGWS3nAcFvbY15oP/31qpnsLAFZZiuvsQ19jwx6C 74drB1P8zdr8cpAvCVMpmEGRE1hDHTB4iyKQ4rttaAhJu5D5ukP+pGvL+bIL7bTC mzyww37gZE4Fh/ydyaUEQSPw6dBR0pMpKl61/DUKsvF2G/62gW8c5j/+ZXlvBYb8 5tX1ecfWF3LAuBDqrFK0EHtysZ8JfwjRz9aOBR/ZuGM9NKW2UN5iLljxsq7nKIIx YFDKEwPJKPV8t4AsaAxv1Z6ctFqAOSmFObj5Ku9Ifc8vgpSKx9yZpuAttpfaEwYT wf+PHvn1hZNzHb/UZ5ZaIBqP63w+xqTLUEmoDrO9qwSUsi2DhCPUCvKhQ7wzWsnZ 3U+GvmsV3c1JGHCroXii+B2hu04DI0fKxboyFdy+x19PvAMf4UAEIwAG+X0FO9dS pd1F8Zq5ohXItjdAm6ZxGtOL1Q9KHU29G9liYjj/N9NYq7iQLd59CNhoELHulYoO BYBUyTzVwASYIDPbcUZ63z23vCk+ymfX95JTj2J4LK0ZbmJWhe+23ZOIfXiF/v/t 5UBoSIPok336NmsNv7vGMV8O8PuqsEm6/Gv9CCETlUw+wzrSdlu3K0QhLjYagj0C Fl8uEiKzH1LzavdBsSMfDKCGQya4LbvWSnDM2DmHWra3hPG6xJMvnMPxCdqr73dv vGezCcQBb6limTdHW1xH =xqRh -----END PGP SIGNATURE-----

1 1

Starting Tor from Python using Ctypes improving Sandboxing?
by Fabio Pietrosanti (naif) 19 Apr '14

19 Apr '14

Hi, currently starting Tor from an python application using existing frameworks (such as txtorconn) provide limits related to the capabilities of sandboxing the application itself with AppArmor. If you want to start Tor from your own application, then you must enable such application to "execute" an external binary called /usr/bin/tor . I'm wondering if anyone ever tried to start Tor from a Python application using Ctypes, to start the Tor "main()", placing the Tor process into a dedicated Python's application Thread. That way it would be possible to sandbox the Python application using AppArmor without enabling any kind of execve() call. Does anyone ever tried this? -- Fabio Pietrosanti (naif) HERMES - Center for Transparency and Digital Human Rights http://logioshermes.org - http://globaleaks.org - http://tor2web.org

1 0

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