[tor-talk] can't get tor to work :(

[Scott Bennett]

     On Tue, 8 Mar 2011 14:26:35 -0500 Roger Dingledine <arma at mit.edu> wrote:
>On Sun, Mar 06, 2011 at 10:09:49AM -0800, Robert Ransom wrote:
>> > In the default mode, it will hang on "connecting to a relay directory
>> > failed (no route to host)"
>> 
>> All of the directory authorities crashed between 2011-03-06T10:00 and
>> 2011-03-06T11:00 UTC.  Newly started Tor clients will not work until
>> the directory authorities are running again.
>
>There was indeed a directory authority outage, but it's unclear whether
>the original bug report here is related to the outage.
>
>When all directory authorities are down, new Tor clients can't bootstrap
>if they don't have cached directory information from earlier that day. But
>Tor clients that are already up and have directory information are all
>set for about 24 hours. At that point, if the directory authorities
>still haven't produced any new consensus about the network, things go bad.
>Fortunately, in this case things didn't come to that.
>
>We don't believe directory information that's too old, to protect clients
>from attackers who choose their favorite consensus from the past year and
>give that to their target client, either to skew their path selection
>onto relays that the attacker controls, or to make the client build
>paths in a distinguishable way from all the other clients. See
>http://freehaven.net/anonbib/#danezis-pet2008
>for a variation on this issue.
>
>The reason I say it's unclear whether the original bug report is related
>is that a Tor bridge should have been able to bootstrap the user the
>whole time. Most Tor clients probably didn't notice any disruption.
>
>For those wondering about the role of the directory authorities, see e.g.
>https://www.torproject.org/docs/faq#KeyManagement
>
>The bug in this case was that we had implemented partial IPv6 support
>for Tor but hadn't implemented it in a consistent way. So when somebody
>tried adding the experimental IPv6 support to his exit policy, the
>directory authorities triggered an assert. We figured out the problem,
>created a patch, and got a threshold of directory authorities to upgrade,
>in about 8 hours. Plenty of time to spare. ;)
>
>Mike opened this trac ticket afterwards so we can adapt our process for
>handling these situations:
>https://trac.torproject.org/projects/tor/ticket/2664
>
     Thank you for the explanation, Roger.  I see that the bug must have
been present in all of the versions of tor running that the authorities
were running at the time, which suggests that the rule about having the
authorities be spread across several versions at all times failed to be
sufficient in the end to uphold the purpose of the rule.  Perhaps the
timing of code propagation for new features that have yet to be fully
tested needs to be rethought. For example, should IPv6 support have been
eligible to appear in the "stable" versions of tor yet?
      Does the bug affect directory mirrors as well?  In other words, if
a new version of tor is implemented on some of the authorities that will
correctly handle whatever exit policy was the problem, will the distribution
of descriptors bearing that exit policy by the authorities to mirrors cause
the mirrors to crash, too, if they are running today's versions of tor at
the time if they don't have your patch applied?  How about ordinary non-exit
relays?  Clients?


                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:       bennett at cs.niu.edu                              *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************