- tor-dev - lists.torproject.org

Python TorCtl development questions
by Sean Robinson 12 Jun '11

12 Jun '11

I have begun using the Python TorCtl package to develop a gui TOR controller. So, I am looking at the TorCtl source to understand how to use it properly. In this examination, I have begun adding comments, renaming vars to be more explicit, etc. How open are the developers to these changes? Will the devs accept patches to remove unused code. I'm looking at you, TorCtl.TorUtil.Enum. Is there interest in making TorCtl into a more mainstream form of Python package? See https://trac.torproject.org/projects/tor/ticket/2585 How far back in Python versions are we trying to maintain compatibility? As an example: TorCtl.TorUtil.Callable seems to be used to create static methods, but the staticmethod function to do this was added in Py2.2 (Dec 2001) and the @staticmethod decorator form was added in Py2.4 (Nov 2004). And thank you for TorCtl, it certainly saved me time not to have to implement a protocol engine from scratch. -- Sean Robinson WiFi Radar - http://wifi-radar.berlios.de Python WiFi - http://pythonwifi.wikispot.org pymnl - http://pymnl.wikispot.org

2 3

Will people running a relay be blocked from accessing CN destinations?
by tagnaq 11 Jun '11

11 Jun '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Ian, I made a new thread to avoid this discussion in the 'The Torouter and the DreamPlug' thread. > On Thu, Jun 09, 2011 at 11:47:10PM +0200, tagnaq wrote: >>> > > Doesn't "make random people into public (middle-only) relays" have the >>> > > (well maybe not "problem", but "issue"?) that when GFW blocks them, they >>> > > (the random people who bought an Excito/etc.) won't be able to connect >>> > > to anything in .cn any more? Although I don't _often_ connect to .cn >>> > > domains, it seems unfortunate to effectively auto-ban these people from >>> > > Chinese websites. >> > >> > I did not experience any problems connecting to .cn while using a relay >> > IP address. I think they are just blocking an IP:port combination and >> > not the entire IP address. >> > ...but things might change > Hmm. I wonder what happens if the packets are fragmented so that the > TCP port information isn't in the first fragment... possibilities: a) a fragmented IP packet doesn't get blocked b) they don't allow IP fragmentation (Don't Framgent Bit set) c) their firewall is able to find out whether the fragment is part of a blocked destination (IP:port) -----BEGIN PGP SIGNATURE----- iF4EAREKAAYFAk3znv4ACgkQyM26BSNOM7ZB5QD+J7p1OSqD7uopViiigmop84sp nlzbSV6dqK2ZvT+PrbUA/i2hLQKHkYZfVUQqTp4hu2o9bp5GbHsNylNP6l1lKByB =aKCK -----END PGP SIGNATURE-----

4 6

The Torouter and the DreamPlug
by Runa A. Sandvik 11 Jun '11

11 Jun '11

Hi everyone, DreamPlug is a new plug computer from GlobalScale Technologies: http://www.globalscaletechnologies.com/c-5-dreamplugs.aspx. The spec looks good, it runs Ubuntu by default and it doesn't cost too much. I thought that the DreamPlug was going to be very user friendly and a potential candidate for the Torouter project. (Maybe) I was wrong. When the SheevaPlug came out a couple of years ago, it shipped with a web interface that enabled users to change various network options. I thought the DreamPlug would ship with some kind of interface as well (and my plan was to just plug in a Tor page). This is not the case; it ships with lighthttpd by default and displays a static and very simple placeholder page on 192.168.1.1. If we want to use the DreamPlug for the Torouter, we will have to write a web interface for easy configuration of Tor. The interface should probably also provide options to better secure the DreamPlug. Downloading and installing Tor isn't a problem, but the configuration side of things can be tricky for users who aren't used to the command line. Thoughts? Comments? Thanks, -- Runa A. Sandvik

14 44

Too many cooks spoil the broth---or: how about we clean up the wiki?
by Karsten Loesing 11 Jun '11

11 Jun '11

Hello everyone, <rant>Today I looked at our wiki to add roadmaps for some products and realized what a mess the wiki is. This wasn't obvious to me, because I stopped using the wiki long ago, well, because it was such a mess. But boy, it has become worse!</rant> I think the main problem is that there's no obvious structure in the wiki, so everyone just adds their stuff anywhere, maybe thinking that someone else will move it to the right place. The other problem is that there's no such person cleaning up. Here's my plan: I'd like to rename (possibly a lot of) wiki pages so that the naming scheme implies a kind of wiki structure. I'd also add a page saying where stuff should go, and we'll beat up everyone not adhering to the structure in a joint effort. By the way, what happens if we rename wiki pages? I guess Trac will update all internal links, but external links (e.g., from the website) will be broken? We could fix our own website, but other websites would still be broken. How bad would that be? Here's a suggested naming scheme. In this scheme, there are three top-level directories (or rather, page prefixes): - doc/ contains all documentation for Tor users, relay operators, and the community in general. This is the stuff that people would usually expect in a wiki. - org/ contains deliverables promised to our sponsors, meeting plans, product roadmaps, project progress, etc. This stuff is in the wiki to make Tor development as transparent as possible. In theory, non-developers wouldn't require write permissions to these pages. - trac/ contains Trac's own documentation that it generously dumped into our Tor wiki. In theory, nobody would require write permissions to these pages. I'll go through the existing wiki pages and say where they should go. The following pages would move to doc/ (e.g., "DNS Hijacking" would become "doc/DNS Hijacking"): DNS Hijacking HTTPSEverywhere/SSLObservatorySubmission ImportantGoogleChromeBugs OnionCat TorALaymansGuide TorFAQUnanswered TorInChroot TorToggle UsingTorWithVservers badRelays badRelays/trotskyIps talks talks/MoscowState2010 TheOnionRouter TheOnionRouter/AnonymousPublicSpeech TheOnionRouter/BIND TheOnionRouter/BandwidthLimitChangeController TheOnionRouter/BlockNonTorTrafficDebian TheOnionRouter/BlockingDiagnostics TheOnionRouter/BlockingIrc TheOnionRouter/CentralizedTorServer TheOnionRouter/ConnectOverSSH TheOnionRouter/ContestEntries TheOnionRouter/ContestEntries/DesignFeedback TheOnionRouter/CronBandwidthLimit TheOnionRouter/DebianLive TheOnionRouter/EmbeddedTips TheOnionRouter/ExitEnclave TheOnionRouter/FAQUnanswered TheOnionRouter/FireFoxTorPerf TheOnionRouter/FirefoxRemoteDNS TheOnionRouter/GoodBadISPs TheOnionRouter/Gsoc2009 TheOnionRouter/Gsoc2009/ThandyTorrents TheOnionRouter/HiddenServiceNames TheOnionRouter/HowTo_post_on_or-talk_mailinglist TheOnionRouter/LegalStuff TheOnionRouter/LiveCDBestPractices TheOnionRouter/MacOSXUpgradeToTrunk TheOnionRouter/OpenbsdChrootedTor TheOnionRouter/OpenbsdChrootedTorControlScript TheOnionRouter/OpenbsdChrootedTorScript TheOnionRouter/OperationalSecurity TheOnionRouter/Portable_Tor TheOnionRouter/PreventingDnsLeaksInTor TheOnionRouter/Preventing_Tor_DNS_Leaks TheOnionRouter/PrivoxyConfig TheOnionRouter/PrivoxyPatches TheOnionRouter/Publicfile TheOnionRouter/ReducedExitPolicy TheOnionRouter/RemailingAndTor TheOnionRouter/RunTwoPrivoxys TheOnionRouter/SshPortForwardedTor TheOnionRouter/SummerOfCode TheOnionRouter/SupportPrograms TheOnionRouter/SupportPrograms/Polipo TheOnionRouter/TSocksPatches TheOnionRouter/TermsObserved TheOnionRouter/TorAbuseTemplates TheOnionRouter/TorExitNodeHowto TheOnionRouter/TorGuideUniversities TheOnionRouter/TorInChroot TheOnionRouter/TorInChroot-new TheOnionRouter/TorInTheMedia TheOnionRouter/TorMirror TheOnionRouter/TorOnDebian/PackagesForArchitectures TheOnionRouter/TorShirt TheOnionRouter/TorWin32TorWS TheOnionRouter/TorALaymansGuide TheOnionRouter/TorDNSExitList TheOnionRouter/TorFAQ TheOnionRouter/TorIPCOP TheOnionRouter/TorifyHOWTO TheOnionRouter/TorifyHOWTO/EMail TheOnionRouter/TorifyHOWTO/FTP TheOnionRouter/TorifyHOWTO/InstantMessaging TheOnionRouter/TorifyHOWTO/IrcSilc TheOnionRouter/TorifyHOWTO/Misc TheOnionRouter/TorifyHOWTO/Misc/Putty TheOnionRouter/TorifyHOWTO/Putty TheOnionRouter/TorifyHOWTO/SystracePolicy TheOnionRouter/TorifyHOWTO/WebBrowsers TheOnionRouter/Torouter TheOnionRouter/Torouter_notes TheOnionRouter/Torwin32DNS TheOnionRouter/Transocks TheOnionRouter/TransocksifyingTor TheOnionRouter/TransparentProxy TheOnionRouter/VMWareThroughTor TheOnionRouter/VerifyingSignatures TheOnionRouter/WebProxyHowto TheOnionRouter/Wikipedia TheOnionRouter/WindowsBufferProblems CodingForTor CodingForTor/CodingInC CodingForTor/CodingInR CodingForTor/LoggingAndDocumentation CodingInC CoreTorTracUsers build build/AddingBuildSlaves build/BuildSignoff build/ListOfPackages dev/HowToReleaseTor dev/SupportPolicy dev/SupportPolicy_v2 The following pages would move to org/meetings/: 2010TorAnnualDevMeeting 2011MiniDevMeeting 2011MiniDevMeeting/notes 2011StockholmHackfest 2011TorAnnualDevMeeting The product roadmaps that are not there yet would go into org/roadmaps/. Everything related to project management would go into org/projects/: TorAgileProcess projects/HowWeDoProjectManagement projects/ProjMgt/SetUpProjectMgt Products projects/ProductsandAssignments projects projects/2009FinancialandComplianceAudit projects/BridgeDB projects/CalculateDirreqShares projects/EmailAutoResponder projects/ExperimentalBridgeBundles projects/Infrastructure projects/Metrics projects/Metrics/DesignAndDeployDescriptorDatabase projects/Metrics/ImproveMetricsPortal projects/Metrics/PublishMetricsDataAndTools projects/Metrics/SafelyCountClients projects/Thandy projects/Tor projects/TorBrowserBundle projects/TorBrowserBundle/Alpha projects/TorBrowserBundle/OSX projects/TorBrowserBundle/OSX/Security projects/TorBulkExitlist projects/TorButton projects/TorCheck projects/TorFlow projects/TorStatus projects/Tor/MultithreadedCrypto projects/Weather projects/arm projects/mirror projects/mirror/torrent projects/vidalia The deliverables promised to our sponsors would go into org/sponsors/: sponsors sponsors/SponsorA sponsors/SponsorB sponsors/SponsorD sponsors/SponsorD/December2010 sponsors/SponsorD/June2011 sponsors/SponsorD/March2011 sponsors/SponsorD/September2010 sponsors/SponsorE sponsors/SponsorE/PhaseOne sponsors/SponsorF sponsors/SponsorF/Year1 And finally, the following pages are about using Trac and would go into trac/ (it's possible that Trac wouldn't like us renaming some of its pages, but I guess we'll find out): InterTrac InterWiki RecentChanges TitleIndex TracAccessibility TracAdmin TracBackup TracBrowser TracCgi TracChangeset TracEnvironment TracFastCgi TracFineGrainedPermissions TracGuide TracImport TracIni TracInstall TracInterfaceCustomization TracLinks TracLogging TracModPython TracModWSGI TracNavigation TracNotification TracPermissions TracPlugins TracQuery TracReports TracRevisionLog TracRoadmap TracRss TracSearch TracStandalone TracSupport TracSyntaxColoring TracTickets TracTicketsCustomFields TracTimeline TracUnicode TracUpgrade TracWiki TracWorkflow WikiDeletePage WikiFormatting WikiHtml WikiMacros WikiNewPage WikiPageNames WikiProcessors WikiRestructuredText WikiRestructuredTextLinks WikiStart That's it. I realize there are lots of cooks on this list, so I expect there will be feedback. Thanks, Karsten

4 8

Re: [tor-dev] Tor and BGP integration
by Arturo 09 Jun '11

09 Jun '11

Hello, This seems to me like a really neat idea! Reading from real time BGP feeds is not a simple task and I think it might be a bit of an overhead for the average Tor user. On the other hand it could be a good idea to have some nodes run tools to generate exit policies or at least provide BGP routing information in a easy to consume format for the tor clients to use. I have been doing some experimenting on getting and analysing BGP information and these are the resources that I have found useful: - http://archive.routeviews.org/ - For getting raw MRT format BGP feeds and also the output of `bgp show ip` - http://www-01.pch.net/resources/data/routing-tables/archive/2011/ - Routing information from other "probes" - https://github.com/hellais/PyRT - A quick patch I made to make PyRT work on python > 2.3 (useful for parsing MRT format files), original: https://research.sprintlabs.com/pyrt/ IXPs: - http://www.pch.net/resources/data/routing-tables/looking-glass/ - https://www.peeringdb.com/private/index.php - Very complete database on peers and ASN information. They also provide a very nice API for interacting with their database. I have been working on some python code for adding BGP support to blockfinder. It basically just parses the results of the `bgp show ip` command outputs obtainable from route views and stores the routing paths inside a database. It needs to be cleaned up a bit, but if you are interested in using it I can hack on it some more. Let me know of the progress you make :) - Arturo `hellais` > Hello from Iceland, > > Linus invited me to Reykjavik to talk about Tor at the NORDUnet conference > and this idea is the result of a bit of feedback from some network operators > here. > > Tor needs a way to be friendly to large network operators who wish to enable > exiting to anonymous communication for their networks. These network > operators are happy to allow anyone to pass traffic to their relays as entry > nodes, middle nodes and even limited exit nodes. > > Linus and I have been discussing methods of automating this process and of > course BGP integration makes a lot of sense. Generally, a network operator > has a set of AS numbers for their network blocks and as they want people to > connect to many of their services, it helps quite a bit to allow exiting to > those services from their own Tor relays. > > We came up with two main ideas for making this happen. > > One method would be to write a program where given an AS number and a BGP > feed, we parse all of the advertised network blocks and emit exit policy > lines that accepts all traffic for the AS. This would allow for a web > service similar to BulkExitList.py for network aware exit policy generation > and relay operators would simply need to add this to their Tor configs > manually. For mostly static networks, a cronjob would be fine and Tor > doesn't need to know about AS numbers internally. > > Another method would be to write a controller that watches for BGP network > updates and Tor would add relevant exit policy lines for any configured AS. > This would allow any Tor relay to dynamically learn about network changes if > it has access to a BGP feed patched into a controller. This could be > implemented by adding some configuration options to Tor that let Tor know > which AS numbers matter to which router. It may also allow for the router to > auto learn it's own likely family network but it lacks any kind of > bi-directional confirmation, still it seems useful information to have... > > It would be fantastic if someone offered a hidden service NORDUNet BGPMon > feed. This would help enable the first method of generating network aware > exit policies; this would also help with the development of AS awareness in > Tor itself. In the future, I imagine that it makes a lot of sense for > circuit building to be BGP aware as mere netblocks will not be very useful > in an ipv6 world, they're already mostly irrelevant. > > Anyway, food for thought. Linus and I will probably hack on some of these > ideas in the near future. > > All the best, > Jake

1 0

[Patch] common/procmon.c
by Gisle Vanem 02 Jun '11

02 Jun '11

Hi list! I've been staring at this file for some time trying to find the elusive compile-error (MingW-gcc v4.50) on Win_XP). The bug was a missing comma (!) and a typo ('err_msg' at line 277 changed to 'err_msg'). I've also changed the format for 'err_code' at line 293 into a "%ld" to suppress a warning. How did this go unnoticed for ~1 month? --- Git-latest\src\common\procmon.c Thu May 26 19:30:24 2011 +++ common/procmon.c Tue May 31 22:54:14 2011 @@ -252,7 +252,7 @@ if (!GetExitCodeProcess(procmon->hproc, &exit_code)) { char *errmsg = format_win32_error(GetLastError()); log_warn(procmon->log_domain, "Error \"%s\" occurred while polling " - "handle for monitored process %d; assuming it's dead." + "handle for monitored process %d; assuming it's dead.", errmsg, procmon->pid); tor_free(errmsg); its_dead_jim = 1; @@ -287,12 +287,12 @@ if (!its_dead_jim) log_info(procmon->log_domain, "Failed to open handle to monitored " - "process %d, and error code %d (%s) is not 'invalid " + "process %d, and error code %lu (%s) is not 'invalid " "parameter' -- assuming the process is still alive.", procmon->pid, - err_code, err_msg); + err_code, errmsg); - tor_free(err_msg); + tor_free(errmsg); } } #else ------------- Sorry, no git patch. I'm a git newbie. Gisle V.

2 1

[PATCH] Signed-off-by: Gisle <gvanem@broadpark.no>
by Gisle 01 Jun '11

01 Jun '11

An elusive compile-error (MingW-gcc v4.50 on Win_XP); a missing comma (!) and a typo ('err_msg' at line 277 changed to 'errmsg'). Aso changed the format for 'err_code' at line 293 into a "%ld" to suppress a warning. How did this go unnoticed for ~1 month? Btw. This is my 1st ever 'git commit', so it better work. --- src/common/procmon.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/src/common/procmon.c b/src/common/procmon.c index 8fcc1af..5c10e9a 100644 --- a/src/common/procmon.c +++ b/src/common/procmon.c @@ -252,7 +252,7 @@ tor_process_monitor_poll_cb(evutil_socket_t unused1, short unused2, if (!GetExitCodeProcess(procmon->hproc, &exit_code)) { char *errmsg = format_win32_error(GetLastError()); log_warn(procmon->log_domain, "Error \"%s\" occurred while polling " - "handle for monitored process %d; assuming it's dead." + "handle for monitored process %d; assuming it's dead.", errmsg, procmon->pid); tor_free(errmsg); its_dead_jim = 1; @@ -287,12 +287,12 @@ tor_process_monitor_poll_cb(evutil_socket_t unused1, short unused2, if (!its_dead_jim) log_info(procmon->log_domain, "Failed to open handle to monitored " - "process %d, and error code %d (%s) is not 'invalid " + "process %d, and error code %lu (%s) is not 'invalid " "parameter' -- assuming the process is still alive.", procmon->pid, - err_code, err_msg); + err_code, errmsg); - tor_free(err_msg); + tor_free(errmsg); } } #else -- 1.7.0.2.msysgit.0

2 1

Control-port circuit event/status format
by Robert Ransom 01 Jun '11

01 Jun '11

Subject: Control-port circuit event/status format Will any Tor controllers that I should care about break if I modify Tor to report a ‘CANNIBALIZED’ circuit event to all controllers that send ‘SETEVENTS CIRC’ to Tor? Will any Tor controllers that I should care about break if I modify Tor to report a ‘CANNIBALIZED’ circuit state in response to a ‘GETINFO circuit-status’ control-port command? Robert Ransom

1 0

Code Review (arm) - Initial commit for the menu code
by Damian Johnson 28 May '11

28 May '11

Hi all. Kamran and I are gonna doing code reviews publicly so if you're interested and spot issues we miss then feel free to chime in. -Damian Change: https://gitweb.torproject.org/user/krkhan/arm.git/commitdiff/5fd9b5f74a86eb… > ARM_CONTROLLER = Controller(stdscr, stickyPanels, pagePanels, menu) What sort of persistent state will the menu require? If we can make it a popup function (like "showHelpPopup()") that would be preferable (less parameter juggling). But if you expect it to remember something between menu requests then this makes sense. > menu.draw() Maybe rename this to "showMenu()"? The draw method is part of panel which threw me off a bit. > self._rootEntry = (entry and isinstance(entry, ParentEntry)) and entry or DEFAULT_ROOT Interesting pattern, but it's kinda hard to read (or make sense of unless you've seen it before). Maybe something a little less compact would be clearer? if entry and isinstance(entry, ParentEntry): self._rootEntry = entry else: self._rootEntry = DEFAULT_ROOT > titles = map(attrgetter('title'), self._rootEntry.children) This took me a couple minutes with the interactive interpretor to make sense of too. Maybe list comprehension instead of the attrgetter would help? titles = [menuItem.title for menuItem in self._rootEntry.children] > titlewidth = max(map(lambda title: len(title), titles)) + 2 Neat. Honestly I'm greener than I should be with lamdas. The pattern I'd use for this is... titlewidth = max([len(entry) for entry in titles]) + 2 but up to you. The later is more familiar to me but I'm not sure which can claim the best readability. > # total number of titles that can be printed in current width Why are you giving all titles equal distance? Does this make it look better? I'd assume that would be best to have dynamic widths, leaving some entries unprinted if we run out of room (this is done all around so I can get you an example if you'd like). I'm thrilled you're taking variable screen sizes into account! > titleformat = curses.A_NORMAL > > if index == self._selection[0]: > titleformat = curses.A_STANDOUT Alternative option... titleformat = curses.A_STANDOUT if index == self._selection[0] else curses.A_NORMAL > popup.win.addch(top, left, curses.ACS_VLINE) > popup.win.addstr(top, left, entry.title.center(titlewidth), titleformat) > popup.win.addch(top, left, curses.ACS_VLINE) Noooooooo! Don't do this! If you can help it _never_ draw to the raw curses window. If this ever attempts to draw outside the curses window it will crash. The panel class has safe proxies for everything that you should need. In this case... popup.addch(top, left, curses.ACS_VLINE) popup.addstr(top, left, entry.title.center(titlewidth), titleformat) popup.addch(top, left, curses.ACS_VLINE) will do the same. There's, of course, exceptions like popup.win.box() and popup.win.refresh() (those are safe). > DEFAULT_ROOT = ParentEntry(title="Root", children=( I've been defining constants outside of classes so they can be easier to spot at the top of files. However, this is just a stylistic preference of mine - if you prefer constants to be a class attribute then that's fine. > for index in self._selection: > if isinstance(entry, ParentEntry): > entry = entry.children[index] > else: > break > > if isinstance(entry, LeafEntry): > entry.callback(entry) It looks like if self._selection is an invalid path you do nothing? Maybe we should log something or raise an exception... Your usage of named tuples and index lists will, I think, make this harder and more confusing than it needs to be. Instead I'd suggest a MenuItem class that has... getLabel() -> text for the option isLeaf() -> boolean for if we're a leaf or not getSubmenu() -> returns a list of MenuItems below it - either an empty list or None if a leaf node (whatever makes most sense to you) getParent() -> parent MenuItem next(), prev() -> returns a MenuItem instance for the next or previous option for the menu list we're in select() -> event handler Constructing the menu will be a little more interesting, but rendering it, navigation, and selection will all become trivial. It'll also avoid the situation where _selection is out of sync with _rootEntry (for that matter, we wouldn't need a rootEntry...).

2 2

was my LDAP account ever setup?
by Nathan Freitas 25 May '11

25 May '11

Seems like this ticket is still open: https://trac.torproject.org/projects/tor/ticket/3068 and I am problems like this: git remote add public ssh://git-rw.torproject.org/n8fr8/orbot git push public master Permission denied (publickey). fatal: The remote end hung up unexpectedly thx!

1 0

Re: [tor-dev] arm - new identity ...
by Damian Johnson 23 May '11

23 May '11

Hi Dominik. Sounds good, we should keep this simple (at least for the first version) so lets go with #2 and #3. Developing this should be pretty straight forward... 1. Add "sendNewnym", "isNewnymAvailable", and "getNewnymWait" methods to 'src/util/torTools.py'. All of these should be very easy. 2. Add a handler for sending a newnym in 'src/cli/headerPanel.py'. This is done by overwriting the "handleKey(self, key)" method - for an example see just about any of the other panels. I'm currently working on another feature for the header panel (reattaching to tor instances) so there might be a handler here by the time you start. I'm fine with F5. From the curses documentation it sounds like you can compare the keycode to the curses.KEY_F5 constant. 3. Adding the newnym to the header panel - this will be the hardest part (but still not too difficult). This will only be visible when we're a non-relay, and involves filling in... https://gitweb.torproject.org/arm.git/blob/HEAD:/src/cli/headerPanel.py#l259 Normally this could say something like "Press F5 for a new identity", then after they send a newnym instead display "Building circuits (newnym signal unavailable for X seconds)". 4. Coordinate with Kamran for the menu option. Maybe we want to somehow make it disabled while sending a newnym is unavailable? > - mumble with krkhan (and you?) I'm looking forward to it. We should be able to set this up next week. Cheers! -Damian On Mon, May 23, 2011 at 7:04 AM, dominik <d.schuetzdeller(a)gmx.de> wrote: > hello atagar, > im sorry for not sending this email yesterday. my vserver hoster has reset > the wrong vserver and caused some trouble =( > ... anyway > > i had 3 ideas realizing this: > 1. build a new "page" > that page should contain possibilities for adding nodes to use (entry or > bridges, relay and exit). it should also contain > some informations about flags from that nodes; especially if that node is > a known bad node. there should also be a > new identity button. > 2. implement it within the menues krkhan is working on > as i now heard krkhan is working on a menu, what would be the best and > user friendliest way for implementing the > stuff in there and create some masks for the according informations to be > put in there. > 3. using a hotkey for some things like "new identity" > first of all i thought about using the "f5"-button as a hotkey for using > new circuits. i like the idea of using the same hotkey > as it is used in the browser. > that new identity thing how ever needs to have a check whether the node > where it runs on is a client or some other thing. > > ok... before you are going to ask how i am going further - this is what my > todo list says: > - delete torsh from monitoring programs in the thesis > - describe whether there is a magical setup for nagios for ~6 different > nodes or not ... > - describe and edit features for arm > - search an elegant way for recreating a new circuit in pytorctl > - mumble with krkhan (and you?) > - based on the things said i am going to begin implementations (from > saturday on fulltime) > > after all my decision of working on arm after my thesis still is the same... > even if python3 has a weird utf8 handling. > i will also work on torsh as a fun project > > best regards > dominik > > > > > > >

1 0

Re: [tor-dev] [tor-commits] [tor/maint-0.2.2] The first argument for a libevent callback should be evutil_socket_t
by Robert Ransom 23 May '11

23 May '11

On Mon, 23 May 2011 05:18:07 +0000 (UTC) nickm(a)torproject.org wrote: > commit 1e69c60dccc358a7146c2b5e7825ea729498b41b > Author: Nick Mathewson <nickm(a)torproject.org> > Date: Mon May 23 01:12:00 2011 -0400 > > The first argument for a libevent callback should be evutil_socket_t > --- > src/common/procmon.c | 5 +++-- > 1 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/src/common/procmon.c b/src/common/procmon.c > index cee956a..bd25bc1 100644 > --- a/src/common/procmon.c > +++ b/src/common/procmon.c > @@ -34,7 +34,7 @@ typedef int pid_t; > /* Currently we need to poll in some way on all systems. */ > > #ifdef PROCMON_POLLS > -static void tor_process_monitor_poll_cb(int unused1, short unused2, > +static void tor_process_monitor_poll_cb(evutil_socket_t unused1, short unused2, > void *procmon_); This will break the build on libevent 1.x systems (until you merge your bug3270 branch that #defines evutil_socket_t on such systems). Robert Ransom

1 0

Tor meets real users
by Andrew Lewman 19 May '11

19 May '11

A short while ago, I did a training for some activists from a country that is hostile to the Internet. These people were some of the more technical people from their community. There was a mix of Windows and OS X laptops in the session. English was their third language, for added fun. I walked them through finding tor browser bundle, downloading it, verifying it, unzipping it, and starting it. Here was the first problem. They couldn't find tbb on the download page. Their comments were that all these files and releases on the page were confusing. They wanted just one thing to look at, pick their operating system, and go. And they wanted the one thing to automatically detect their language preferences for tbb. I ended up pointing them at tpo/torbrowser, which they also thought was confusing. The aforementioned desires weren't satisfied on this page, but at least they could find their preferred language. They all commented that back home, a 24MB file was too big, and can't they get it via bittorrent or some other piecemeal way? A 24mb file would take hours to download. Once they finally downloaded it, they all double clicked on their resulting zip file. In fact, all of the mac people ended up downloading the windows tbb and unzipped it correctly. In all cases, their operating system handled the zip file correctly. After fixing the mac people with mac tbb, we moved on to the next step. None of them had pgp installed, and therefore no way to verify the .asc and zip file. Most of them figured out to click inside the resulting folder and start the 'start tor browser' program. For all of the macs, the tbb didn't start. The people had to restart the system and then clicking on 'start tor browser' worked as expected. As tbb was starting up, nearly all of them clicked on 'start tor browser' one to three times more, because they didn't see anything starting up. In fact, it was starting, it just wasn't instantaneous. I worry about forcing a splash screen that announces "I'm using Tor!" on the screen, but at the same time, it would let users know that tbb is starting. Once vidalia started, no one waited for tbb firefox to start, but rather started their own browser and tried to use it. Once tbb firefox started up, in some cases, minutes later, they were confused. Why didn't tbb firefox start right away instead of this useless vidalia control panel? A few of them felt the need to explore the vidalia control panel since we showed it to them. As if to say, 'there are buttons you are showing me, I just click and explore.' Once tbb firefox started, they were ok with using firefox over tor just fine. The first thing many of them did was to login to facebook or gmail over tor to see if it was different. None of them verified the ssl cert presented for facebook or gmail logins. For those that did login to gmail, gchat didn't work due to the lack of Flash in tbb firefox. We then tried to configure their chat clients for tor. Adium on the mac was fairly easy. The variety of clients on windows wasn't so easy. A few wondered about logging in over ssl, but never did because the services didn't offer it (aol, msn, gchat). I showed the windows people pidgin, but they liked their native apps and didn't see why one multi-protocol app was better. The experience continued through pidgin with OTR, installing pgp for email and verifying files, and a general talk about openssl certificates, what they mean, and what verification of a cert entails. The relevant tor experience was what I wanted to communicate and for us to start thinking through ways to address it. Perhaps Mike's desire for a anonymous browser is a correct path for usability and better anonymity for the user. I believe torfox and torora have both come to the same conclusion (at different times) as well. -- Andrew pgp 0x74ED336B

6 8

May Tor proposal status, and proposal plans for 0.2.3
by Nick Mathewson 16 May '11

16 May '11

Hi, all! When Roger was at my house the week before last, we spent some time trying to triage currently open proposals for 0.2.3.x. I've spent some time revising the list of proposal statuses that I sent out in early March to reflect that conversation. Here's the current list of proposal statuses, plus a list of those that we would like to target for 0.2.3. Note that this is a *tentative* list of stuff for 0.2.3, not a final list. Given a goal of getting 0.2.3.x-stable out much more quickly than 0.2.2.x-stable, we may need to let unfinished items wait until 0.2.4. I'll be trying to work out a release schedule over the course of this week (to fit in with commitments we've made and time we have). That said, the distinction between "nice to have for 0.2.3" and "targeted for 0.2.3" is that the "targeted for 0.2.3" items are the ones I would currently consider delaying the release a little for, whereas the others would be neat to focus on, but great whenever they land. ===== FINISHED SINCE MARCH 2: These were actually implemented and merged since March 2: 158 Clients download consensus + microdescriptors 162 Publish the consensus in multiple flavors 174 Optimistic Data for Tor: Server Side [CLOSED] These ones were implemented (in full or in part) all along: 149 Using data from NETINFO cells 163 Detecting whether a connection comes from a client 166 Including Network Statistics in Extra-Info Documents These were superseded in full: 170 Configuration options regarding circuit building ===== TARGETED FOR 0.2.3 110 Avoiding infinite length circuits This proposal solves a potential DoS attack. This has been nearly completely implemented for a while. All we need to do is verify that there are no clients that do not send RELAY_EARLY cells correctly, and if so, turn on the code that drops EXTEND cells not sent via RELAY_EARLY. The hard part here is double-checking that all the clients that send EXTEND commands inside non-RELAY_EARLY cells are really and truly obsolete. 117 IPv6 exits This proposal describes how to transmit IPv6 traffic over Tor. It needs updating to work properly with microdescriptors; it also has some open questions about DNS. We should revise this to bring it up-to-date for microdescriptors and what we now know about DNS, and try to get it into 0.2.3.x. 147 Eliminate the need for v2 directories in generating v3 directories This proposal explains a way that we can phase out the vestigial use of v2 directory documents in keeping authorities well-informed enough to generating the v3 consensus. It's still correct; somebody should implement it before the v2 directory code rots any further. 157 Make certificate downloads specific This proposal added cross-certification and signing-key-specific download URLs for directory authority certificates. It is IIRC mostly implemented; there are just some SHOULDs that we should turn into MUSTS if all sufficiently old authority certificates are now obsolete. 171 Separate streams across circuits by connection metadata This proposal describes a way to prevent cross-application linking of different anonymized sessions by isolating different kinds of streams on different circuits based on their characteristics. Robert Hogan did an implementation for a much earlier version of this proposal that distinguished only based on ports; this could serve as the basis of a new proposal, or not. 176 Proposed version-3 link handshake for Tor Here's my proposal for how to improve our TLS handshake to eliminate renegotiation, become less fingerprintable, and generally make the world a better place. It needs more review by actual crypto people, but I would like to get it into 0.2.3.x. 178 Require majority of authorities to vote for consensus parameters This is a proposal for making it a little harder for a small number of authorities to influence the value of a consensus parameter. It needs more discussion; Sebastian has a draft implementation in his "safer_params" branch. 179 TLS certificate and parameter normalization Here's a proposal that describes better ways to come up with TLS parameters (including DH parameter values and X.509 cetificates) to make our protocol even harder to fingerprint. Jacob has an implementation in progress. 180 Pluggable transports for circumvention And this one is the sledgehammer of circumvention support: it describes There's Google Summer of Code student (George) planning to spend some time working on this one. ===== NICE-TO-HAVE FOR 0.2.3 118 Advertising multiple ORPorts at once This proposal describes how an OR can advertise more than one address and OR port at a time. It needs to be updated to work with microdescriptors, and to explain how much information can be transmitted in the consensus and how (the original proposal was written before consensus directories were really figured out). 140 Provide diffs between consensuses This proposal describes a way to transmit less directory traffic by sending only differences between consensuses, rather than the consensuses themselves. It is mainly languishing for lack of an appropriately licensed, well-written, very small, pure-C implementation of the "diff" and "patch" algorithms. (The good diffs seem to be GPL (which we can't use without changing Tor's license), or spaghetti code, or not easily usable as a library, or not written in C, or very large, or some combination of those.) 143 Improvements of Distributed Storage for Tor Hidden Service Descriptors Here's a proposal from Karsten about making the hidden service DHT more reliable and secure to use. It could use more discussion and analysis. 164 Reporting the status of server votes This proposal explains a way for authorities to provide a slightly more verbose document that relay operators can use to diagnose reasons that their router was or was not listed in the consensus. These documents would be like slightly more verbose versions of the authorities' votes, and would explain *why* the authority voted as it did. It wouldn't be too hard to implement, and would be a fine project for somebody who wants to get to know the directory code. 168 Reduce default circuit window This proposal reduces the default window for circuit sendme cells. I think it's implemented, isn't it? If so, we should make sure that tor-spec.txt is updated and close it. 172 GETINFO controller option for circuit information 173 GETINFO Option Expansion These would help controllers (particularly arm) provide more useful information about a running Tor process. They're accepted and some parts of 173 are even implemented: somebody just needs to implement the rest. 177 Abstaining from votes on individual flags Here's my proposal for letting authorities have opinions about some (flag,router) combinations without voting on whether _every_ router should have that flag. It's simple, and I think it's basically right. With more discussion and review, somebody could/should build it for 0.2.3.x, I think. ===== OPEN: 145 Separate "suitable as a guard" from "suitable as a new guard" Currently, the Guard flag means both "You can use this node as a guard if you need to pick a new guard" and "If this node is currently your guard, you can keep using it as a guard." This proposal tries to separate these two concepts, so that clients can stop picking a router once it is full of existing clients using it as a guard, but the clients currently on it won't all drop it. It's not clear whether this has anonymity issues, and it's not clear whether the imagined performance gains are actually worthwhile. 146 Add new flag to reflect losing-term stability From time to time we get the idea of having clients ship with a reasonably recent consensus (or a list of directory mirrors), so instead of bootstrapping from one of the authorities, they can bootstrap from a regular directory cache. The problem here is that by the time the client is run, most of the directory mirrors will be down or will have changed their IP. This proposal tries to address that. It needs analysis based on behavior of actual routers on the network to see whether it could work, and what parameters might work. 156 Tracking blocked ports on the client side This proposal provides a way for clients to learn which ports they are (and aren't) able to connect to, and connect to the ones that work. It comes with a patch, too. It also lets routers track ports that _they_ can't connect to. I'm a little unconvinced that : most clients that have some ports blocked will need bridges, not just restriction to a smaller set of ports. This could be good behind restrictive firewalls, though. The router-side part is a little iffy: routers that can't connect to each other violate one of our network topology assumptions, and even if we do want to track failed router->router connections, the routers need to be sure that they aren't fooled into trying to connect repeatedly to a series of nonexistent addresses in an attempt to make them believe that (say) they can't reach port 443. This one is a paradigmatic "open" proposal: it needs more discussion. The patch probably also needs to be ported to 0.2.3.x; it touches some code that has changed. 159 Exit Scanning This is an overview of SoaT, with some ideas for how to integrate it into Tor. 165 Easy migration for voting authority sets This is a design for how to change the set of authorities without having a flag day where the authority operators all reconfigure their authorities at once. It needs more discussion. One difficulty here is that we aren't talking much about changing the set of authorities, but that may be a chicken-and-egg issue, since changing the set is so onerous. If anybody is interested, it would be great to move the discussion ahead here. ===== DRAFT: 127 Relaying dirport requests to Tor download site / website The idea here was to make it easier to fetch and learn about Tor by making it easy for relays to automatically act as proxies to the Tor website. It needs more discussion, and there are some significant details to work out. It's not at all clear whether this is actually a good idea or not. 132 A Tor Web Service For Verifying Correct Browser Configuration This proposal was meant to give users a way to see if their browser and privoxy (yes, it was a while ago) are correctly configured by running a local webserver on 127.0.0.1. I'm not sure the status here. 133 Incorporate Unreachable ORs into the Tor Network This proposal had an idea for letting ORs that can only make outgoing connections still relay data usefully in the network. It's something we should keep in mind, and it's a pretty neat idea, but it radically changes the network topology. Anybody who wants to analyze new network topologies should definitely have a look. 141 Download server descriptors on demand The idea of this proposal was for clients to only download the consensus, and later ask nodes for their own server descriptors while building the circuit through them. It would make each circuit more time-consuming to build, but make bootstrapping much cheaper. A microdescriptor-based version of this would be even better, and microdescriptors would solve a lot of the problem that this was meant to resolve. It still is not wholly superseded by the microdescriptor system, though. 144 Increase the diversity of circuits by detecting nodes belonging the same provider This is a version of the good idea, "Let's do routing in a way that tries to keep from routing traffic through the same provider too much!" There are complex issues here that the proposal doesn't completely address, but I think it might be a fine idea for somebody to see how much more we know now than we did in 2008, particularly in light of the relevant paper(s) by Matt Edmann and Paul Syverson. 175 Automatically promoting Tor clients to nodes Here's Steven's proposal for adding a mode between "client mode" and "relay mode" for "self-test to see if you would be a good relay, and if so become one." It didn't get enough attention when it was posted to the list; more people should review it. ===== NEEDS-REVISION: 131 Help users to verify they are using Tor Here's a proposal for making a torcheck-like website more reliable. If anybody wants to pick it up (especially somebody working on torcheck) and see whether it should be reopened or rejected, that would be a fine thing. ====== "IDEAS": xxx-bwrate-algs.txt Here's a note about better round-robin calculations for rate limiting. Mike wrote it; I don't understand what's going on with it. xxx-choosing-crypto-in-tor-protocol.txt Here's the start of a considerations document that Marian was writing about how to pick new crypto algorithms to migrate to. xxx-controllers-intercept-extends.txt Here's an old idea from Geoff Goodell about letting controllers intercept EXTEND commands. It is partially superseded by Damian's 172, though there is an additional feature that doesn't make sense for the Tor network, but might make sense for experimental stuff like Geoff was working on. xxx-crypto-migration.txt Here's the document I wrote in December about which parts of our crypto there are to migrate, and what might be involved. This isn't a draft or pre-draft of a design proposal; it is more of a new category of "survey of stuff we need to design and think about", or "proposal for proposals" or something. xxx-crypto-requirements.txt Here's Robert Ransom's draft for what crypto properties, exactly, we're trying to get out of our circuit crypto. It is not a proposal draft or pre-draft: it is again a "design considerations" document, and one worth reading. xxx-draft-spec-for-TLS-normalization.txt Here's Jacob's proposal for certificate normalization. It should get renamed, given a proposal number, and called "Open" or "Draft" depending on how much the details are likely to change. xxx-encrypted-services.txt This is a start-of-a-proposal of Rogers that somebody should pick up and finish some time: The idea is to use the hidden service mechanism to provide a secure naming and encrypted connection facility for hosting sites that do not actually want anonymity themselves. There's been more interest in this topic lately. It might also turn into "exit enclaves done right". xxx-exit-scanning-outline.txt Looks like this was superseded by 159? xxx-geoip-survey-plan.txt Here's an old document I wrote a while ago about tracking usage by country. Probably it should go into the metrics documentation somewhere (if we do this), or get thrown into "old" (if we won't do this), or updated (if we might someday do this). xxx-grand-scaling-plan.txt Here are some notes on scaling that Roger wrote in 2008. There might be some smart ideas here! Have a look some time. xxx-hide-platform.txt Here's a proposal pre-draft that says we should normalize the platform string. Somebody could turn this into a proposal pretty easily. xxx-ipv6-plan.txt Here's a survey of what we need to do for IPv6 support that I started writing. It's not a proposal; it's a survey of proposal and implementation statuses. xxx-pluggable-transport.txt Here's the thing Jacob and I have been working on for pluggable obfuscation techniques. It should get turned into "Draft" status asap, if not "Open". We should finish writing the missing sections, like, yesterday. xxx-port-knocking.txt Here's a pre-proposal from Jacob about using port knocking to make bridges harder to fingerprint. This could be a good idea for somebody to do in terms of the pluggable transport spec. xxx-rate-limit-exits.txt Here are some notes of Roger's from 2008 claiming that we should rate-limit stream creation at exit nodes. It could help avoid port-scans if we do it right, but we would need to be exceedingly careful not to disrupt useful traffic. xxx-using-spdy.txt Here's a document from Steven about opportunistic use of SPDY over Tor. This should be a "Draft" proposal IMO. xxx-what-uses-sha1.txt Here's the beginnings of a survey of where Tor uses SHA1, with an eye to stopping. This really isn't a design proposal; it might fall into a new category of "issue survey" or "information" or something.

3 2

IPv6 Thoughts
by Lucky Green 16 May '11

16 May '11

I just read nickm's post on Tor IPv6 migration at https://blog.torproject.org/blog/ipv6-future-i-hear --- What needs to change Tor uses the Internet in many ways. There are three main ways that will need to change for IPv6 support, from most urgent to least urgent. Tor must allow connections from IPv6-only clients. (Currently, routers and bridges do not listen on IPv6 addresses, and can't advertise that they support IPv6 addresses, so clients can't learn that they do.) Tor must transport IPv6 traffic and IPv6-related DNS traffic. (Currently, Tor only allows BEGIN cells to ask for connections to IPv4 targets or to hostnames, and only allows RESOLVE cells to request A and PTR records.) Tor must allow nodes to connect to one another over IPv6. Allowing IPv6-only clients is the most important, since unless we do, these clients will be unable to connect to Tor at all. Next most important is to support IPv6 DNS related dependencies and exiting to IPv6 services. Finally, allowing Tor nodes to support a dual stack of both IPv4 and IPv6 for interconnection seems like a reasonable step towards a fully hybrid v4/v6 Tor network. --- One thought that may or may not be relevant to your sequence of implementation, but that you should be made aware of if you aren't already. (You may well be already be aware of it). The most important IPv6 compatibility task in Tor is that the Tor servers can accept inbound connections over IPv6. The second most important task is that Tor servers can make outbound IPv6 connections to services on the Internet. This is, and that may not be intuitive, not isomorphic with Tor clients being able to perform outbound connections to Tor servers over IPv6. Jane Tor User's laptop does, in all likelihood, not have a globally routable IP address. Instead, Jane's laptop has been assigned an RFC 1918 address by her cable modem or the NAT at the Internet cafe. It is Jane's cable modem that either does today or very soon will use an IPv6 address to communicate upstream. If the Tor server to which Jane is connecting does not support native IPv6, then Jane's provider will have to force her Tor traffic through a provider-level IPv6-to-IPv4 gateway. Some days that gateway will work well. Other days that proxy will be overloaded and won't work all that well. Both days, traffic latency will be increased unless the Tor server to which Jane connects accepts inbound IPv6. This talk by ARIN's CEO John Curran explains the issue beautifully. Watch from the 8 minute mark: http://www.youtube.com/watch?v=S3i4RRubCvI (When traffic has to be forced through a provider-level gateway out of technical necessity, obvious opportunities for easy filtering arise that I will not explore further in this post). In summary, outbound IPv6 Tor connections from end-users can wait until after Tor servers accept inbound IPv6 connections (and after exit nodes can make outbound IPv6 connections to other services). --Lucky

2 1

TorStatus
by Jan G. 15 May '11

15 May '11

Hey, im trying to port TorNetworkStatus to Ruby. I took a look at the Trac and it looks like it's project that should be done at the GSoC. https://trac.torproject.org/projects/tor/wiki/projects/TorStatus Is anyone working at this now? Greetings, J

3 2

Fairness between circuits
by Björn Scheuermann 12 May '11

12 May '11

Hi all, my group and I have recently been working on the question whether multiple circuits in Tor share the available bandwidth fairly and reasonably. What we found is: they don't. Not at all. First, we developed an analytical model for the fairness between circuits in an anonymity overlay, and thought about how to define fairness in a setting like Tor: when can the bandwidth sharing between many circuits in a complex anonymity overlay with varying available router bandwidth be called "fair"? In short: an adaptation of the max-min fairness concept does a very good job here. In order to overcome the existing fairness problems in Tor, we also developed a (surprisingly simple) mechanism which achieves max-min fairness without exchanging any additional data about the circuits between onion routers - the latter is clearly a nice trait with respect to privacy. We found that this approach goes very well with the recently proposed N23 congestion feedback scheme from the guys at Waterloo/Colorado/San Diego. We implemented Tor's scheduling mechanisms, the N23 extension, and our fairness mechanism in an event-based network simulator (ns-3). Independent from the question of inter-circuit fairness, we were able to confirm the key findings in the DefenestraTor tech report with respect to N23 based on this independent implementation. Moreover, we found that N23 does not solve the fundamental fairness problems - but N23 in combination with our fairness mechanism does an excellent job in this regard. We explain all this in much more detail in a paper: F. Tschorsch, B. Scheuermann: Tor is Unfair - and What to Do About It http://robotik.informatik.uni-wuerzburg.de/tr481.pdf We're hoping for feedback and vivid discussions - we would be really interested in bringing these mechanisms into Tor. Best regards Björn -- Prof. Dr. Björn Scheuermann Chair of Computer Science VII University of Würzburg Am Hubland, 97074 Würzburg, Germany Tel.: +49 931 31 85402 scheuermann(a)informatik.uni-wuerzburg.de http://www7.informatik.uni-wuerzburg.de

3 4

Re: [tor-dev] New paper by Goldberg, Stebila, and Ustaoglu with proposed circuit handshake
by Nick Mathewson 11 May '11

11 May '11

On Fri, May 6, 2011 at 11:12 AM, Ian Goldberg <iang(a)cs.uwaterloo.ca> wrote: > [+ Douglas, Berkant] > BTW, apologies to Berkant for misspelling his name!

1 0

regd throughput fingerprinting based attacks
by Prateek Mittal 10 May '11

10 May '11

Hi Roger, Hope things are going well. I wanted to point you to an updated version of our technical report on throughput-fingerprinting based attacks in Tor, available at https://netfiles.uiuc.edu/mittal2/www/throughput-fingerprinting.pdf. Thanks, Prateek

1 0

Orbot 1.0.5 Release Candidate
by Nathan Freitas 09 May '11

09 May '11

Based on feedback from our core test group in the Guardian Project, it seems like we have a solid new version of Orbot that includes Tor 0.2.2.25, as well as improved handling of transparent proxying. This new build also includes our own version of iptables, and proactively checks if the device has netfilter/owner support in the kernel. This should lead to overall less support requests from confused users who have "root" but still can't transproxy. We have a few UI tweaks to make, and need to make sure all of our translations are up-to-date, but otherwise, the app feels very ready to go. I invite any of you with a few spare cycles and an Android device handy to try it out if you haven't already. As this is a dev build, it is not signed by the official Tor distro key, so you will have to uninstall any existing Orbot official release. The final app we release to the market will be signed by the Tor key, and users will get an automatic "updates available" message from the Android market. https://guardianproject.info/downloads/0.2.2.25-orbot-alpha-1.0.5.20110508a… (.asc - signed by nathan(a)guardianproject.info 0xB374CBD2) If you aren't on our guardian-dev or -alpha lists, but are an Android user, then I encourage you to join, as we keep most of the day to day traffic on those lists: https://guardianproject.info/contact/ Best, Nathan

1 0

memcmp() & co. timing info disclosures?
by Marsh Ray 07 May '11

07 May '11

Greetings all, I happened to download the tor-0.2.2.25-alpha.tar.gz source yesterday and I noticed something. Apologies in advance if this has already been discussed and resolved, I did a cursory web search and didn't see anything. There are a lot of places in the code where memcmp() is called on memory buffers that look like they might contain various hashes or digests: ~/tor-0.2.2.25-alpha$ grep -r memcmp . | grep -i digest | wc -l 137 ~/tor-0.2.2.25-alpha$ grep -r memcmp . | grep -i key | wc -l 14 The built-in memcmp typically runs in time proportional to the common prefix of the two memory buffers being compared. In networked applications, this is often a significant source of timing information. Sometimes these are severe enough to result in disclosure of secret key material. A good resource for remote timing attacks is Nate Lawson's blog: http://rdist.root.org/2010/07/19/exploiting-remote-timing-attacks/ Some cases look particularly concerning. For example, in the following code 'handshake_reply' appears to be supplied by the remote party and it is compared with something called "key material". src/or/onion.c:331: if (memcmp(key_material, handshake_reply+DH_KEY_LEN, DIGEST_LEN)) { /* H(K) does *not* match. Something fishy. */ log_warn(LD_PROTOCOL,"Digest DOES NOT MATCH on onion handshake. " "Bug or attack."); goto err; } In the worst-case, the attacker could simply supply different values of handshake_reply, observe how long each takes to compare, and figure out the value of key_material statistically byte-by-byte. Perhaps this key material is never used again, or there are other reasons this timing informaion is not useful. But in general, it's very difficult to determine whether or not such a timing info disclosure represents a vulnerability or how difficult it would be to exploit. Expert programmers seem to consistently underestimate the severtiy of these weaknesses, perhaps because they are so subtle. I've just started learning about Tor so it's not possible for me to review every instance. I think the quickest and easiest solution would be to replace every usage of memcmp and str*cmp in the source with an alternate version that guarantees a constant time comparison. I'd expect this could be done with negligible performance impact, especially for short comparisons like 20-byte hash values. Regards, - Marsh

5 15

Mingw ann non-autoconf build
by Gisle Vanem 04 May '11

04 May '11

I have a question regarding src/win32/orconfig.h. I guess this hand- edited file is supposed to be used by MSVC (targeting Win32, WinCE and whatnot). Or? What prevents it from being used by e.g. MingW in a non- autoconf build? If someone (like me that doesn't want to touch autotool with a ten-feet pole) want to use this file unchanged, things like: #undef HAVE_SYS_TIME_H has to be treated specifically for MingW. E.g.: #ifndef __MINGW32__ #undef HAVE_SYS_TIME_H #endif Same goes for HAVE_UNISTD_H, HAVE_GETTTIMEOFDAY etc. BTW. Older MingW does not have gettimeofday(). I'm not sure when the function was added. So to be perfect, an "#ifndef" test should consider the __MINGW32_VERSION too. --gv For every credibility gap, there is a gullibility fill.

3 3

Moving Orbot to Git from SVN
by Nathan Freitas 02 May '11

02 May '11

Sebastian, I believe you are the one to request this of. We need this repo/path: https://svn.torproject.org/svn/projects/android/trunk/Orbot/ moved over to a repo on the git server, as soon as you can. I am also not sure of my credential status on the git server, whether they are the same as Trac and SVN or not. It should have happened a long time ago, but now GSoC 2011 is acting as a catalyst, such that we can properly have our student branch his work. Best, Nathan

2 1

Fwd: Re: [guardian-dev] ORBot Alpha, some candles, a few glasses of wine and a packet sniffer
by Nathan Freitas 28 Apr '11

28 Apr '11

fyi -------- Original Message -------- Subject: Re: [guardian-dev] ORBot Alpha, some candles, a few glasses of wine and a packet sniffer Date: Wed, 27 Apr 2011 14:49:01 -0700 From: Nathan of Guardian <nathan(a)guardianproject.info> Organization: The Guardian Project To: guardian-dev(a)lists.mayfirst.org CC: tor-dev(a)lists.torproject.org Fantastic, Manuel. Looks like we are going to need some wine over to patch this up. This type of look at how our transproxy all rules are working (or not) is long overdue. I really appreciate your effort. The first thing that comes to mind is that we are setting up the iptables rules on an app-by-app basis, using the list of user IDs we are provided by Android API calls. It is quite possible that certain subsystems are not represented in that list. There may be a better way to implement the transproxy all implementation that is more of a "everything but tor" approach. Our transproxy configuration is based on the approach outlined here: https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TransparentPro… We'll have to go through additional recommended configurations that we are not addressing in our current "all" setup, and see if they address the leakage you have found. Best, Nathan On 04/27/2011 12:40 PM, Manuel wrote: > Hi all! > > Mini-intro: Hi, I'm Manuel (aka __sporkbomb), infosec researcher from > Austria, got bored and asked Nathan if he wanted help with ORBot ;) > > Setup: Simply an open AP, a Desire HD running CM 7.0.2 and > 0.2.2.22-orbot-alpha-1.0.5.20110417a-dev plus airodump. > > Methodology: The dump was started after the tor connection (and full > transproxying) was established in order to reduce false positives. Total > dump length is around 3h15m, around 57MB of data. Of course the phone > was left idle for a quite a while, also to ensure that it didn't do > nasty untorified stuff when waking up to check mails. Afterwards, I used > Wireshark's 'Endpoints' statistics function to determine all TCP > endpoints in the dump[0] and awk'd & uniq'd the IPs out of it[1]. As the > next step, I determined which of these IPs was in my cached-consensus[2] > (somewhat ill-advised, because I compared with my laptop's > cached-consensus rather than the phone's, causing two false positives > [false non-tor nodes] that actually were nodes). I also ran a reverse > lookup on all IPs [3]. As the last step, I went through all > communication with IPs that were not found in cached-consensus[4]. > > You can find links to most of the files I produced at the end of this > mail, excluding the dump, which I can provide if requested, but would > rather not hand out publicly (mostly because of the size). > > All in all, the phone connected to 88 IPs during that time. 37 of those > were not contained in the laptop's cached-consensus, two of which were > actually legitimate nodes (according to metrics.torproject.org) that > just went down throughout the duration of the test, leaving us with 35 > non-Tor IPs. They can be categorized as follows: > > - 27 of those nodes had no other communication than multiple TCP > packets, sometimes from a few different source ports (i.e. different TCP > connections), all originating from the phone and having FIN+PSH+ACK set. > (PSH is the 'push flag', which requests that this data bypass buffers > and be handed directly to the application) > > - 4 existing connections that still transmitted data; one even contained > Market HTTP (cleartext) API requests. > > - 4 were completely unencrypted and newly established connections to > YouTube or Revision3 video servers. This one is rather bad - it seems > that the video player subsystem of Android ignores the proxy setting and > leaks everything, including DNS. I also mentioned this yesterday on > Twitter, but didn't want to post it yet without confirmation, but it's > definitely reproducible on my end. > > -------------------- > Sumup of this part: Generally solid performance, but already established > connections might pose a threat (a minor one I'd guess, however...unless > one of you can think of a scenario where that causes Bad Things to > happen?). Additionally, the video player completely ignores the proxy > setting and communicates untorified. While video streaming isn't a > strong point of Tor anyway, it's still not good...does anyone have good > contact to CyanogenMod people and can ask about that one? > > Various tidbits of slight UX annoyances plus a few suggestions: > - ORBot ignores the "Transparent proxy" setting when connecting, I > always have to enter the Settings menu, untick and re-tick "Transparent > proxying" and press back to actually cause it to be enabled. > - Related to this: Is it possible to colour-code the "Transparent > proxying {DIS,EN}ABLED" notification? The bug above might have serious > consequences, because if someone doesn't visit check.torproject.org to > assure that he/she is actually torified, chances are that he/she will > browse in clear. DISABLED and ENABLED are only three characters away > from each other, whereas a red vs green notification would probably > catch the eye. > - Install fails when installing/uncompressing tor binary > https://trac.torproject.org/projects/tor/ticket/2989 [turns out that > this is only a bug on Android<2.3, but still...see comment #1 for more > details] > - Blank semi-permanent status box > https://trac.torproject.org/projects/tor/ticket/2993 [haven't updated > this one yet; the bug actually occured only before the first reboot for > me, and one time afterwards when I had b0rked the network badly] > - ORBot vs DroidWall: Starts with 'You don't preserve my chains like you > used to :(' and ends with, if I remember correctly, ORBot flushing > iptables rules. I'll have a look at that one tomorrow (or is there > already some data on it?). > > For now, have a nice evening! > > Cheers, > > __sporkbomb > > > > > > [0] http://sporkbomb.eu/orbot/endpoints > [1] http://sporkbomb.eu/orbot/ips > [2] http://sporkbomb.eu/orbot/inconsensus (result of a grep -c - IPs > with '0' in the second field are not contained in the consensus) > [3] http://sporkbomb.eu/orbot/dig-result > [4] http://sporkbomb.eu/orbot/not-inconsensus.notes > _______________________________________________ > Guardian-dev mailing list > > Post: Guardian-dev(a)lists.mayfirst.org > List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev > > To Unsubscribe > Send email to: Guardian-dev-unsubscribe(a)lists.mayfirst.org > Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/nathan%40guardianpr… > > You are subscribed as: nathan(a)guardianproject.info _______________________________________________ Guardian-dev mailing list Post: Guardian-dev(a)lists.mayfirst.org List info: https://lists.mayfirst.org/mailman/listinfo/guardian-dev To Unsubscribe Send email to: Guardian-dev-unsubscribe(a)lists.mayfirst.org Or visit: https://lists.mayfirst.org/mailman/options/guardian-dev/nathan%40guardianpr… You are subscribed as: nathan(a)guardianproject.info

3 2

GSoC - Torbutton for Thunderbird
by tagnaq 20 Apr '11

20 Apr '11

Hi, this is a reply to: https://lists.torproject.org/pipermail/tor-dev/2011-April/002551.html (I was not on the list at that point in time.) I wanted to let you know that I'm also researching in this area, but my goal is not to build an extension and I'm not involved in GsoC. I'm looking into issues that would negatively affect the pseudonymous use of Thunderbird with Tor. (Application level concerns when using Thunderbird with Tor) As a side effect I'm also playing around with Thunderbird/Lanikai. The outcome of my research (~08/2011) is hopefully useful to those actually implementing stuff. best regards, tagnaq

1 0