- tor-dev - lists.torproject.org

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 … [View More]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 [View Less]

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 … [View More]

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 … [View More]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 [View Less]

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 … [View More]

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 … [View More]

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 … [View More]

2 3

Proposal 203: Avoiding censorship by impersonating an HTTPS server
by Nick Mathewson 11 Jul '12

11 Jul '12

Hi all. Here's a proposal for ticket #5548. Let's discuss! Filename: 203-https-frontend.txt Title: Avoiding censorship by impersonating an HTTPS server Author: Nick Mathewson Created: 24 Jun 2012 Status: Draft Overview: One frequently proposed approach for censorship resistance is that Tor bridges ought to act like another TLS-based service, and deliver traffic to Tor only if the client can demonstrate some shared knowledge with the bridge. In this document, I discuss some … [View More]design considerations for building such systems, and propose a few possible architectures and designs. Background: Most of our previous work on censorship resistance has focused on preventing passive attackers from identifying Tor bridges, or from doing so cheaply. But active attackers exist, and exist in the wild: right now, the most sophisticated censors use their anti-Tor passive attacks only as a first round of filtering before launching a secondary active attack to confirm suspected Tor nodes. One idea we've been talking about for a while is that of having a service that looks like an HTTPS service unless a client does some particular secret thing to prove it is allowed to use it as a Tor bridge. Such a system would still succumb to passive traffic analysis attacks (since the packet timings and sizes for HTTPS don't look that much like Tor), but it would be enough to beat many current censors. Goals and requirements: We should make it impossible for a passive attacker who examines only a few packets at a time to distinguish Tor->Bridge traffic from an HTTPS client talking to an HTTPS server. We should make it impossible for an active attacker talking to the server to tell a Tor bridge server from regular HTTPS server. We should make it impossible for an active attacker who can MITM the server to learn from the client whether it thought it was connecting to an HTTPS server or a Tor bridge. (This implies that an MITM attacker shouldn't be able to learn anything that would help it convince the server to act like a bridge.) It would be nice to minimize the required code changes to Tor, and the required code changes to any other software. It would be good to avoid any requirement of close integration with any particular HTTP or HTTPS implementation. If we're replacing our own profile with that of an HTTPS service, we should do so in a way that lets us use a the profile of a popular HTTPS implementation. Efficiency would be good: layering TLS inside TLS is best avoided if we can. Discussion: We need an actual web server; HTTP and HTTPS are so complicated that there's no practical way to behave in a bug-compatible way with any popular webserver short of running that webserver. More obviously, we need a TLS implementation (or we can't implement HTTPS), and we need a Tor bridge (since that's the whole point of this exercise). So from a top-level point of view, the question becomes: how shall we wire these together? There are three obvious ways; I'll discuss them in turn below. Design #1: TLS in Tor Under this design, Tor accepts HTTPS connections, decides which ones don't look like the Tor protocol, and relays them to a webserver. +--------------------------------------+ +------+ TLS | +------------+ http +-----------+ | | User |<------> | Tor Bridge |<----->| Webserver | | +------+ | +------------+ +-----------+ | | trusted host/network | +--------------------------------------+ This approach would let us use a completely unmodified webserver implementation, but would require the most extensive changes in Tor: we'd need to add yet another flavor to Tor's TLS ice cream parlor, and try to emulate a popular webserver's TLS behavior even more thoroughly. To authenticate, we would need to take a hybrid approach, and begin forwarding traffic to the webserver as soon as soon as a webserver might respond to the traffic. This could be pretty complicated, since it requires us to have a model of how the webserver would respond to any given set of bytes. As a workaround, we might try relaying _all_ input to the webserver, and only replying as Tor in the cases where the website hasn't replied. (This would likely to create recognizable timing patterns, though.) The authentication itself could use a system akin to Tor proposals 189/190, where an early AUTHORIZE cell shows knowledge of a shared secret if the client is a Tor client. Design #2: TLS in the web server +----------------------------------+ +------+ TLS | +------------+ tor0 +-----+ | | User |<------> | Webserver |<------->| Tor | | +------+ | +------------+ +-----+ | | trusted host/network | +----------------------------------+ In this design, we write an Apache module or something that can recognize an authenticator of some kind in an HTTPS header, or recognize a valid AUTHORIZE cell, and respond by forwarding the traffic to a Tor instance. To avoid the efficiency issue of doing an extra local encrypt/decrypt, we need to have the webserver talk to Tor over a local unencrypted connection. (I've denoted this as "tor0" in the diagram above.) For implementation convenience, we might want to implement that as a NULL TLS connection, so that the Tor server code wouldn't have to change except to allow local NULL TLS connections in this configuration. For the Tor handshake to work properly here, we'll need a way for the Tor instance to know which public key the webserver is configured to use. We wouldn't need to support the parts of the Tor link protocol used to authenticate clients to servers: relays shouldn't be using this subsystem at all. The Tor client would need to connect and prove its status as a Tor client. If the client uses some means other then AUTHORIZE cells, or if we want to do the authentication in a pluggable transport, and we therefore decided to offload the responsibility TLS itself to the pluggable transport, that would scare me: Supporting pluggable transports that have the responsibility for TLS would make it fairly easy to mess up the crypto, and I'd rather not have it be so easy to write a pluggable transport that accidentally makes Tor less secure. Design #3: Reverse proxy +----------------------------------+ | +-------+ http +-----------+ | | | |<------>| Webserver | | +------+ TLS | | | +-----------+ | | User |<------> | Proxy | | +------+ | | | tor0 +-----------+ | | | |<------>| Tor | | | +-------+ +-----------+ | | trusted host/network | +----------------------------------+ In this design, we write a server-side proxy to sit in front of Tor and a webserver, or repurpose some existing HTTPS proxy. Its role will be to do TLS, and then forward connections to Tor or the webserver as appropriate. (In the web world, this kind of thing is called a "reverse proxy", so that's the term I'm using here.) To avoid fingerprinting, we should choose a proxy that's already in common use as a TLS frontend for webservers -- nginx, perhaps. Unfortunately, the more popular tools here seem to be pretty complex, and the simpler tools less widely deployed. More investigation would be needed. The authorization considerations would be as in Design #2 above; for the reasons discussed there, it's probably a good idea to build the necessary authorization into Tor itself. I generally like this design best: it lets us isolate the "Check for a valid authenticator and/or a valid or invalid HTTP header, and react accordingly" question to a single program. How to authenticate: The easiest way Designing a good MITM-resistant AUTHORIZE cell, or an equivalent HTTP header, is an open problem that we should solve in proposals 190 and 191 and their successors. I'm calling it out-of-scope here; please see those proposals, their attendant discussion, and their eventual successors How to authenticate: a slightly harder way Some proposals in this vein have in the past suggested a special HTTP header to distinguish Tor connections from non-Tor connections. This could work too, though it would require substantially larger changes on the Tor client's part, would still require the client take measures to avoid MITM attacks, and would also require the client to implement a particular browser's http profile. Some considerations on distinguishability Against a passive eavesdropper, the easiest way to avoid distinguishability in server responses will be to use an actual web server or reverse web proxy's TLS implementation. (Distinguishability based on client TLS use is another topic entirely.) Against an active non-MITM attacker, the best probing attacks will be ones designed to provoke the system in acting in ways different from those in which a webserver would act: responding earlier than a web server would respond, or later, or differently. We need to make sure that, whatever the front-end program is, it answers anything that would qualify as a well-formed or ill-formed HTTP request whenever the web server would. This must mean, for example, that whatever the correct form of client authorization turns out to be, no prefix of that authorization is ever something that the webserver would respond to. With some web servers (I believe), that's as easy as making sure that any valid authenticator isn't too long, and doesn't contain a CR or LF character. With others, the authenticator would need to be a valid HTTP request, with all the attendant difficulty that would raise. Against an attacker who can MITM the bridge, the best attacks will be to wait for clients to connect and see how they behave. In this case, the client probably needs to be able to authenticate the bridge certificate as presented in the initial TLS handshake -- or some other aspect of the TLS handshake if we're feeling insane. If the certificate or handshake isn't as expected, the client should behave as a web browser that's just received a bad TLS certificate. (The alternative there would be to try to impersonate an HTTPS client that has just accepted a self-signed certificate. But that would probably require the Tor client to impersonate a full web browser, which isn't realistic.) Side note: What to put on the webserver? To credibly pretend not to be ourselves, we must pretend to be something else in particular -- and something not easily identifiable or inherently worthless. We should not, for example, have all deployments of this kind use a fixed website, even if that website is the default "Welcome to Apache" configuration: A censor would probably feel that they weren't breaking anything important by blocking all unconfigured websites with nothing on them. Therefore, we should probably conceive of a system like this as "Something to add to your HTTPS website" rather than as a standalone installation. [View Less]

4 3

Re: [tor-dev] Onionoo in Python
by Norman Danner 11 Jul '12

11 Jul '12

(Side-conversation that got off of tor-dev@, bring it back.) Based on what Sathya has to say, along with our own playing around with plain Twisted, I'm inclined to agree that Cyclone provides enough extra value to justify the additional dependency. Sathya, do you want to work on the back-end while we work on the front-end (starting with the code you've already written)? - Norman On 7/11/12 12:58 AM, Sathyanarayanan Gunasekaran wrote: > Also, the python version of Onionoo is going to … [View More]

2 1

Arturo's June Status Report
by Arturo Filastò 11 Jul '12

11 Jul '12

# Summary I worked mainly on documentation and specification tasks related to OONI. Did a bit of travelling and a bit of coding too. # Documentation/Design related The wiki is starting to look good. Most of the basic analysis required for moving on to implementing OONI is in place. We still need to have some more discussion on a few design choices, but the overall concept is in place. In particular we have finished the analysis of Tests. I created templates for the analysis of … [View More]Censorship detection tools (https://trac.torproject.org/projects/tor/wiki/doc/OONI/CensorshipDetectionT…) did the analysis of Neubot: https://trac.torproject.org/projects/tor/wiki/doc/OONI/CensorshipDetectionT… and of Herdict: https://trac.torproject.org/projects/tor/wiki/doc/OONI/CensorshipDetectionT… We created the methodology for specifying and writing OONI probe tests: https://trac.torproject.org/projects/tor/wiki/doc/OONI/TestWritingMethodolo… created a module view and a component and connector view and specified the overall architecture of OONI: https://trac.torproject.org/projects/tor/wiki/doc/OONI/Architecture I started defining the API for the backend system in particular the reporting mechanism: https://trac.torproject.org/projects/tor/wiki/doc/OONI/Backend. In the past days had some discussions with jake and isis if we should be using HTTP for reporting. Jake suggested that we use rsync instead of HTTP. I will detail in a following mail the pro and cotra of one solution over the other. We finished specifying the basic set of Test for OONI here: https://trac.torproject.org/projects/tor/wiki/doc/OONI/Tests The data collection scheme has been defined here: https://trac.torproject.org/projects/tor/wiki/doc/OONI/DataCollection. I got a few good tips from Nick on the topic of design and specification of software. What I took from it is that in the end the design that you make will not be ultimate and you will end up changing it. For this reason it's good to start implementing some of the tests and that will allow you to understand what is the abstraction that fits all of them. He used a very nice analogy, it's like having a set of points in N dimensional space and by designing an abstraction for it you are trying to find an hypercube that fits all of them (I may have a bit re-elaborated this). # Coding Implemented an HTTP utility library for writing HTTP based OONI tests and implemented a few of the using such library. Wrote a OONI scapy twisted library that replaces scapys send and receive functions with some based on twisted. Wrote an OONI Test protocol for it. Implemented based on OONI a test written by phw that does packet mutation to bissect censorship fingerprints. Misc. code refactoring. # Travel/Advocacy Travelled to Madrid to do a talk on Tor and GlobaLeaks. Met there with Jillian York. Went to hackmeeting in l'Aquila and did a talk about Tor and censorship ( http://www.slideshare.net/hellais/tor-censorship-2012-ooni) I believe this talk went very well and everybody was very excited about Tor at the end of it. # What I plan to do next Work on drawing these N dots, by implementing test for OONI. I will finish one of the first fully client server tests based on OONI called b0wser (the server part is almost done). Figure out what should be done with the backend and start having a test backend deployment on ooni.nu. - Art. [View Less]

1 0

Adding bridge support to chutney
by Linus Nordberg 11 Jul '12

11 Jul '12

Hi, Chutney is a program created by Nick that can be used for setting up and operate a test tor network. It can generate torrc files from a network configuration file and torrc template files. It can further start, hup and stop all the tor processes needed to run the network. I've added support for bridges to chutney. It's in branch 'bridges' of user/linus/chutney.git. I will add support for bridge authorities handling IPv6 bridges, bridge relays with an IPv6 OR port and clients using … [View More]

1 0

Tomas' June 2012 status report
by Tomás Touceda 10 Jul '12

10 Jul '12

Hi everyone, Here's what I did for Vidalia in June: - Reviewed a series of patches from other people: TorrcPrototype implementation and some Torrc parsing fixes by feroze, the testing framework by sebb, up to date country code/flags handling by sirop, a Network Map stream traffic patch by an anonymous contributor. - Improved Network Map by adding Entry/ExitNode handling, better display of relays in the router list, better handling of microdescriptors, improved performance in loading the whole … [View More]

1 0

Mike's June 2012 Status Report
by Mike Perry 10 Jul '12

10 Jul '12

I fixed the following bugs in June: https://trac.torproject.org/projects/tor/query?keywords=~MikePerry201206 Exec Summary of Trac Tickets: I reviewed WebGL for fingerprinting issues as well as reviewed a rendering-based fingerprinting vector and produced plans for next steps/defenses on both fronts. I rebased our Firefox patches to both 10.x-ESR and 13.0, and wrote a script to immediately alert us of new releases via email. I spent some time shepherding a Windows TBB patch by Shondoit. I also … [View More]commented a whole bunch of Torbutton code with priority levels so that it may be ported over to Proxy Mobile or eliminated. The future will run on a Proxy Mobile derivative. Nick and I also worked on a Tor patch to help Tor clients defend against "path bias"/"route capture" attacks, but we still need to tune the parameters more. Non-trac tasks: I made some progress on determining how to set optimal parameters for the "path bias"/"route capture" defense (ticket #6138). I wrote a python simulation and determined next steps (12 points, development). I finished up the Tor core interview process by sending out "rejection" letters suggesting specific areas where the applicants could apply their skills in potential future positions at Tor, and at least volunteer in those areas in the meantime (5 points). I spent an unsettling amount of time on email, coordination, and general conspiracy. It seems to have gone up from last month to about 8 points/week this month. (32 points). I spent a day and some change with the EFF and working on HTTPS-Everywhere issues (6 pts, development). I did some postmortem on our first volunteer QA run, replying to results and filing tickets about potential future tests. More postmortem is needed. Hopefully I can get to it before the next TBB release. (1 point). Time Keeping Notes: I did 31 points of trac-recorded development activity this month, in addition to 18 more points of development on tickets not yet closed, for a total of 49 points of development activity. I did 38 points of non-development work this month. A bit more sane ratio than last month, but man is email a time sink. Trac Workload Stats: I only closed 7 tickets of priority major and above in June. Sad. At the beginning of June, 50 major+ tickets were opened against me. As of this report, 54 major+ tickets are now opened against me. This means I've lost roughly 4 months of forward progress against major issues (I had previously been closing about 1 major+ ticket more per month than were opened against me). https://trac.torproject.org/projects/tor/query?status=accepted&status=assig… aka https://bit.ly/KZcmA9 Next month: https://trac.torproject.org/projects/tor/query?keywords=~MikePerry201207 Exec Summary: I'm going to throw much less on the queue ahead of time this month, due to a week being lost to fascistly shitty Internet access (yes, fascistly. Adverbing is the new new hotness now. Verbing is so OVER) during the dev meeting in Italy, as well as last month seeing way less closed tickets than expected. There's also a lot more conspiring to be done, as it turns out. -- Mike Perry [View Less]

1 0

Mike's May 2012 Status Report
by Mike Perry 10 Jul '12

10 Jul '12

For comparison with June and to follow Roger's example, here's my May status report. ----- Forwarded message from Mike Perry <mikeperry(a)torproject.org> ----- I fixed the following bugs in May: https://trac.torproject.org/projects/tor/query?keywords=~MikePerry201205 Exec Summary of Trac Tickets: I designed a volunteer TBB testing program. We're still working out the bumps, but I'm pretty confident that we'll be able to keep the overhead at the level of "one email + an scp" for … [View More]Erinn. I fixed several very serious Tor Browser bugs, including a DNS leak, a disk leak, an evercookie leak, and I released a Torbutton 1.4.6 using an offline update signing key (no more remote code exec through arbitrary CA compromise!). I also bumped the Torbutton useragent, clear search+find boxes on New Identity, perform the TBB versioncheck regularly in the background, updated the captcha redirect to startpage, fixed a window sizing issue, synced some important Torbutton and TBB prefs with eachother, and did some review + made some suggestions for Torbirdy. Most notably from a support perspective, Torbutton 1.4.6 informs users about TBB, and is no longer togglable (though you can re-enable toggle if you uncheck a checkbox in the prefs). Non-Trac Tasks: I helped with the tor core interview process, determining stages, reviewing resumes and phone screening candidates, and helping Nick with the third round coding question. (20 points). I reviewed a handful of trac tickets and did some triage. (3 points). I made a first pass at a patch to detect path bias (2 points). I reviewed another silly website fingerprinting attack paper. (2 points). I spent a fair amount of time on email. It seems like it comes down to about 6 points per week on average, with the exception of this last week, where I spent an additional 16 points arguing about volunteer processes and the benefits of involving the community in our work. (6*4 + 16 = 40 points). Time keeping notes: I did 40 points of trac-recorded development activity this month. I did 67 points of non-trac work this month. That's a total of 107 points, which is roughly 214 hours, give or take about 20 hours for rounding error. I really failed at timeboxing work in the last week, which is I think why this number is so high compared to last month. Trac workload stats: I closed 14 tickets of major priority or above, yet there are still currently 50 tickets of major priority or above opened against me. This is one less than the number of tickets last month! I'm still making steady progress at a rate of 1 major+ ticket per month (same rate as last month)! I'll be done with them all in just a scant 50 more months! :) https://trac.torproject.org/projects/tor/query?status=accepted&status=assig… https://bit.ly/KZcmA9 Next Month: https://trac.torproject.org/projects/tor/query?keywords=~MikePerry201206 Exec Summary: Fix TBB fingerprinting and linkability issues, updating the TBB design doc, rebase Tor Browser to Firefox 10.x ESR, publish the relay best practices doc + scripts, write a build security proposal outline, work on the path bias issue. Probably also help smooth out tor-qa process a bit more. -- Mike Perry ----- End forwarded message ----- -- Mike Perry [View Less]

1 0

Re: [tor-dev] Stem Descriptor Parsers
by Norman Danner 10 Jul '12

10 Jul '12

OK, bringing back to tor-dev... On 7/5/12 1:44 PM, Damian Johnson wrote: > Hi Norman. > >> (Taking this off tor-dev@ for the moment until we get things straightened out...) > > Actually, this would have been an interesting discussion for the list. > Feel free to add it back in. > >> The TorExport functionality seems pretty straightforward, but the stem-interesting parts (new descriptor parsers) already seem to be on Ravi's punch-list. > > My understanding is … [View More]that the csv work is to add export (and maybe > import) functionality to the Descriptor class. This would provide > those capabilities to the current ServerDescriptor and > ExtraInfoDescriptor classes in addition to anything we add in the > future like consensus based entities. If it really isn't possible to > do in the Descriptor then it would be an abstract method that's > implemented by Descriptors as we go along. OK, there's the first confusion on my part; I thought the export functionality was to be something like utility scripts rather than built into stem itself. So is export intended to be an instance method of descriptor, one that just dumps a single csv line of the instance attributes (maybe subject to some selection of those attributes)? Or a static method that takes a collection? It seems like it might be awkward to have to hack stem itself to add a new export format (for example). Is this a concern? Actually, this makes me wonder a bit about what exactly stem is. It seems like it is: * stem the Tor Control Protocol interface, and * stem the (relay, network status,...) descriptor utility library. It seems that the former is dependent upon the latter (for stem to provide a list of cached descriptor objects, it needs a descriptor utility library that defines those objects), but not the reverse (the utilities don't much care where the descriptors come from). This isn't completely correct, since the descriptor utilities might provide APIs for parsing some source of descriptor(s) (Tor Control message, cached-consensus, metrics), but making the descriptor utility library one module among many in stem makes it seem like they are more intertwined than they appear. Of course, you've been thinking about this a lot longer than have I. Do all the known use-cases make need both an interface to Tor Control and a descriptor utility library? I guess I'm not quite sure what the design philosophy for stem is. >> Onionoo is always a possibility, though we'd probably need a bit more guidance on which part to work on (front end, back end, both?). But regardless, it still seems like it depends on various parsers that Ravi is working on. > > For an Onionoo project I would be the main mentor for stem based > parts, and Karsten would mentor the work on Onionoo itself since he > wrote the java version (though I'll still do the code reviews). First > step would be to start a thread with both of us (and tor-dev@) to > figure out milestones. > > FYI: at the Tor dev meeting Sathyanarayanan (gsathya.ceg(a)gmail.com) > also expressed interest in taking on this project, though with his > summer internship I'm not sure how much time he'll have to help. Do I understand Onionoo correctly to be basically a small webservice that returns a JSON formatted description of data read from a file based on the HTTP request parameters, along with a program that presumably runs with some frequency to create that file? It seems that at least porting the webservice side to a Django webapp might be a reasonable project for the rest of our summer. However, the little bit of software development that I learned does make me want to ask: Why a Python port or this component? - Norman -- Norman Danner - ndanner(a)wesleyan.edu - http://ndanner.web.wesleyan.edu Department of Mathematics and Computer Science - Wesleyan University [View Less]

6 9

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

09 Jul '12

Hello again I am currently working on implementing the network status (v3) descriptor parsers. I will implement the microdescriptor parsers after I'm done with that. The Python Onionoo implementation requires them, so I have paused working on the controller for now. I will resume working on the controller class once I'm done implementing these descriptor parsers. Damian reviewed and merged the setconf/reset methods into stem/master earlier today[1]. I will also be getting some of the other … [View More]

1 0

One man left a message for you
by Badoo 08 Jul '12

08 Jul '12

One man left a message for you Only you can see the sender and content of your message, and you can delete it anytime. You can instantly reply using our message exchange system: http://eu1.badoo.com/0246897483/in/EEdZpyZMo6Y/?lang_id=3&m=63&mid=4ff9eb00… Some other people in the area who are on Badoo Segun (Ibadan, Nigeria) Becky Jay (Ibadan, Nigeria) Sarath Cristina (Ibadan, Nigeria) http://eu1.badoo.com/0246897483/in/EEdZpyZMo6Y/?lang_id=3&m=63&mid=4ff9eb00… If the link … [View More]

1 0

[PATCH] Implement proposal xxx: ignore subdomains in hidden service addresses
by Jérémy Bobbio 08 Jul '12

08 Jul '12

The implementation is pretty straightforward: parse_extended_hostname() is modified to drop any leading components from an address like 'foo.aaaaaaaaaaaaaaaa.onion'. --- Warning! Tests on this patch were limited to 'make check'. src/or/connection_edge.c | 10 +++++++++- src/test/test.c | 4 ++++ 2 files changed, 13 insertions(+), 1 deletions(-) diff --git a/src/or/connection_edge.c b/src/or/connection_edge.c index 3c8b4bc..92a3dbe 100644 --- a/src/or/connection_edge.c +++ b/… [View More]

2 2

unsubscript
by after1990s 07 Jul '12

07 Jul '12

1 0

Proposal: Subdomain support for Hidden Service addresses
by ale＠incal.net 06 Jul '12

06 Jul '12

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. Title: Subdomain support for Hidden Service addresses Author: Alessandro Preite Martinez Created: 06-… [View More]

1 0

Fwd: Stem Descriptor Parsers
by Ravi Chandra Padmala 03 Jul '12

03 Jul '12

Forwarding Megan's email because it looks like it's stuck in the mailing list's moderation queue. ---------- Forwarded message ---------- From: Megan Chang <mchang01(a)wesleyan.edu> Date: Mon, Jul 2, 2012 at 9:24 PM Subject: [tor-dev] Stem Descriptor Parsers To: neenaoffline(a)gmail.com Cc: Erik I Islo <eislo(a)wesleyan.edu>, Norman Danner <ndanner(a)wesleyan.edu>, tor-dev(a)lists.torproject.org Hi Ravi, We're currently working on data export for Stem and were wondering … [View More]

1 0

Damian's Status Report - June 2012
by Damian Johnson 03 Jul '12

03 Jul '12

Hi all. This June I exchanged my developer hat to be a mentor instead, spending more time reviewing code than writing it myself. Fingers crossed that at least one or two of them stick around after the summer ends! As such, this status report is more about other people than me. Apologies if I miss anything. * Ravi (GSoC Student) This month Ravi discovered a bug with Tor's GETCONF method [1] and wrote numerous features including SAFECOOKIE support [2] and a GETCONF method for the controller [3]… [View More]. The GETCONF handling is complicated by the accursed HiddenServiceOptions so it has needed several iterations, but I plan to merge it this week. After that Ravi already has two more feature branches lined up for me to review (*sob*)... * Beck (Volunteer) Somehow I've never been able to bring myself to do development on Windows (if you haven't seen Neal Stephenson's Hole Hawg article then I recommend it [4]). Fortunately Beck does, and has done a fantastic job of fixing stem and its tests to work there [5][6]. He also added get_version(), authenticate(), and protocolinfo() methods to the controller. * Erik and Megan (Wesleyan Students) Erik and Megan have been focusing on stem's tests, first submitting a couple fixes for the mocking module [7][8] then writing unit and integration tests for the proc utilities [9]. Next they plan to implement the CSV export functionality suggested by naif [10]. * Sathyanarayanan (Volunteer) Though work has kept him pretty occupied, Sathyanarayanan has been working on an ExitPolicy class [11] and is presently at the dev meeting making plans to implement a python based Onionoo. * Karsten Though he isn't hacking on stem itself, Karsten has been helping by reviewing its descriptor handling and suggesting improvements [12][13]. Besides those, I implemented a few stem improvements too this month... * Sphinx Documentation At the start of June I rewrote stem's documentation into reStructuredText so it could be compiled by Sphinx. The results are very pretty... http://www.atagar.com/transfer/tmp/stem_html_12_06_05/ * Python 2.5 Compatibility Stem aims to support python versions 2.5 and above (in the 2.x series). However, most of our development has been on 2.7, letting backward incompatible changes slip in inadvertently. This ended up being a two week bug fixing odyssey, but now that it's done stem and its tests should now work if users want an interpretor that harks back to 2006... * Test Freezing Issue on Mac OSX Both Sathyanarayanan and Karsten reported that stem's integ tests freeze on Mac OSX. After a dozen hours of hair pulling I've narrowed it down to an issue where control sockets are left in a CLOSE_WAIT state when closed, and eventually we lose the ability to make new control sockets... https://trac.torproject.org/6235 >From what I can tell this is either an issue with Tor, Python, or Mac OSX (my money's on the last). Help welcome if anyone has ideas. Other random things from this month include going to the Fremont Fair, attending a SEAPIG meeting (local python developer group) and making travel arrangements to attend Defcon later in July. Cheers! -Damian [1] https://trac.torproject.org/6172 [2] https://trac.torproject.org/5262 [3] https://trac.torproject.org/6114 [4] http://www.team.net/mjb/hawg.html [5] https://trac.torproject.org/5493 [6] https://trac.torproject.org/6205 [7] https://gitweb.torproject.org/stem.git/commitdiff/66376f5 [8] https://gitweb.torproject.org/stem.git/commitdiff/385b05b [9] https://trac.torproject.org/6082 [10] https://trac.torproject.org/6171 [11] https://trac.torproject.org/5454 [12] https://lists.torproject.org/pipermail/tor-dev/2012-June/003608.html [13] https://trac.torproject.org/6257 [View Less]

1 0

Re: [tor-dev] Stem Descriptor Parsers
by Ravi Chandra Padmala 03 Jul '12

03 Jul '12

On Mon, Jul 2, 2012 at 9:24 PM, Megan Chang <mchang01(a)wesleyan.edu> wrote: > Which descriptor parsers are you referring to, as some are already > implemented? A lot of what we're working on in Tor Export overlaps your work > regarding descriptor parsers. According to my proposal, I was to implement the parsers for V3 network status documents and microdescriptor documents for the mid term evaluation. > Do you mind if we take on the minor task of working on descriptor parsers?… [View More]

2 1

[GSoC] Vidalia - Week 6
by Feroze Naina 02 Jul '12

02 Jul '12

I have created the Hidden Service plugin. Currently, the plugin loads the list of hidden services from the torrc file and displays it in a custom widget consisting of line-edits and spinbox inside a groupbox. This is then displayed in a vertical layout in the container widget's scroll-area. The values of HiddenServiceDir and HiddenServicePort are displayed in line-edits. If the Hidden Service had been activated previously, the hostname string is fetched from the file and displayed inside the … [View More]

1 0

[GSoC] Pluggable Transports in Python Status Update
by Brandon Wiley 02 Jul '12

02 Jul '12

Status Update - Refactoring There was a slight change in the schedule in that I moved refactoring up in front of testing and debugging. The major refactoring effort was in splitting the project into two parts. The library for implementing the pluggable transport specification, with environment variable parsing and printing of pluggable transport protocol lines to stdout is now all that is included in pyptlib. The framework and obfsproxy command line program replacement have been split off … [View More]

1 0