tor-dev

tor-dev@lists.torproject.org

3581 discussions

Ports with hidden/rend services?
by Kevin Evans 17 Jul '12

17 Jul '12

I am utterly dumbfounded by this (it's probably because I'm really tired), but in rendservice.c in the rend_service_t structure, there is a smartlist_t for the ports. How exactly are the [source and destination] ports stored in there? Thanks, Kevin

1 0

Clarification of prop 186
by Linus Nordberg 17 Jul '12

17 Jul '12

Hi, Can votes and consensuses have more than one "a" line? Prop 186 says, on one hand [...] votes should include a single "a" line for every relay that has an IPv6 address, to include the first IPv6 line in its descriptor. [...] The remaining or-address lines will turn into "a" lines in the microdescriptor. I interpret this to mean that there is at most one "a" line in a status vote or consensus. On the other hand it also says Clients that use microdescriptors should consider a node's addresses to be the address:port listed in the "r" line of a consensus, plus all "a" lines for that node in the consensus, [...] and the vote will include whichever set of "a" lines are given by the most authorities who voted for the descriptor digest that will be used for the router. (Is "vote" a typo? Should it read "consensus"?) This makes me think there can be more than one "a" line in both votes and consensuses. -- Linus

3 3

License for flash proxy software
by David Fifield 16 Jul '12

16 Jul '12

I feel there should be a LICENSE file in the flash proxy client packages currently at http://www.bamsoftware.com/dist/flashproxy/. What is the recommended practice? Right now the files carry no license. I would be happy with anything that is free software and convenient to the Tor Project. For example the 3-clause BSD used by obfsproxy is fine. I am pretty sure that I wrote all the code that is in use at this point. David Fifield

3 3

[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 16 Jul '12

16 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev