- tor-dev - lists.torproject.org

[GSoc] [Stegotorus] Progress report
by vmon 16 Jul '12

16 Jul '12

Hello everybody, Quick update on the progress of apache payload class for stegotorus: - https://github.com/vmon/payload_scraper/ is working now, checking apache document root dir, find all files usable as payload, compute their capacity and store them in a database. For now, I'm using the database in Stegotorus, but later the whole code is going to be part of Stegotorus and Stegotorus runs it periodically to keep the database updated. - I've written the basic functionality of apache_payload_server class, i.e. get_payload function (and anything else it needs to work). In theory, we should be able to call apache_payload_server::get_payload instead of get_payload, and Stegotorus would request the payload from apache (or as a matter of fact, any http server running on localhost). In practice, it still has compiling error which I'm working on and I expect them to be solved today. - I'm meeting Zack tomorrow to move my codes to his repo, so we have a unified repo from now on. Hopefully, I'll push the apache_payload_server on the new repo. - Afterward, I'm going to incorporate the infranet code http://nms.csail.mit.edu/infranet/ into the apache_payload_server to improve the quality of the steg. That is for now. Cheers, vmon

1 0

[GSoC] Stem stuff - Progress report
by Ravi Chandra Padmala 15 Jul '12

15 Jul '12

Hello. During the last week Damian merged my patches that implement loadconf & saveconf wrapper methods[1][2] in Stem. I am currently working on implementing the router descriptors (from the network status documents). I should have something ready for review by tuesday. Once that is done, I'll work on implementing the microdescriptor parser. I will also be getting my remaining controller class patches merged in parallel. 1. https://gitweb.torproject.org/stem.git/commit/6cc4e195452bc573e34f0b2de295b… 2. https://gitweb.torproject.org/stem.git/commit/e68adb7fdd465e1780bc4ee1243e0… -- neena

1 0

Minimum required ciphers for running Tor as both client and router.
by Gino Badouri 13 Jul '12

13 Jul '12

Hi there, First of all thanks for helping me last time with my mipsel build of Tor with statically linked OpenSSL. It's running fine and we're waiting for the last review of the bandwith-checking scripts before they go live. The second cluster we prepare will consist of low-powered PowerPC devices 250MHz/256MB Ram/8MB Flash. This time Tor will dynamically link to OpenSSL (libcrypto.so.1.0.0 and libssl.so.1.0.0) because there are also other programs depending on it. Because the devices have very limited flash-space the binaries and libraries have to be as small as possible. Tor 0.2.3.19-rc is only 550KB with only libevent staticly linked in (stripped and bz2 compressed). When run, it will be extracted to /tmp, executed and then deleted (since /tmp runs in RAM). It runs very well so far :) However the OpenSSL libraries are quite large for this system and they don't fit in at the moment. libcrypto.so.1.0.0 is 1.9MB and libssl.so.1.0.0 is 375KB (stripped). Our goal is to run Tor both as client and router and therefor I'd like to know the absolute minimum required ciphers for doing so. We've currently compiled OpenSSL 1.0.1 with: NM=powerpc-gnu-nm CC=powerpc-linux-gnu-gcc RANLIB=powerpc-linux-gnu-ranlib AR=powerpc-linux-gnu-ar \ ./Configure --prefix=/home/mastag/root --openssldir=/home/mastag/root/lib/ssl \ shared threads zlib enable-tlsext no-ssl2 no-dso no-idea no-mdc2 no-rc5 \ no-engines no-hw linux-ppc \ >From the OpenSSL documentation it seems that no-hw and no-engines leaves out support for hardware crypto engines so those are safe to set (our devices don't have them). Could anybody provide us with more "no-" options for ciphers we can skip? Thanks alot!

2 2

Re: [tor-dev] Encrypted PM site/hidden service
by Daniel Dennis 13 Jul '12

13 Jul '12

Because I don't have access to phones that may support this I will not try. The code will be open sourced so anyone may port it. But however I will now assume the app may not always be running on an encrypted filesystem so i'll add some support for keeping the files private Anonbox looks cool. It doesnt appear i can write emails? This isn't meant for emails, just simple PMs which you cannot attach image nor need to sign up for. Right now by design i cam PM someone w/o giving them a way to know who i am (although if you want a discussion you should attach your public key) The tech used will be openssl, mono (or .NET) and sqlite. I can drop openssl but i suspect people would prefer using openssl pem keys rather then mono/.NET generated keys. It sounds like you want to know how it works technically. Well, here are some notes i written for myself. It may not make sense or be a little incoherent but perhaps you can get an idea how secure it may be. --What data we have (in the client sqlite db)-- -If app is encrypted, all data unless with a * is encrypted with the symmetric key- db version*, path to pem file*, symmetric key (encrypted with said pem file or generated with PBKDF2 on the users password), misc options, server url, server public key private keys, plain names, ids*, last ident public keys, plain names, ids* association table: association value*, private key id* inbox: private key id*, inmsg/timestamp/optional from public key id outbox: public key id*, outmsg/timestamp/optional reply to public key id draft: same fields as outbox last ident is when the user last identify himself to the server. If user marks server as untrusted this will prevent user from grabbing all his msgs from the server using different keys. This is so the server is less likely to associate a group of keys to one user --- communication to server Handshake with server: Client encrypts random data with server public key, server sends it back plaintext Register public key. Client gives user pub key, server reply's with an encrypted block of random data, client decrypt it using private key then sends it back plaintext Unregister: delete all msgs and public key from user. Of course server sends random data which will need to be sent back as plaintext to verify the key is mine. Send Message: Client send data which is encrypted with AES which key is encrypted with the recipient pub key. The data is msg+optional my reply to/identity pub key) + recipient pub key. This data is compressing with DEFLATE. Server replies with success or error message. It makes sure recipient and your pub key is registered. Also replies with test to ensure the reply-to pub key is yours. Get Messages: Send pubic key i'd like to get messages for. Server sends me random data to send back in plaintext. Then receive all my data (compressed with DEFLATE) Messages is msg + timestamp(UTC server date) + if available the reply to public key. The client app will decrypt the messages and store it either compressed or compressed/encrypted with the db AES key. Timestamp and reply-to pub key are encrypted. Messages are deleted from servers after 10days of retrieval (or immediately). If pub key has not been seen > 1 year he is unregister and all messages are deleted > Date: Thu, 12 Jul 2012 17:12:01 +0000 > From: krugar <tor-admin(a)krugar.de> > To: tor-dev(a)lists.torproject.org > Subject: Re: [tor-dev] Encrypted PM site/hidden service > Message-ID: <4FFF0561.40906(a)krugar.de> > Content-Type: text/plain; charset=ISO-8859-1 > > take a look at https://anonbox.net/ for a similar service. > > a few considerations: if you create an "app" that lives on a mobile > phone, are private keys stored on the phone? are they secured somehow > while the app is running / not running? which public keys will be stored > on the phone? will messages be stored on the phone? > will someone always know who sent a PM, or only if the sender so > chooses? how do you know how to reach someone on your service? are there > pseudonyms? how long to they last? what about key revocation? > what happens if the server is compromised somehow, will attackers be > able to look at the data and see who wrote messages to whom? for which > time period? > > try to clearly define which privacy guarantees you try to achieve > against which type of attacker. the more precise you write this down, > the easier someone can help you spot weaknesses in your concept, and the > better for you and your users once the system is live. > http://dud.inf.tu-dresden.de/Anon_Terminology.shtml may help if you are > uncertain about wording. > > cheers > -k -- http://www.fastmail.fm - Faster than the air-speed velocity of an unladen european swallow

1 0

Onionoo in Python
by Norman Danner 13 Jul '12

13 Jul '12

On 7/6/12 10:34 AM, Sathyanarayanan Gunasekaran wrote:>> OK; Megan and Erik, after you incorporate the export function into >> Descriptor in stem, please start reading through the Django tutorial. > > I'm not sure if Django is a good choice for this project. We don't > require such a heavy web framework with a templating engine, auth, > etc. I'd rather use Tornado or Cyclone+Twisted. Since tor2web, APAF > use Twisted, it would make sense to have onionoo use the same thing. > > I've been hacking on this since morning and I have a very simple > prototype which uses Cyclone that parses only the summary documents > and provides an API for that("/summary") - I will clean it up and put > on github in a bit Is this available yet? >> We'll start working out milestones on Monday (I'm away until Monday morning, >> but I'll probably have occasional e-mail access); Sathyanarayanan, you >> should probably chime in too. So we need to decide on both some milestones and also what various people ought to work on so we avoid stepping on each other's toes. It seems like a natural way to keep some of our work disjoint is to have us primarily work on the back end and Sathyanarayanan on the front end, or vice-versa. Sathyanarayanan, does this sound reasonable to you? Do you have a preference? It sounds like you're already working on the front end, though I was hoping we'd have a chance to play with and learn twisted ourselves a bit. - Norman -- Norman Danner - ndanner(a)wesleyan.edu - http://ndanner.web.wesleyan.edu Department of Mathematics and Computer Science - Wesleyan University

6 10

Flash proxy deployment
by David Fifield 13 Jul '12

13 Jul '12

During the development meeting today, the group interested in pluggable transports decided to begin to deploy the flash proxy transport in the near future. As a reminder, flash proxies use a small JavaScript/WebSocket program to run proxies in a web browser and provide a hard-to-block pool of IP addresses. This message is a call for testing and comment, and a list of known issues that we are working on. I get the impression that some people have unresolved questions and concerns, and I will do my best to answer those. Here are links with some background information. The first URL here has a proxy on it; it's the "I support Internet freedom" graphic at the bottom of the page. http://crypto.stanford.edu/flashproxy/ http://crypto.stanford.edu/flashproxy/flashproxy.pdf https://gitweb.torproject.org/flashproxy.git/blob/HEAD:/README https://lists.torproject.org/pipermail/tor-dev/2011-December/003135.html You don't have to install anything nor configure port forwarding in order to try the flash proxy transport using this command: tor ClientTransportPlugin "websocket socks4 tor-facilitator.bamsoftware.com:9999" UseBridges 1 Bridge "websocket 127.0.0.1:9001" If you're on the miserable hotel wi-fi, try adding: LearnCircuitBuildTimeout 0 CircuitBuildTimeout 1000 Since the last message on this topic, flash proxies no longer use Adobe Flash. They are implemented in JavaScript with WebSocket. We now also work as a pluggable transport. Here is a list of known issues and things on which I especially invite comment. (There is also a Flashproxy Trac ticket component at https://trac.torproject.org/projects/tor/query?component=Flashproxy.) * There is a central host (or hosts) that sees all proxy and client addresses. The facilitator is the component to which clients advertise their addresses and from which proxies pull addresses to connect to. A compromise of the facilitator would lead to disclosure of Tor users' addresses (and retroactively if logs are being kept). * The censored client must be able to receive a TCP connection; i.e., it can't be behind NAT. There are potential avenues to investigate to remove this restriction, but none of them have been looked at. (The command I gave above works even behind NAT, because it is using a client transport plugin running on the public Internet.) * Some of the infrastructure is running on domains other than torproject.org, namely stanford.edu and bamsoftware.com. The proxy badge itself is hosted at http://crypto.stanford.edu/flashproxy/embed.html. The facilitator is at tor-facilitator.bamsoftware.com. bamsoftware.com is mine and it's being used only because I have control of DNS for that domain. I think it would be more seemly for these to have torproject.org addresses (or maybe even just IP addresses). Also, the only relay that supports the websocket transport is mine, tor1.bamsoftware.com, and all flash proxy traffic will use this as a first hop until there are more. * The flash proxy system is supposed to have a covert rendezvous method for the client to register its need for a connection. All we have now is a dumb blockable HTTP-based rendezvous. The plan is to use this until it is blocked and see what we can learn. My idea of "deployment" is that we provide packages for download (with a warning that they are only for testing), and make a blog post publicizing them. The packages will contain the client transport plugin program, a README, and a preconfigured torrc file (but not tor the program nor a Tor Browser). My goal is to begin receiving bug reports from users and other developers, and to begin collecting usage metrics. I wish to enter upon this with due caution and slowness; but I don't want to sit forever on something that could possibly help people. To this purpose I'm trying to be very forthright about the abilities and shortcomings of the flash proxy system. I do hope to receive your consideration and honest feedback, positive and negative. David Fifield

2 3

Tor Export
by Erik I Islo 12 Jul '12

12 Jul '12

Hi Damian, Here is a first draft for the tor export module we have been discussing. I have attached the file as we were having some git issues and I am in a bit of a rush right now. We have been developing the file at stem/descriptors/export.py. Any suggestions or comments would be appreciated -- we have done basic testing, and would be happy to implement some unit & integration tests if this implementation satisfies the needs of the community. Thanks, Erik and Megan.

3 3

New Identity/Client attacks?
by Daniel Dennis 12 Jul '12

12 Jul '12

I'm doing a little brainstorming to properly secure my app specifically made for tor. I notice vidalia has a new identity button. I pressed it and couldn't tell what it did. While looking at the network view i saw a few connections get closed (but not all) and that was about it. It appears every TCP connection creates a new circuit. Is this right? Does this mean every connection i make cannot be associated with another? Finally my last question related to identities is. If a client connects to a hidden service many times is it possible to discover who he is? Perhaps by using timing attacks, cookies, looking at IPs connected to the network etc? Where can i read about it? I don't believe relays know when clients connect to the network unless the client connects to the relay as its first node (is that relay called an entrance relay?) -- http://www.fastmail.fm - Same, same, but different...

1 0

Encrypted PM site/hidden service
by Daniel Dennis 12 Jul '12

12 Jul '12

I have been brushing up on my crypto, security and studied/thought about how tor works and the hidden services although i don't know too much about this part. Anyways so i was thinking i'd make an app that allows people to leave other PMs using public keys. <---- I want to absolutely make sure no one has written or is writing code for anyone to leave anyone else PMs anonymously. The coding part i am not worried about. But the below is what I like to know. 1) Are there still pretty good attacks on hidden services when used by clients? If a user disconnects and connects everyday the hidden service can be found pretty easily? (study clients online, offline and availability of hidden service) Because i don't think decentralize model is a good idea if participants can be found i'm think i will need hosting. 2) Would anyone be willing to host a few static files for me and give me access to update said files? 3) Would anyone be willing to host my service on their server? I'd be using .NET/mono. I believe i can stick with .NET 3.5 (mono 2.6) if needed. 4) Can i use one hidden service but more then one port? I somehow got the impression i can only use 1 port per service but i havent looked into it. This means i'll need a hidden service for the static files and another for a central site. I haven't gone over the numbers but traditionally mono memory footprint is pretty good (i believe under 30mb) but i'll likely need a mysql server however i can stick with files if that is all i have available. -- http://www.fastmail.fm - Access all of your messages and folders wherever you are

2 1

Re: [tor-dev] Proposal 204: Subdomain support for Hidden Service addresses
by Nick Mathewson 11 Jul '12

11 Jul '12

On Fri, Jul 6, 2012 at 10:23 AM, <ale(a)incal.net> wrote: > Hello! > > As discussed with a few people at the Florence Hackfest, here's a quick proposal > for subdomain support on Hidden Service addresses. The implementation seems pretty > straightforward (a patch will follow). > > Please forgive me if the proposal is missing something, or isn't using the > proper Tor-specific technical terms, I'm kinda new to this :) -- I hope it is > understandable nevertheless. Added as proposal 204: Thanks! > > > Title: Subdomain support for Hidden Service addresses > Author: Alessandro Preite Martinez > Created: 06-07-2012 > > > 1. Overview > > This proposal aims to extend the .onion naming scheme for Hidden > Service addresses with sub-domain components, which will be ignored > by the Tor layer but will appear in HTTP Host headers, allowing > subdomain-based virtual hosting. > > 2. Motivation > > Sites doing large-scale HTTP virtual hosting on subdomains currently > do not have a good option for exposure via Hidden Services, short of > creating a separate HS for every subdomain (which in some cases is > simply not possible due to the subdomains not being fully known > beforehand). > > 3. Implementation > > Tor should ignore any subdomain components besides the Hidden > Service key, i.e. "foo.aaaaaaaaaaaaaaaa.onion" should be treated > simply as "aaaaaaaaaaaaaaaa.onion". > The only part I'm worried about here is that we had once considered doing authenticated hidden services or some other kind of wacky hidden service with a design like "bbbbbbbbb.aaaaaaaaaaaaaaa.onion", where bbbbbbbbb is some additional data to use in the protocol. Still, we can still do the above proposal and save room to extend the .onion address scheme: just reserve *.x.onion for all x of length other than 16. -- Nick

2 3