Blogs

Reading links, 7 May edition

Just some quick links to what interests us over the past week.

GSoC 2011 Projects

We're pleased to announce that the Tor Project, Tails, and Guardian are hosting students this year as part of Google Summer of Code. Out of the 31 applications to us we were able to take on six fantastic students:
 

Projects officially begin on May 23rd. We're thrilled to have them with us, and have our fingers crossed that they'll stay afterward to become core developers.
 
Many thanks to Google for having the program again this year! -Damian

New Tor Browser Bundles (and other packaging updates)

Tor 0.2.2.25-alpha is out and there are the usual packaging updates. You can go right to the download page to update.

The alpha Vidalia bundles have also been updated with the latest Torbutton 1.3.3-alpha which has itself been updated to work with the latest Firefox 4.0.1 release and has this notable feature:

When used with Firefox 4 or the alpha Tor Browser Bundles, it also
features support for youtube videos in HTML5, but you must currently
opt-in for youtube to provide you with HTML5 video as opposed to
flash: http://www.youtube.com/html5

Tor Browser Bundle changelogs follow.

Firefox 3.6 Tor Browser Bundles

Tor Browser Bundle for Windows

1.3.24: Released 2011-04-30

  • Update Firefox to 3.6.17
  • Update Libevent to 2.0.10-stable
  • Update zlib to 1.2.5
  • Update OpenSSL to 1.0.0d

Tor Browser Bundle for Linux
1.1.8: Released 2011-04-30

  • Update Tor to 0.2.2.25-alpha
  • Update Firefox to 3.6.17

Tor Browser Bundle for OS X
1.0.16: Released 2011-04-30

  • Update Tor to 0.2.2.25-alpha
  • Update Firefox to 3.6.17

Firefox 4 Tor Browser Bundles

Tor Browser Bundle (2.2.25-1) alpha; suite=all

  • Update Tor to 0.2.2.25-alpha
  • Update Firefox to 4.0.1
  • Update Torbutton to 1.3.3-alpha
  • Update BetterPrivacy to 1.50
  • Update NoScript to 2.1.0.3

Temporary direct download links for Firefox 4 bundles:

Tor 0.2.2.25-alpha is out

Tor 0.2.2.25-alpha fixes many bugs: hidden service clients are more
robust, routers no longer overreport their bandwidth, Win7 should crash
a little less, and NEWNYM (as used by Vidalia's "new identity" button)
now prevents hidden service-related activity from being linkable. It
provides more information to Vidalia so you can see if your bridge is
working. Also, 0.2.2.25-alpha revamps the Entry/Exit/ExcludeNodes and
StrictNodes configuration options to make them more reliable, more
understandable, and more regularly applied. If you use those options,
please see the revised documentation for them in the manual page.

https://www.torproject.org/download/download

Major bugfixes:

  • Relays were publishing grossly inflated bandwidth values because
    they were writing their state files wrong--now they write the
    correct value. Also, resume reading bandwidth history from the
    state file correctly. Fixes bug 2704; bugfix on 0.2.2.23-alpha.
  • Improve hidden service robustness: When we find that we have
    extended a hidden service's introduction circuit to a relay not
    listed as an introduction point in the HS descriptor we currently
    have, retry with an introduction point from the current
    descriptor. Previously we would just give up. Fixes bugs 1024 and
    1930; bugfix on 0.2.0.10-alpha.
  • Clients now stop trying to use an exit node associated with a given
    destination by TrackHostExits if they fail to reach that exit node.
    Fixes bug 2999. Bugfix on 0.2.0.20-rc.
  • Fix crash bug on platforms where gmtime and localtime can return
    NULL. Windows 7 users were running into this one. Fixes part of bug
    2077. Bugfix on all versions of Tor. Found by boboper.

Security and stability fixes:

  • Don't double-free a parsable, but invalid, microdescriptor, even if
    it is followed in the blob we're parsing by an unparsable
    microdescriptor. Fixes an issue reported in a comment on bug 2954.
    Bugfix on 0.2.2.6-alpha; fix by "cypherpunks".
  • If the Nickname configuration option isn't given, Tor would pick a
    nickname based on the local hostname as the nickname for a relay.
    Because nicknames are not very important in today's Tor and the
    "Unnamed" nickname has been implemented, this is now problematic
    behavior: It leaks information about the hostname without being
    useful at all. Fixes bug 2979; bugfix on 0.1.2.2-alpha, which
    introduced the Unnamed nickname. Reported by tagnaq.
  • Fix an uncommon assertion failure when running with DNSPort under
    heavy load. Fixes bug 2933; bugfix on 0.2.0.1-alpha.
  • Avoid linkability based on cached hidden service descriptors: forget
    all hidden service descriptors cached as a client when processing a
    SIGNAL NEWNYM command. Fixes bug 3000; bugfix on 0.0.6.

Major features:

  • Export GeoIP information on bridge usage to controllers even if we
    have not yet been running for 24 hours. Now Vidalia bridge operators
    can get more accurate and immediate feedback about their
    contributions to the network.

Major features and bugfixes (node selection):

  • Revise and reconcile the meaning of the ExitNodes, EntryNodes,
    ExcludeEntryNodes, ExcludeExitNodes, ExcludeNodes, and StrictNodes
    options. Previously, we had been ambiguous in describing what
    counted as an "exit" node, and what operations exactly "StrictNodes
    0" would permit. This created confusion when people saw nodes built
    through unexpected circuits, and made it hard to tell real bugs from
    surprises. Now the intended behavior is:
    • "Exit", in the context of ExitNodes and ExcludeExitNodes, means
      a node that delivers user traffic outside the Tor network.
    • "Entry", in the context of EntryNodes, means a node used as the
      first hop of a multihop circuit. It doesn't include direct
      connections to directory servers.
    • "ExcludeNodes" applies to all nodes.
    • "StrictNodes" changes the behavior of ExcludeNodes only. When
      StrictNodes is set, Tor should avoid all nodes listed in
      ExcludeNodes, even when it will make user requests fail. When
      StrictNodes is *not* set, then Tor should follow ExcludeNodes
      whenever it can, except when it must use an excluded node to
      perform self-tests, connect to a hidden service, provide a
      hidden service, fulfill a .exit request, upload directory
      information, or fetch directory information.

    Collectively, the changes to implement the behavior fix bug 1090.

  • ExcludeNodes now takes precedence over EntryNodes and ExitNodes: if
    a node is listed in both, it's treated as excluded.
  • ExcludeNodes now applies to directory nodes -- as a preference if
    StrictNodes is 0, or an absolute requirement if StrictNodes is 1.
    Don't exclude all the directory authorities and set StrictNodes to 1
    unless you really want your Tor to break.
  • ExcludeNodes and ExcludeExitNodes now override exit enclaving.
  • ExcludeExitNodes now overrides .exit requests.
  • We don't use bridges listed in ExcludeNodes.
  • When StrictNodes is 1:
    • We now apply ExcludeNodes to hidden service introduction points
      and to rendezvous points selected by hidden service users. This
      can make your hidden service less reliable: use it with caution!
    • If we have used ExcludeNodes on ourself, do not try relay
      reachability self-tests.
    • If we have excluded all the directory authorities, we will not
      even try to upload our descriptor if we're a relay.
    • Do not honor .exit requests to an excluded node.
  • Remove a misfeature that caused us to ignore the Fast/Stable flags
    when ExitNodes is set. Bugfix on 0.2.2.7-alpha.
  • When the set of permitted nodes changes, we now remove any mappings
    introduced via TrackExitHosts to now-excluded nodes. Bugfix on
    0.1.0.1-rc.
  • We never cannibalize a circuit that had excluded nodes on it, even
    if StrictNodes is 0. Bugfix on 0.1.0.1-rc.
  • Revert a change where we would be laxer about attaching streams to
    circuits than when building the circuits. This was meant to prevent
    a set of bugs where streams were never attachable, but our improved
    code here should make this unnecessary. Bugfix on 0.2.2.7-alpha.
  • Keep track of how many times we launch a new circuit to handle a
    given stream. Too many launches could indicate an inconsistency
    between our "launch a circuit to handle this stream" logic and our
    "attach this stream to one of the available circuits" logic.
  • Improve log messages related to excluded nodes.

Minor bugfixes:

  • Fix a spurious warning when moving from a short month to a long
    month on relays with month-based BandwidthAccounting. Bugfix on
    0.2.2.17-alpha; fixes bug 3020.
  • When a client finds that an origin circuit has run out of 16-bit
    stream IDs, we now mark it as unusable for new streams. Previously,
    we would try to close the entire circuit. Bugfix on 0.0.6.
  • Add a forgotten cast that caused a compile warning on OS X 10.6.
    Bugfix on 0.2.2.24-alpha.
  • Be more careful about reporting the correct error from a failed
    connect() system call. Under some circumstances, it was possible to
    look at an incorrect value for errno when sending the end reason.
    Bugfix on 0.1.0.1-rc.
  • Correctly handle an "impossible" overflow cases in connection byte
    counting, where we write or read more than 4GB on an edge connection
    in a single second. Bugfix on 0.1.2.8-beta.
  • Correct the warning displayed when a rendezvous descriptor exceeds
    the maximum size. Fixes bug 2750; bugfix on 0.2.1.5-alpha. Found by
    John Brooks.
  • Clients and hidden services now use HSDir-flagged relays for hidden
    service descriptor downloads and uploads even if the relays have no
    DirPort set and the client has disabled TunnelDirConns. This will
    eventually allow us to give the HSDir flag to relays with no
    DirPort. Fixes bug 2722; bugfix on 0.2.1.6-alpha.
  • Downgrade "no current certificates known for authority" message from
    Notice to Info. Fixes bug 2899; bugfix on 0.2.0.10-alpha.
  • Make the SIGNAL DUMP control-port command work on FreeBSD. Fixes bug
    2917. Bugfix on 0.1.1.1-alpha.
  • Only limit the lengths of single HS descriptors, even when multiple
    HS descriptors are published to an HSDir relay in a single POST
    operation. Fixes bug 2948; bugfix on 0.2.1.5-alpha. Found by hsdir.
  • Write the current time into the LastWritten line in our state file,
    rather than the time from the previous write attempt. Also, stop
    trying to use a time of -1 in our log statements. Fixes bug 3039;
    bugfix on 0.2.2.14-alpha.
  • Be more consistent in our treatment of file system paths. "~" should
    get expanded to the user's home directory in the Log config option.
    Fixes bug 2971; bugfix on 0.2.0.1-alpha, which introduced the
    feature for the -f and --DataDirectory options.

Minor features:

  • Make sure every relay writes a state file at least every 12 hours.
    Previously, a relay could go for weeks without writing its state
    file, and on a crash could lose its bandwidth history, capacity
    estimates, client country statistics, and so on. Addresses bug 3012.
  • Send END_STREAM_REASON_NOROUTE in response to EHOSTUNREACH errors.
    Clients before 0.2.1.27 didn't handle NOROUTE correctly, but such
    clients are already deprecated because of security bugs.
  • Don't allow v0 hidden service authorities to act as clients.
    Required by fix for bug 3000.
  • Ignore SIGNAL NEWNYM commands on relay-only Tor instances. Required
    by fix for bug 3000.
  • Ensure that no empty [dirreq-](read|write)-history lines are added
    to an extrainfo document. Implements ticket 2497.

Code simplification and refactoring:

  • Remove workaround code to handle directory responses from servers
    that had bug 539 (they would send HTTP status 503 responses _and_
    send a body too). Since only server versions before
    0.2.0.16-alpha/0.1.2.19 were affected, there is no longer reason to
    keep the workaround in place.
  • Remove the old 'fuzzy time' logic. It was supposed to be used for
    handling calculations where we have a known amount of clock skew and
    an allowed amount of unknown skew. But we only used it in three
    places, and we never adjusted the known/unknown skew values. This is
    still something we might want to do someday, but if we do, we'll
    want to do it differently.
  • Avoid signed/unsigned comparisons by making SIZE_T_CEILING unsigned.
    None of the cases where we did this before were wrong, but by making
    this change we avoid warnings. Fixes bug 2475; bugfix on 0.2.1.28.
  • Use GetTempDir to find the proper temporary directory location on
    Windows when generating temporary files for the unit tests. Patch by
    Gisle Vanem.

To Toggle, or not to Toggle: The End of Torbutton

In a random bar about two years ago, a Google Chrome developer asked me why Torbutton didn't just launch a new, clean Firefox profile/instance to deal with the tremendous number of state separation issues. Simply by virtue of him asking me this question, I realized how much better off Chrome was by implementing Incognito Mode this way and how much simpler it must have been for them overall (though they did not/do not deal with anywhere near as many issues as Torbutton does)...

So I took a deep breath, and explained how the original use model of Torbutton and my initial ignorance at the size of the problem had led me through a series of incremental improvements to address the state isolation issue one item at a time. Since the toggle model was present at the beginning of this vision quest, it was present at the end.

I realized at that same instant that in hindsight, this decision was monumentally stupid, and that I had been working harder, not smarter. However, I thought then that since we had the toggle model built, we might as well keep it: it allowed people to use their standard issue Firefoxes easily and painlessly with Tor.

I now no longer believe even this much. I think we should completely do away with the toggle model, as well as the entire idea of Torbutton as a separate piece of user-facing software, and rely solely on the Tor Browser Bundles, except perhaps with the addition of standalone Tor+Vidalia binaries for use by experts and relay operators.

The Tor Browser Bundles will include Torbutton, but we will no longer recommend that people use Torbutton without Tor Browser. Torbutton will be removed from addons.mozilla.org, and the Torbutton download page will clearly state that it is for experts only. If serious unfixed security issues begin to accumulate against the toggle model, we will stop providing Torbutton xpis at all.

I believe this shift must be done for a few reasons: some usability, some technical. Since I feel the usability issues trump the technical ones, I'll discuss them first.

Unfortunately, the Tor Project doesn't really have funding to conduct official usability studies to help us make the best choice, but I think that even without them, it is pretty clear that this migration is what we must do to improve the status quo.

I think the average user is horribly confused by both the toggle model and the need to install additional software into Firefox (or conversely, the need to *also* install Tor software onto their computers after they install Torbutton). I also think that the average user is not likely to use this software safely. They are likely to log in to sites over Tor that they shouldn't, forget which tor mode they are in, and forget which mode certain tabs were opened under. These are all nightmare situations for anonymity and privacy.

On the technical side, several factors are forcing us in the direction of a short-term fork of Firefox. The over-arching issue is that the set of bugfixes required to maintain the toggle model is a superset of those required to maintain the browser model. Trac report #39 lists the bugs we must fix for the browser model, where as to maintain the toggle model, we must fix bugs from trac report #14 in addition to the bugs in report #39.

A similar issue exists with bugs that must be fixed in Firefox. The Firefox API bugs that need to be addressed to properly support the toggle model include rather esoteric and complicated issues that few groups other than Tor will find useful.

This means more resistance from Mozilla to get the toggle mode bugs fixed or even merged, less likelihood the fixes will be used elsewhere, and more danger they will succumb to bitrot. As a result, the lag time between fix and deployment for low-priority Firefox bugs can be as long as 3 years. See Bug 280661 for an example.

The Tor Browser bugs on the other hand are more directly usable by Firefox in its own Private Browsing Mode, which makes them more likely to merge quicker, and be maintained long-term. Also, because we are releasing our own Firefox-based browser, we will also have more control over experimenting with them and deploying these fixes to our users rapidly, as opposed to waiting for the next major Firefox release.

So, we can either invest effort in improving the UI of Torbutton to better educate users to understand our particular rabbit-hole tunnel-vision of design choices, and also solving crazier Firefox bugs; or we can reconsider our user model and try to simplify our software.

We don't have the manpower (ie: enough me) to do both. This means we should go with the simpler, easier option.

We do face a small number of barriers and downsides associated with this plan. We are collecting the issues we need to address ASAP as child tickets of this bug:
https://trac.torproject.org/projects/tor/ticket/2880

Overall, the downsides seem to mostly apply to expert users and how they will adapt the custom Tor setups they have built. We don't anticipate a lot of long term issues with this group, as most of the configuration options of Torbutton will remain available, and users should still be able to install custom addons and configure their Tor Browser profile however they need (even to the point of running it side-by-side to a system tor instance that is used for non-web applications).

Additional discussion about this issue has occurred on the tor-talk mailinglist.

Hopefully this announcement doesn't ruin your day!

IPv6 is the future, I hear

A while ago, I wrote up a description of what needs to be done to get Tor to be IPv6-compliant and sent it to the tor-dev mailinglist. I thought it might be neat to share this on the blog too, so that people know what's left to do before we an call Tor fully IPv6-compliant.

Currently, I'm hoping that for 0.2.3.x we can at least get to the point where bridges can handle IPv6-only clients and exits can handle IPv6 addresses. If we get further, that will be even better.


Overview

This document outlines what we'll have to do to make Tor fully support IPv6. It refers to other proposals, current and as-yet unwritten. It suggests a few incremental steps, each of which on its own should make Tor more useful in the brave new IPv6 future of tomorrow.

Motivation

Turns out, 4 billion addresses wasn't enough.

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.

  1. 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.)
  2. 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.)
  3. Tor must allow nodes to connect to one another over IPv6.
  4. 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 implementation hurdle that will need to get resolved alongside these changes is to convert uint32_t to tor_addr_t in many more places in the Tor code, so we can handle addresses being either IPv4 or IPv6. There are a few cases, e.g. the local router list, where we'll want to think harder about the resource requirements of keeping tens of thousands of larger addresses in memory.

    More issues may of course also be discovered as we develop solutions for these issues, some of which may need to take priority.

    Designs that we will need to do

    For IPv6-only clients, we'll need to specify that routers can have multiple addresses and ORPorts.

    There is an old proposal (118) to try to allow multiple ORPorts per router. It's been accepted; it needs to be checked for correctness, updated to track other changes in more recent Tor versions, and updated to work with the new microdescriptor designs.

    Additionally, we'll need to audit the designs for all our codebase for places that might assume that IPs are a scarce resource. For example, clients assume that any two routers occupying an IPv4 /16 network are "too close" topologically to be used in the same circuit, and the bridgedb HTTPS distributor assumes that hopping from one /24 to another takes a little effort for most clients. The directory authorities assume that blacklisting an IP is an okay response to a bad router at that address. These and other places will instead need more appropriate notions of "closeness" and "similarity".

    We'll want to consider geographic and political boundaries rather than purely mathematical notions such as the size of network blocks.

    We'll need a way to advertise IPv6 bridges, and to use them.

    For transporting IPv6-only traffic, we have another accepted design proposal (117). It has some open questions concerning proper behavior with respect to DNS lookups, and also needs to be checked and updated to track current Tor designs.

    We do not have a current accepted design proposal for allowing nodes to connect to each other via IPv6. Allowing opportunistic IPv6 traffic between nodes that can communicate with both IPv4 and IPv6 will be relatively simple, as will be bridges that have only an IPv6 address: both of these fall out relatively simply from designing a process for advertising and connecting to IPv6 addresses. The harder problem is in supporting IPv6-only Tor routers. For these, we'll need to consider network topology issues: having nodes that can't connect to all the other nodes will weaken one of our basic assumptions for path generation, so we'll need to make sure to do the analysis enough to tell whether this is safe.

    Ready, fire, aim: An alternative methodology

    At least one volunteer is currently working on IPv6 issues in Tor. If his efforts go well, it might be that our first design drafts for some of these open topics arrive concurrently with (or even in the form of!) alpha code to implement them. If so, we need to follow a variant of the design process, extracting design from code to evaluate it (rather than designing then coding). Probably, based on design review, some changes to code would be necessary.

Firefox 4 Tor Browser Bundle for Windows

Windows users, your time has finally arrived! A new Tor Browser Bundle with Firefox 4 is available here (sig). The build infrastructure has moved to a Windows 7 machine, but this bundle has been tested on both WinXP and Win7. If you encounter any strange issues, please let me know here or on our bug tracker. read more »

Reading links, 15 April

Syndicate content Syndicate content