- tor-dev - lists.torproject.org

Is it possible to run private Exit nodes?
by SiNA Rabbani 08 Aug '12

08 Aug '12

I have been running private bridges for my VIP contacts for a long time. I use PublishServerDescriptor 0 to keep my bridges private. Is it possible to also run a private Exit node? What would happen, if I hard coded an exit into my torrc that is not published (if possible at all)? All the best, SiNA -- “If I had eight hours to chop down a tree, I’d spend the first six of them sharpening my axe.” -Abraham Lincoln

3 2

Next Tor release timeframes?
by Roger Dingledine 08 Aug '12

08 Aug '12

1) Do we have any requirements to release an 0.2.4.1-alpha at any particular date? I haven't been following e.g. the latest SponsorG timelines. 2) Nick was enthusiastic about an 0.2.2.38 with the latest fix. Nick, do you still think that's important? My sense is that it's a totally esoteric theoretical attack where there's no rush to release. 3) For the next 0.2.3 rc, we might want to merge at least: https://trac.torproject.org/projects/tor/ticket/6252 https://trac.torproject.org/projects/tor/ticket/6404 --Roger

3 2

[patch] fix vidalia compilation in gcc 4.7
by Jason A. Donenfeld 08 Aug '12

08 Aug '12

Fixed in a gentoo bug report: https://422645.bugs.gentoo.org/attachment.cgi?id=320722

2 1

http_apache_steg_t is working now
by vmonmoonshine＠gmail.com 08 Aug '12

08 Aug '12

Hey Zack, I have pushed the working version of http_apache_steg_t. On server side it asks apache for the load, on the client side it uses the url dictionary and parameter values. http_apache_steg_t is inherited from http_steg_t. But because of all those macro hackish tricks (which expect you to inherit only from steg_t), it feels bit odd (when c++ natively support polymorphism maybe we don't need these macros). So you can test it writing http_apache instead of http in the command line. (but you need apache installed on server side and you need to run payload_scraper first) Downstream client to server is only curl now and hence probably more robust while passing proxies. It's blocking though. I'll make non-blocking in near future. I'm going to implement the protocol for passing the dictionary from the server to client in following few days and spends next week testing, writing tests and applying your comments on github (including spelling and grammatical mistakes :p ) Cheers, vmon P.S. I'm slowly re-styling stuff in the steg directory to c++ style, meanwhile it might look even uglier and messier, but it'll be pretier at end.

1 0

Re: [tor-dev] #6512 [Stem]: TorExport Module and Unit Testing
by Erik I Islo 07 Aug '12

07 Aug '12

Hi Damian, Looking at coverage the test provides, I was under the impression that the various cases of include_fields and exclude fields (e.g. if they overlap) should also be tested, but if you find that unnecessary, that would help explain why my unit tests were difficult to follow. In the mocking changes that I made, I added functionality for mocking functions that take keyword arguments. Though it is no longer necessary with the new unit tests, I was wondering if there was something I could have done better with that code as it seems such functionality may come in useful in the future. You may have already noticed this (and your documentation is consistent with this), but just to be sure, the new export code won't work with generators, which I bring up as this is what server_descriptor.parse_file() returns. So a user of this module would need to covert that generator into a list or tuple, which could be rather large. >>> def gener(list=[1,2,3,4]): ... for item in list: ... yield item >>> gener()[0] Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: 'generator' object has no attribute '__getitem__' Working with Professor Danner this summer (and from the CS classes I have taken so far), I am under the impression that run-time type checking can be expensive and generally falls outside of the realm of 'pythonic' code. To help Megan and I understand this design change, could you explain why you went with this style (e.g. line 83 in stem/descriptor/export.py)? Along similar lines, why wouldn't we also check the types of other parameters passed into the function? Thank you in advance for answering these questions -- this summer has been (and still is) a phenomenal learning experience for us, and gaining insight on coding style and the like is crucial to developing our own coding techniques. Looking at the code, I must apologize. I didn't mean to take so much of your time rewriting the code. That said, looking at your implementation gave me some perspective in evaluating the code I submitted so I don't make similar mistakes in the future. Best, Erik On Sat, Aug 4, 2012 at 3:22 PM, Tor Bug Tracker & Wiki < torproject-admin(a)torproject.org> wrote: > #6512: TorExport Module and Unit Testing > > ----------------------------+----------------------------------------------- > Reporter: ErikI | Owner: atagar > Type: enhancement | Status: closed > Priority: normal | Milestone: > Component: Stem | Version: > Resolution: implemented | Keywords: > Parent: | Points: > Actualpoints: | > > ----------------------------+----------------------------------------------- > Changes (by atagar): > > * status: needs_review => closed > * resolution: => implemented > > > Comment: > > Thanks Erik, merged with some revisions [1]. I found the unit tests a bit > hard to follow, especially since it wasn't broken down by the test cases > so I rewrote those. Let me know if I missed any test cases that you think > are important. > > [1] > > https://gitweb.torproject.org/stem.git/commitdiff/7022021c4207a0066cb932616… > > -- > Ticket URL: < > https://trac.torproject.org/projects/tor/ticket/6512#comment:3> > Tor Bug Tracker & Wiki <https://trac.torproject.org/> > The Tor Project: anonymity online >

2 1

[GSoC] Stem descriptor parsing - Status update
by Ravi Chandra Padmala 06 Aug '12

06 Aug '12

Hello I spent the last two weeks implementing the network status document parser and the microdescriptor consensus parser. The network status document parsing code is ready for review here[1]. It's a fairly large amount of code, with ~1.4K new LoC. The microdescriptor consensus parser is much simpler, since it reuses most of the network status document parsing code. I'll be uploading that soon. I should be working on the controller's event handling methods after that. 1. https://trac.torproject.org/projects/tor/ticket/6569 -- neena

1 0

Damian's Status Report - July 2012
by Damian Johnson 05 Aug '12

05 Aug '12

Hi all. My July was mostly spent traveling, both for Defcon [1] and a couple visits with my family on Vashon (for a funeral and Strawberry Festival). August will be much the same. I'll be gone... * 8/8 - 8/12 for Toorcamp [2] * 8/17 - 9/3 for a family trip Besides that and cat wrangling for the GSoC midterms, here's the things I did this month... * Implemented an ExitPolicy class [3]. Sathyanarayanan did the initial port of the class from arm, but that implementation turned out to have several issues (no IPv6 support, masking was incomplete, didn't strictly conform to the spec) so I ended up rewriting it. The result was pretty nice... https://gitweb.torproject.org/stem.git/blob/HEAD:/stem/exit_policy.py https://gitweb.torproject.org/stem.git/blob/HEAD:/test/unit/exit_policy/pol… https://gitweb.torproject.org/stem.git/blob/HEAD:/test/unit/exit_policy/rul… * Not tor related, but submitted five patches to ReviewBoard... * Re-enabling lexer guessing based on content [4] * Supporting dashboard impersonations [5] * Better supporting mixed newline types in diff reconstruction [6] * Crashing issue when authentication fails [7] * Better handle perforce symlinks [8] * Variety of small things... * Skipping tests on OSX that make numerous sockets to unblock development there [9] * Unsuccessful attempt to fix Windows specific date formatting issue [10] * Forgot to account for tor's debugger disabling in stem's proc tests [11] * Supporting the transport line in extrainfo descriptors [12] * Expanding the Version class and tor spec to include git commit ids * Variety of pylint fixes [13] * Discussion about is_alive() handling and quitting the socket [14] * Ravi has also been busy, finishing several controller methods... * GETCONF support [15] * SETCONF and RESETCONF support [16] * LOADCONF and SAVECONF support [17] * SETFEATURE support, though this one's still incomplete [18] Cheers! -Damian [1] http://www.atagar.com/arm/log.php#defcon2012 [2] http://www.toorcamp.org/ [3] https://trac.torproject.org/5454 [4] http://reviews.reviewboard.org/r/3156/ [5] http://reviews.reviewboard.org/r/3207/ [6] http://reviews.reviewboard.org/r/3208/ [7] http://reviews.reviewboard.org/r/3209/ [8] http://reviews.reviewboard.org/r/3221/ [9] https://trac.torproject.org/5917 [10] https://trac.torproject.org/6206 [11] https://trac.torproject.org/6286 [12] https://trac.torproject.org/6257 [13] https://gitweb.torproject.org/stem.git/commitdiff/fd2da10 [14] https://trac.torproject.org/6234 [15] https://trac.torproject.org/6114 [16] https://trac.torproject.org/6239 [17] https://trac.torproject.org/6356 [18] https://trac.torproject.org/6417

1 0

OnionOO protocol questions
by Norman Danner 04 Aug '12

04 Aug '12

Hi Karsten, A few questions on the Onionoo protocol specification: If multiple parameters are specified in the GET request, does that imply a logical and or a logical or (or something else)? E.g., suppose the GET request has type=relay and lookup=FFFF... . To me it seems like that should return the relay with fingerprint FFFF..., if there is such a relay. But it could also mean return all relays as well as the router with fingerprint FFFF... . The search parameter is described as "Return only relays with the parameter value matching the beginning of a nickname, (possibly $-prefixed) fingerprint, or IP address..." Do you mean that the parameter value matches the beginning of a nickname, the beginning of a (possibly $-prefixed) fingerprint, or is one of the relay IP addresses? For ordering, what do you mean by "possible fields for ordering are: consensus_weight." This is really two questions. How is the consensus_weight ordering defined when producing a summary document (which doesn't include a consensus weight field)? Can clients not request that summary documents be ordered by any of the 'n', 'f', 'a', or 'r' fields? Thanks! - Norman -- Norman Danner - ndanner(a)wesleyan.edu - http://ndanner.web.wesleyan.edu Department of Mathematics and Computer Science - Wesleyan University

2 4

[GSoC] Stegotorus
by vmon 04 Aug '12

04 Aug '12

Hi there, The payload strategies can be changed easily now by inheriting different class from PayloadServer. Current strategy is now in TracePayloadServer. For ApachePayloadServer strategy, server side is complete. for the client side, I need a handshake in steg level so the server sends the client, url dictionary. This needs to manipulate the program in level of Chop protocol. I spent few days to add this capability where chop send a reply handshake to the client (based what is in the paper) I haven't find it yet. Time to ask my mentor. Cheers, vmon

3 2

Sathya's status report - July 2012
by Sathyanarayanan Gunasekaran 04 Aug '12

04 Aug '12

July 2012 - Attended Tor dev meeting and hackfest in Florence in the first week of July. - Talked to arma, Karsten and asn about helping out with certain metrics tasks(#6460, #6232) to figure out the safety of the Tor network. Hopefully, I can extend this to something bigger and hack on it for my undergrad thesis. - Hacked on a entropy-over-time script(#6232) with help from Karsten, phw and asn. - Pair programmed with neena, helping him with his GSoC work(the consensus and votes descriptor parser). - Discussed pyonionoo components on the tor-dev mailing list[0]. - Hacked on the web service for pyonionoo for a bit at the hackfest. Megan is currently refactoring it and making it awesome. - Started work on the pyonionoo backend(#6452) - - Completed the network status document parser for summary documents - Taught pyonionoo about stem to parse server descriptors for details documents - Next up - Refactor this and add bandwidth documents. - Finished ExitPolicy parser for stem(#5454), which Damian ended up rewriting mostly. - Discussed the proper way to check if the Tor control socket is closed or not(#6234) which led to "Tor should have a PING command to check"(#6354), but arma and nickm are of the opinion that we shouldn't have any more pre-auth commands since it makes Tor more complex / less safe. Stem now makes a best-effort call (errors ignored) since we just want the socket to shut down and we don't need the QUIT to succeed to do that. - Discussed about setting up a code review tool(#6402). I've set up an ec2 instance with ReviewBoard and will hopefully set up the repos with some help from Damian soon-ish. [0] - https://lists.torproject.org/pipermail/tor-dev/2012-July/003731.html

1 0

Ticket #5749
by SiNA Rabbani 03 Aug '12

03 Aug '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have attached a patch: 0001-Faravahar-added.patch.asc to this ticket. Faravahar is very much ready! The patch is gpg signed, let me know if there are any other actions required on my part. All the best, SiNA - -- "If I had eight hours to chop down a tree, I?d spend the first six of them sharpening my axe." -Abraham Lincoln -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJQHDhXAAoJEJPBwXYLR9Vt2Q0P/jRRUvrjB0AcoFagw9rUZzFr 1Os0RYPk1j9HXz30xJy9u+3sLQAaRQovpgvRJJv6GY0Jb+RCI9A4k6ExaHO4nxHq OJPhW6HcWa+w6QcFxIb4GizYVKthxcxcBPfVGPXvzH/U/gkGiuJYGNTXeCUhZNi9 JI5gtfOriwp7pspcXyufLZcAcjGE+8LKlwnEhqNeMhw6bGvqWFuueb5ZYLQwuOn/ ngtLFsD1NnAXgTAJY9wFS9tTmDX3wISKzMq726lKieOBqOH2v4+nkusoq8CUNfjK NPq8MsrtHEtxsEdR5nMy2PDROKHsUNclO9mV8+W/K5nRDjJU9wzgBlX+fttNZ5H6 AH9+1f6Tr4Z1KzLfNfBrwoq4kCgkIIvCkYl4xL+0RboFuITZuqqKwE0tA0MDMh6X uAKSkB7WsXrVbKpYVfppD9Z2blKmJ80gLvOWkuiptoe9mI/EhmfnzlwdGYzcp+80 A3ovAI7JADCQNYQjaVST1nudVy0nUGua957JKgry6P/GM83nj1p7krIKs0FzQtly pG6tyuLySFKFyhfdZ3jkpi/fJwrffDgXVrT2yXh4hljTaHd5ym6WjFrHcnoBdLLx 895jZhaFh65rBpLpq1yYa4yoO0+J0MKTRy5qDEgzZoq6Y5TjagEk3tKCmIF62dW7 18iv/9Dp/+6eZbTOjnN4 =UQ4G -----END PGP SIGNATURE-----

1 0

Karsten's status report July 1--31
by Karsten Loesing 03 Aug '12

03 Aug '12

Hi all, here's what I did in July. The numbers in [] are the ticket number and percentage of my total developer time in July. Best, Karsten Briefly looked into Maxmind's GeoIP database that started labeling relays as coming from the "A1 -- Anonymous Proxy" country. We'll need to fix that, or users won't be able to exclude relays by country, and our country-based usage statistics will deteriorate. We switched back to the May database for now, but that's only a short-term solution. [#6266, 2%] Made the consensus-health script print out diffs of recommended version sets. [#6261, 1%] Fixed a problem with Tomcat running out of memory on the metrics server, which was related to Java's leap second bug. [#6270, 2%] Looked up the number of crypto operations on a typical relay for designing a hardware Tor device. [#6369, 5%] Started converting the first five old tech reports to a common Tor Tech Report format. Zack was really helpful here by writing an improved LaTeX template and tweaking the existing reports. [#5405, 8%] Helped delber write a Python script to compute statistics about current relays. This script is the second really useful front-end for the Onionoo service. [#6329, 12%] Extracted probabilities of relays to be selected for a given position in order to add more graphs to Onionoo. The next step will be to extend Atlas to display the new graph data. [#5755, 31%] Helped Sathya write a script to extract data on network entropy and degree of anonymity over time. Ran the script on local tiny number cruncher, which kept it busy for 12 hours, and plotted graphs. [#6232, 14%] Fixed an issue with too frequent consensus-health messages reporting expiring certs. [N/A, 1%] Extracted and graphed cumulative probabilities of clients selecting among the biggest k exits. [#6443, 13%] Discussed and prepared removing GetTor statistics from all metrics codebases. [#6395, 3%] Made metrics website graph colors easier to distinguish for people with color-deficient vision. [#6463, 2%] Reviewed Walter's new interactive metrics graphs on http://tigerpa.ws/tor_metrics/ and fixed a few metrics bugs while doing so. [N/A, 6%]

1 0

We have funding for another browser hacker
by Mike Perry 02 Aug '12

02 Aug '12

Hey everyone, We're looking to add another Firefox developer to our team to help improve Tor Browser. For details on the position, experience needed, and how to apply, please see the job posting: https://www.torproject.org/about/jobs-browserhacker.html.en -- Mike Perry

1 0

[GSoC] Pluggable Transports in Python Status Update - More Transports
by Brandon Wiley 02 Aug '12

02 Aug '12

So far I've implemented Dust and obfs3 and I'm putting the finishing touches on obfs2. I've also rewritten the pluggable transport API and rewritten the transport plugins to use this new API. The API now provides 4 events: start, encodedReceived, decodedReceived, and end. The plugins implement callbacks for these events as well as an __init__(self, decodedSocket, encodedSocket) method that provides virtual sockets to the plugins. The virtual sockets have read and write methods. Control is transferred to the plugin when one of the event callbacks is called, in at which time the plugin can read and write data to the socket buffers. When the callback returns, control is transferred back to the framework, which takes care of reading and writing between the buffers and the actual sockets. The next step is testing of all of the plugins and documenting the plugin API. In particular I expect that the python obfs2 implementation will not work with the C obfs2 implementation due to undocumented assumptions in the protocol implementation, so these will need to be worked out. Code: http://github.com/blanu/pyptlib and http://github.com/blanu/py-obfsproxy Blog: http://stepthreeprivacy.org/

2 1

George's status report: July 2012
by George Kadianakis 01 Aug '12

01 Aug '12

Hi, this is a list of some Tor stuff I did during July: - Got #3589 merged in 0.2.4! - Worked with Arturo on daphn3, an OONI plugin which, given a censored TCP conversation, tries to bruteforce the fingerprint used by the DPI box [0]. Unfortunately, it's still not quite ready for real life use! - Helped around with the problem of measuring the safety of the Tor network [1]. - Helped Brandon with his GSoC project [2]. - Talked with George Danezis about anomaly detection and his automatic censorship detection tool [3]. He has many ideas on improving his current anomaly detection model but they don't seem to work well in practice. I will try to read some stuff about anomaly detection in case I can help out. Meanwhile, Philipp Winter is interested in applying a different anomaly detection model to censorship detection and seeing how well it will work. [0]: https://speakerdeck.com/u/hellais/p/ooni-and-daphn3 [1]: https://blog.torproject.org/blog/research-problem-measuring-safety-tor-netw… https://trac.torproject.org/projects/tor/ticket/6460 [2]: http://stepthreeprivacy.org/ [3]: https://lists.torproject.org/pipermail/tor-dev/2011-September/002923.html https://trac.torproject.org/projects/tor/ticket/6067 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-censorship-events

1 0

How to best support tor 0.2.3.x in Tor Browser Bundle?
by Mike Perry 01 Aug '12

01 Aug '12

Quick recap from #tor-dev IRC convo with Nick, Roger, and Andrew: We need to get a usable tor 0.2.3.x-rc bundle out RSN so we can declare it "stable", but there are concerns that using Firefox 14 with this will continue to cause unexpected problems and otherwise scare people away from testing tor 0.2.3.x enough. However, I still need to have a place to commit TBB-alpha patches, and have three bugfixes (including a fix for a FF14 crash bug that was discovered by tor-qa) that I'd like to get into the alpha series. Also, if we don't provide Firefox Rapid Release with regular alpha testing, we're going to be really, really sad when everything breaks at once in November with the next Firefox ESR. One option is to create a temporary "rc" branch of torbrowser.git's maint-2.2 to build tor 0.2.3.x but with the rest of a "TBB stable" bundle with Vidalia 0.2.x and Firefox 10.x ESR, and leave maint-2.3 as "TBB alpha". A second option is to create a more permanent "TBB beta" series, with whatever software smells like it is getting close to stable at a given point in time. A third option is to just keep doing English-only maint-2.3 builds back-to-back until tor-qa stops reporting crash bugs or strange issues. However, we need input from Erinn to decide the best approach. If the "rc" fork (or a permanent beta branch) messes up the build process or introduces issues with build automation work, perhaps it is not the right way to go, and we should just keep doing english-only maint-2.3 releases back-to-back until FF14 is more stable (Note: it works OK for me now in my test builds with the crash fix applied). So Erinn, which one is least painful for you? Also, does anyone else have any other input or suggestions on how to approach this problem? We're probably going to run into this issue periodically due to our different components stabilizing at different points... -- Mike Perry

4 4

TorExport with Unit Tests
by Erik I Islo 01 Aug '12

01 Aug '12

Hello, I have created a ticket on Trac that links to the code on my github, which is ready for a code review. This includes both TorExport (stem/descriptor/export.py) which has already received a quick review and the unit tests (test/unit/descriptor/export.py). The ticket (#6512) can be found at https://trac.torproject.org/projects/tor/ticket/6512. -Erik & Megan

1 0

[GSoC] Vidalia Report - Week 10
by Feroze Naina 01 Aug '12

01 Aug '12

Hello there, I have completed the hidden services plugin. I rewrote the hidden service widget as a qwidget subclass and implemented functionality to browse for the hidden service directory. I spent the last week testing the plugin and fixing up port sanity check and UI issues. I have squashed the commits and pushed it to https://github.com/feroze/vidalia-plugins/tree/hiddenservice. It is currently awaiting being merged into the vidalia-plugins repo. I'm working on the bandwidth scheduler's tablewidget UI to allow drag selection similar to uTorrent's (http://imgur.com/a/LLZdI)

1 0

[Stegotorus] chop server to client handshake and the url dictionary
by vmon 31 Jul '12

31 Jul '12

Hey Zack, I'm working on changing how client sends info to the server for ApachePayloadServer, according to our discussion. This is how it's going to be for now. The server sends a list of file in some order to the client at the begining of the conversation. The client will send its coded request by chosing a url a from the list and a parameter that it sends to that file such as: /groups/watch.cgi?param=QTwFt25 For this I need to send the list of files somewhere to the client. I looked at the paper and paper says that on a new link the server will send a reply to the handshake of the client with ECDH data. I thought there would be a good place to send these data as well. Unfortunately I couldn't spot that in the code. Could you please tell me where that is happening? Another option is to assign an opcode to this operation, and when the client receive that opcode then, it will process the packet differntly rather than just write its content in upstream event buffer. For now I suppose that the client has the list and write the code from that point till you give me more info. Cheers, vmon

2 1

Trip Report: Defcon
by Damian Johnson 31 Jul '12

31 Jul '12

Hi all. When tor developers go on trips we commonly write a trip report afterward. My recent trip to Defcon didn't contain anything sekrit so sending the notes I took here. If any of these presentations sound interesting to you then videos should be available later on the Defcon site. Cheers! -Damian PS. I was new to many of the things being presented so my notes quite likely have some inaccuracies. Don't quote me on anything - watch it for yourself if interested. tl;dr Only presentations related to the privacy field were... * Can You Track Me Now? Panel discussion on mobile GPS tracking with lots of interesting stats. * Crypto and the Cops EFF presentation on the 5th amendment protections and how it applies to compulsory decryption. ======================================== Las Vegas is... an unusual city. Like most people I knew I wasn't in Kansas any more when I saw slot machines in the airport. By day the city's not much to look at. Mostly just a bunch of dusty buildings baking in the 110 degree desert heat. But by night the whole city illuminates in neon lights making it quite a spectacle. My first night I explored the strip and several of the larger casinos including Bally's, Bellagio, Caesar's Palace, and the Rio where the conference was taking place. They were... enormous. Caesar's in particular took me almost a half hour simply to walk the length of it. Probably my favorite sight was the Bellagio fountains which had a magnificent water show choreographed to 'Singing in the Rain'. It was very classy. ======================================== The second day was the first of the conference and mostly consisted of two things: standing in line a couple hours for registration and introductory talks. The talks were just a single track and included... * Wireless Security: Breaking Wireless Encryption Keys Handshake process for WPA, WEP, and WEP2 among other things. I was still sorting out the material that I got during registration so I didn't pay very close attention which was a pity since I could use a refresher. * Intro to Forensics: Tools & Tactics A very brief introduction to nmap, tcpdump, netcat, ntop, and Metasploit. Nothing new to me here though it was a nice reminder that I know less about them than I'd like. I haven't played with them since grad school and should try them again when I get home... * Cerebral Source Code Presentation on social engineering. Sadly missed a large part of this one since I still hadn't had breakfast. The QA portion that I saw was fun, mostly questions about how he'd extricate himself from various sticky situations. His answers were clever, as well as entertaining. My favorite... Q: What would it take to have more trust in this community? A: LSD? * DC101: Defcon Survival This was a panel discussion with general advice for enjoying Defcon. Mostly it boiled down to 'you get what you put in' which caught me a little off guard. I came here expecting to watch some talks, see Vegas, and schmooze with other conference attendees. Defcon, however, aims to be a lot more interactive than that and the organizers put a lot of effort into events that weave throughout the conference. * HF Skiddies suck, don't be one. Learn some basic Python. This one made me twitch. The speaker both gave a very bad tutorial for getting started with python (who the hell fires up *Eclipse* every time they want to write python?!?) and seemed to be incoherently drunk for most of it. Mostly I spent this time reading the program. * Hacking the Hackers: How Firm is Your Foundation This was a long checklist of various topics the speaker thought the Defcon audience should know about, largely focused on hardware hacking since that was his specialty. Interestingly 'TOR' was the first thing he listed. I always wondered how that spelling persists despite our efforts to stamp it out. Considering that this conference had roughly 20,000 attendees, each of whom will pass it along I guess now I know... * Fun with the Lockpicking Village A few years back I read the MIT guide to lockpicking and spent a couple days practicing against my door. Since then I've fallen out of practice and this was a nice reminder about both the basics and a few things that I didn't know (how bump keys work, defeating deadlatches, how to use a can of compressed air to defeat magnetic locks that allow egress traffic, etc). The hallway track wasn't anything too notable. Met three developers with Metasploit and someone from the security group I attended at WSU. But that was about it. ======================================== Second day of the conference I ran into someone from Amazon Infosec. A talk I wanted to attend concerning the attack surface of near field communication (NFC) devices was full, but several of the others were interesting... * Can You Track Me Now? This was my favorite presentation of the whole conference. A panel of four presenters, including Chris Soghoian, discussed geolocational privacy of mobile devices including local threats, historical information, and requests for real time tracking. Why does this matter, you ask? Because when it takes a team of agents to track your every step surveillance is costly. But when a single agent can track you and your every acquaintance from the comfort of his desk we get a whole lot closer to a 1984 style surveillance state real fast. Sprint now has a department of 200 people to service wiretapping requests. They also provide a self-service portal to law enforcement that has been used six to seven hundred thousand times a year, for 8 million GPS coordinates. This includes your every move going back 6 months to 2 years depending on your provider. 7 years in the case of AT&T. And no, none of this requires probable cause or a warrant. In other words, beware if your ex is a cop. Another eye opening bit of the talk was phone encryption. Apple has a master skeleton key for all iPhone devices so, when requested, they can send law enforcement a DVD with all the contents of your phone. Android is a little different in that they remotely reset your password to something that they can give the law enforcement agent. Beside three letter agencies, ad networks and apps are also a concern. 47 of the top 100 mobile applications send locational information to 3rd parties. For instance, 'Best Alarm Clock' sends locational information in the clear to 3rd parties whenever the app is used (somehow I doubt they need to do that for the alarm clock to function...). On a policy front one slight glimmer of hope comes from a recent case which ruled that placing a GPS tracking device on your car *does* constitute a search and hence requires a warrant (which means they kinda sorta need evidence of wrongdoing, *gasp*!). Don't read too much into this, though. The majority opinion ruled this way because it technically constituted trespassing on your property. Just because you're paranoid doesn't mean they're *not* out to get you... * Crypto and the Cops Marcia Hofmann from the EFF discussed 5th amendment protections and how they apply to being compelled to reveal your passphrase for an encrypted device. There have been five cases in this area so far, some that ruled each way in terms of compulsory decryption. Though not intuitive, the main determining factor in those cases constituted a gap in knowledge. If law enforcement knows exactly what they're looking for and where it is then there's less chance of the amendment applying than if the search is a fishing expedition. Moral of the presentation: never volunteer information, even if you're innocent. Ask for a lawyer first. * Making Sense of Static Walkthrough of GPS signal acquisition, mostly focusing on how receivers account for Doppler shift and determine the code phase. The speakers also presented libswiftnav, an open source implementation of a GPS receiver system. * Life Inside the Skinner Box Cautionary presentation about the automation of law enforcement and where it might someday lead. This was pretty high level, discussing the societal implications. * Anti-Forensics and Anti-Anti-Forensics Discussion by a forensic examiner of several tricks that can draw out the length of an investigation (and by extension cost, increasing the chance of settlement). He also covered how they can be mitigated. Some of them included... - using a non-standard RAID configuration - randomizing file crated/modified timestamps - altering file header types - using restricted windows filenames (CON, PRN, AUX, etc) - owning lots 'o media - modifying files provided with your system so the checksums no longer match what a default install would include (and hence adds to the haystack of things to sift through) Before heading back for dinner I also caught part of a Skytalk. I didn't find the presentation to be too interesting (brainstorming about mass data aggregation), but I got a chuckle from the sign on the door: "Absolutely no cameras allowed. Violaters will be violated violently." :P ======================================== I had less luck on the third day of the conference, hopping between several talks that weren't particularly interesting. The best I found were... * World War 3.0 - Chaos, Control, the Battle of the Net Policy talk about Dubai's upcoming WCIT negotiations (aka, the thing that's gonna politicize the Internet). Most of the presentation was surprisingly fluffy, the only interesting bit coming from Dan Kaminsky who made the point that there's generally four interests involved... - privacy - security - anti-piracy - sovereignty ... with 'reliability' being the golden goose that no one wants to cook. His point was simply that these four camps war and forge alliances, privacy and security for instance sometimes at odds over anonymity but thick as thieves on other obvious fronts. He also said something like "We have made a system optimized for moving pictures of cats. And it's *really* good at it. Though we'd like it to do more." (likely horribly misquoted) * Exploit Archeology: Raiders of the Lost Payphone Step by step process of reverse engineering and reprogramming an Exetel payphone. Twenty year old software from a company that imploded without a trace long, long ago. Ye gods each step turned out to be a trek to Mt. Doom and back... * Off Grid Communication with Android Mesh network by introducing a transparent proxy after going through the Java networking interface. He wrote something based on the 'Wi-Fi Tether for Root Users' app to put his phones into ad-hoc mode then tried both the OLSR and BATMAN proactive routing protocols. He also tried a reactive protocol that broadcasts messages, then left routing decisions to the receiver which can trivially pick the shortest path though this had issues scaling above 200 devices or so. * Back Ops My favorite talk of the day, given by Dan Kaminsky. It was originally slated for two hours, but got crunched at the last minute into a one hour slot so he went pretty fast over five different topics including... - Timing Attacks Attacks can distinguish 15-100 ms deltas over the Internet and 100 nanoseconds over a LAN. Making everything take an identical amount of time is generally unrealistic since it forces everything to worst case performance. His view was not to let the perfect be the enemy of the good, and simply introduce random delay into requests. - Bad Random Number Generation First a rant that for twenty years security engineers have worried about entropy sources, yet we still haven't gotten it right. The common sources of entropy are: hardware RNG, keyboards, mouse, and disk rotation. However... most servers don't have any of these, especially with the move to virtual storage devices. Roughly 1/200 keys on the Internet are poorly generated, and he proposed using idiosyncrasies in clock timing as an alternative source of randomness. - Security Aspects of Languages Starting with the question 'why is PHP so damn popular?', he discussed why secure coding practices like prepared statements often aren't followed. His conclusion: SDEs are in charge and they just want their service to work. The more of a pita security makes itself the more it'll be viewed as an obstruction and hence circumvented. He then proposed more usable security patterns, for instance making the languages smart enough to translate queries like "SELECT name FROM users WHERE username=$id" into the proper prepared statement counterpart. - Censorship Detection After a brief mention of OONI-Probe he discussed a censorship detection method of his via the use of favicons. I saw this in an earlier presentation of his and he mostly skimmed through it. - Vulnerability Scanning Trying to answer the question of 'how much of the Internet is vulnerable to X', he used *stateless* TCP connections to scan hosts far quicker than he usually could. The trick was to skip retaining any information about outbound connections, making fire-and-forget TCP handshakes and leaving it to the other end to remember the state of the connection. ======================================== I didn't expect much from the lineup on the last day, but some of them were surprisingly good. I also ran into a couple more people from Amazon and Runa very briefly. * SIGINT and Traffic Analysis for the Rest of Us Very good talk on APCO Project 25 (P25), two way radio communication used by police, fire departments, federal enforcement, the secret service, and the DoD. A drop-in replacement for analog FM, this was first introduced in the early 1990s. It can optionally be encrypted, with federal/DoD users commonly enabling it and police/fire leaving it off. If you see an earpiece or bulky walki-talky then this is what it's probably using. The speaker discussed several vulnerabilities in P25. Firstly, it uses a forward correcting protocol that is easy to jam. Usually a jammer needs to be stronger than the signal it's jamming, but with P25 it's sufficient to selectively block a message's header to cause the rest of the message to be ignored. How hard is this, you ask? To cheaply jam a P25 signal you just need a $15 GirlTech IMME toy (it cost less to buy the toy than the transmitter that comes in it). As an added bonus it comes in pink or purple and comes with ponies on the box! Second, P25 has no notion of authentication. Anyone can transmit and user ids can be trivially spoofed. The user id of transmitters are sent in the clear, even when encryption is enabled. Third, any P25 device that receives a malformed signal will reply with the user id (again, in cleartext). This is invisible to the user and means that you can ping all P25 devices and triangulate their positions. Think of it as the "Marauder's Map" for the secret service. Fourth, P25 is a narrow band radio broadcast (12.5 Khz) which is fairly easy to intercept via a scanner (such as an Icom R-2500). This makes encryption a must for private communications. However, the encryption of P25 devices has several usability issues... - Encryption is enabled or disabled via a switch on the handset. The only indication of if encryption is enabled or not is a "1" or "(/)" symbol on the handset. Which means 'encrypted' and which means 'cleartext' is evidently a common point of confusion. - The beep that the device makes to indicate that it's in encrypted mode is the same that's used to indicate a low battery among other things. - Encryption is transparent to the receiver, so if an individual in a group is broadcasting in cleartext then it's impossible for anyone else in the group to know and correct them. - Rekeyed P25 devices become incompatible while being rekeyed, forcing users to drop to cleartext if any of the devices haven't yet been updated. As a result, about 30 minutes per day of federal communications are sent in the clear. In a multi-city study on what this included researchers were able to gather the names of informants, license places of vehicles being tailed, etc. These snippets were also enough to reasonably figure out what investigations were going on at a given time. When brought up with the federal field offices encryption rates improved for a week or so, then dropped back to their prior ratio of cleartext. The researchers also discussed these with the manufacturers, who insisted that it wasn't their fault if their users couldn't properly use their devices. Btw, the only federal service to have a spotless record in terms of encrypting their communications? The US Postal Service. * SCADA Strangelove or: How I Learned to Start Worrying and Love the Nuclear Plants This was a talk on the security of SCADA HMI software (or lack thereof), which is used throughout several minor things like nuclear power plants. Originally to prevent plant operators from installing pong on the kiosks, HMI applications hasn't evolved much since those humble origins. This talk was funny as hell, going over issues with several widely deployed HMI systems... - Microsoft Bob: Early attempt at a friendly, 'helpful' interface. If you made three incorrect password attempts you got a dialog saying "I see you forgot your password. Please enter a new one here...". It also stores passwords in plaintext. - InvisiLink: Stored passwords are an xor with a static key. What is that key, you ask? "0123456789" - KingView: Passwords simply have their last byte subtracted from 0xff. - Iconies Genesis32 9.2.2: The login dialog includes a 'challenge code' that can be used as an alternative method of getting local admin access. To use this code the user is supposed to call customer service, who then provides the password corresponding with the code. Alternatively, you can take the first eight characters of the challenge code's md4 hash to do the same. There were also a couple talks on 'firesheep inspired' frontends for various exploits. The first did NTLM relaying against Windows corporate networks to allow for a variety of not-so-nice things like reading through another person's Exchange inbox. The second was a UI to automatically ARP poison a network then use sslstrip to snag credentials. I felt a little embarrassed for the speakers in this talk since they first tried to sensationalize what sslstrip could do. After that they claimed to have a stealthy MITM, then described the noisiest attack I can think of. Not only did they ARP poison the network and do SSL downgrading, but they did a nmap scan of every host on the network and, just for added stealthyness, blocked all tunneling protocols (ssh/vpn). The later was on the theory that "they'll just use the local network instead". Uggg. So more annoying push-button solutions for script kiddies. Yay. ======================================== Ending conclusions: Fun and interesting conference, but *damn* vegas is pricey. The trip was 1.5k and only $200 of that was the conference registration. I enjoyed it and it was a good thing to do at least once, but way too costly to do again.

1 0

Re: [tor-dev] Def Con Kaminsky talk (censorship detection)
by David Fifield 31 Jul '12

31 Jul '12

Dan replies: On Mon, Jul 30, 2012 at 11:33:09AM -0700, Dan Kaminsky wrote: > Basically, if you spoof HTTP or HTTPS headers from a Flash socket to your own > IP, with someone else's Host/SNI, a transparent proxy is going to send its > interposing content to the Flash SWF and not to the browser. It's a really > deployable way to see nasty stuff. > > One warning is that if hijacking is DNS based, and not transparent proxy based, > you don't see anything with this stunt (though favicon.ico detection still > works). > > On Mon, Jul 30, 2012 at 10:57 AM, David Fifield <david(a)bamsoftware.com> wrote: > > I saw an interesting talk by Dan Kaminsky at Def Con that touched on > some ideas for censorship detection. He mentioned OONI-probe and talked > about his project CensorSweeper. It tests blockedness of web sites by > making cross-domain requests for favicon.ico and displaying them in a > minesweeper-like grid. > > http://www.censorsweeper.com/ > https://www.hackerleague.org/hackathons/wsj-data-transparency-code-a-thon/ > hacks/censorsweeper > > He also mentioned something, which unfortunately I didn't follow very > closely, about using Flash sockets to spoof HTTP and HTTPS headers. I > think the gag here was sending these spoofed connections to a server you > control (so you can answer the crossdomain policy requests without which > Flash Player will refuse to connect), but you give it a Host header of a > censored site or something like that. > > http://miriku.com/wp/2012/07/decon-day-3/comment-page-1/#comment-1416 > > Unfortunately I don't have the conference DVD which presumably contains > the slides he used, but videos usually show up online after some number > of months. > > David Fifield > >

1 0

bridge's lifetime
by ??Phoenixing 31 Jul '12

31 Jul '12

hi </:includetail> I have get more than 1000 bridges and I totally inserted into the torrc file. So I can not notice which bridge is no longer work. The bridges can not be blocked totally. Some bridges seem that no longer work, but after sometime (three days or more) they work again.:-)</:includetail> </:includetail> best regards</:includetail> </:includetail> </:includetail>

2 1

introduction and progress toward an interactive version of a Tor metrics website
by Walter Kim 31 Jul '12

31 Jul '12

Hi Everyone, I'm a mathematician/coder/visualization person living in San Francisco. I've been in contact with Karsten Loesing about making more interactive graphs for the tor metrics website. I've made some progress which can be viewed here: http://tigerpa.ws/tor_metrics/ You can select a region in the bottom graph to set the time domain of the top graph. You can click on the buttons on the right to add lines to the graph. It's still a work in progress, so there are still bugs and I've open to suggestions on making it better. Currently it only shows graphs for network/relays data. I'm planning on adding the ability to view graphs for all the other data on the current tor metrics site. The code lives here: https://github.com/tigerpaws/tor_metrics Thanks, Walter -- Walter Kim, Ph.D. Mathematician and Engineering Contractor, San Francisco +1-415-509-1429 (mobile) wltr.km(a)gmail.com

2 3

Def Con Kaminsky talk (censorship detection)
by David Fifield 30 Jul '12

30 Jul '12

I saw an interesting talk by Dan Kaminsky at Def Con that touched on some ideas for censorship detection. He mentioned OONI-probe and talked about his project CensorSweeper. It tests blockedness of web sites by making cross-domain requests for favicon.ico and displaying them in a minesweeper-like grid. http://www.censorsweeper.com/ https://www.hackerleague.org/hackathons/wsj-data-transparency-code-a-thon/h… He also mentioned something, which unfortunately I didn't follow very closely, about using Flash sockets to spoof HTTP and HTTPS headers. I think the gag here was sending these spoofed connections to a server you control (so you can answer the crossdomain policy requests without which Flash Player will refuse to connect), but you give it a Host header of a censored site or something like that. http://miriku.com/wp/2012/07/decon-day-3/comment-page-1/#comment-1416 Unfortunately I don't have the conference DVD which presumably contains the slides he used, but videos usually show up online after some number of months. David Fifield

1 0

Brainstorming about steganographic transports
by David Fifield 29 Jul '12

29 Jul '12

This is a summary of some discussion among developers of pluggable transports about steganographic channels and deriving them from protocol grammars. Two things prompted the discussion: * A program called appid, http://code.google.com/p/appid/ , which compiles simple protocol specifications into big regular expressions and uses them to classify network streams. Supported protocols are https://code.google.com/p/appid/source/browse/trunk/apps ; a sample is https://code.google.com/p/appid/source/browse/trunk/apps/afs . Roger suggested to make a program that takes one of these specifications and embeds data within a stream that appid will classify as the chosen protocol. * This paper: "Provably Secure Steganography" http://www-users.cs.umn.edu/~hopper/tc-stego.pdf The authors define a "channel" as a probability distribution on sequences. You can think of a channel as something that answers "given this prior history of packets, what are the possible next packets and their probabilities?" or even as an oracle that merely allows sampling this distribution. They show a method of steganographically encoding a bit within a channel such that that a passive adversary cannot distinguish it from "normal" traffic (Sec. 4.1 and Fig. 1). For the topics we were talking about, the most important sections to read are 2 and 4.1. You can embed data in a string that will match a given regular expression by constructing a DFA (http://swtch.com/~rsc/regexp/regexp1.html) and walking it state by state, choosing state transition edges so as to encode something. For example, if there are two outgoing edges from a state, which one you choose can encode a bit. Many of the appid signatures contain any* blocks that can straightforwardly encode bytes. An example of this idea is the regular expression /^(ab*[cd])+/. The b* lets us encode one bit (say "" = 0 and "b" = 1), and the choice of c or d allows another bit ("c" = 0 and "d = 1). We could send the message 00110001 as "acabdacad". This idea can really be thought of an application of the paper. A regular expression defines a probabilistic channel if we assign probabilties to edge transitions, which we may do uniformly. So, for example, with the regular expression given above, the first byte is 'a' with probability 1. The second byte is 'b' with probability 0.5, 'c' with probability 0.25, and 'c' with probability 0.25. But we see how a channel is sensitive to history: if the string so far is "ab", then the next byte may be 'c' or 'd'; but if the string so far is "ac", then the next byte must be 'a' (or EOF). We can use appid-like signatures to make steganographic channels, if we assume that the signatures are a realistic reflection of actual use of the protocols. But: this relies critically on the accuracy of the model. (Specifically, does it match the censor's model? If he uses simple regular expressions for blocking, then we win; if not, then we probably lose.) Robert Ransom gave the example of a model of HTTP using just the syntax; i.e. using RFC 2616 as the definition of a channel. Such a thing would not only not look like real-world HTTP, but would be broken easily by proxies that rearrange headers, for example. rransom also suggested a way to use arithmetic encoding to obfuscate a stream using a probabilistic model of a protocol; I'll quote him in part: * send it through an arithmetic-code encoder, using a model which contains a (low-probability) 'pad' symbol; * encrypt it with a stream cipher; * send it through an arithmetic-code decoder, using a model which matches the 'cover protocol' (the protocol you are trying to mimic). David (yours truly) wants to write or help write a simple pluggable transport derived from regular-expression signatures, even with the limitations shown above. Client and relay would need matching signature models. For the same of simplicity, it will only seek to match the given signature, and not be indistinguishable in the strong sense mentioned above. It won't do symmetric encryption of the underlying TLS (or if it does, will use a fixed key). It won't use the constructions from the Provably Secure Steganography paper, rather it will just encode its stream directly in DFA edge transitions. I think it will be interesting to see 1) how far a simple system can get us, and 2) what additional changes we would have to make to be provably secure against censors using more sophisticated computational models than regex. David Fifield

4 3