04/01/11 01:03, intrigeri:
> Hi,
>
> something (else) struck me while writing the design paper: T(A)ILS
> really should support bridges. Someone already did a great part of the
> design and implementation thinking (todo/bridge_support), without much
> feedback IIRC. Here is some, random thoughts, sorry for the mess.
Disclaimer: I wrote that.
> I must admit I'm a bit reluctant to the homebrew script approach. I
> would prefer if we could do this by using and possibly improving
> existing tools.
Agreed.
> While comparing a homebrew script vs. Vidalia the following is stated
> there: "The vidalia approach is easier to implement but leaves the
> burden of finding the Vidalia settings and typing shit to the user." I
> just had a look to Vidalia preferences, and am not sure we can design
> a better UI. Of course the bridges configuration is not on the main
> Vidalia preferences screen, but it is quite easy to find IMHO.
To be honest, I had problems finding it since I was looking for an
option that meioned something about briges, when Vidalia calls it "My
ISP blocks connections to the Tor network". However, if we'd have the
same script that inserts "ReachableAddresses..." into torrc also insert
[Network]
UseBridges=true
into vidalia.conf, then it'd get much easier to find.
> I also don't know what "typing shit" is referred to there; AFAIK
> Vidalia does only asks the user to type anything when using manual
> input of bridges.
Perhaps the "Find bridges now" button wasn't implemented at the time I
wrote that, so my suggested one-liner would make it possible for the
user to avoid typing whereas that was mandatory in Vidalia at the time?
In any case, manual input must always be available, and, like you said,
Vidalia has a nice interface for that.
> The "warn before connecting to bridges.torproject.org" part
> could be added to upstream Vidalia I guess, possibly opt-in.
Sure.
> How does Vidalia set these settings? I have not looked further than
> the author of these current implementation notes. Hints: it may depend
> on the Vidalia/Tor operation mode (standalone Tor managed by Vidalia,
> system-wide Tor daemon); I think I remember Vidalia manages its own
> ~/.vidalia/torrc when it manages Tor itself; this solution hasn't the
> issue of configuration being reset when Tor restarts (should be
> checked, btw), and could be investigated as well. User privilege
> isolation could be hard to get, though.
Vidalia saves the bridges to vidalia.conf, so it should be safe in
combination with the ReachableAddresses thingie. Without
ReachableAddresses Tor could connect to the Tor network in the clear in
case Vidalia doesn't start fast enough... and we can't leave that to chance.
> "Since these settings disappear if Tor restarts, this is potentially
> dangerous." -> I am not sure. At this point we already have
> "ReachableAddresses reject *:*" in torrc and Tor is not supposed to
> connect to the network yet. Having to re-type bridge addresses is
> painful, sure... unless Vidalia remembers such settings and re-applies
> the configuration on startup (could be added if not implemented yet).
I agree. And, again, Vidalia saves the configuration. There is a problem
though (see blow)
> => "keep system-wide Tor, Vidalia talks to it over control port"
> seems OK. No messing with torrc, (almost) everything is here
> already but the boot menu toggleable option.
>
> Well, someone (possibly me) should play a bit more with this Vidalia
> stuff.
I played around like this, trying to emulate what you suggest:
1. I started T(A)ILS 0.6.1 without any network plugged in order to
prevent Tor/Vidalia from starting.
2. Once everything has started, I added "ReachableAddresses reject *:*"
to torrc.
3. I installed wireshark (over LAN) and started tapping all network
interfaces.
4. I plugged the network.
5. I waited a few minutes, then I added a known working bridge through
Vidalia (that was started by network manager).
6. Here is where I should edit torrc and send a SIGHUP (as per what I
wrote in the TODO item), but that turned out to not be necessary, so
this point was skipped (see below).
7. I waited a few more minutes, then I visited the T(A)ILS homepage,
which loaded nicely.
8. I unplugged the network, waited 10 seconds (for NM to detect the
disconnect), and then replugged.
Analysis:
When I plugged the network (4) there was the expected network activity
for setting the time, i.e. my network's DNS was used to query the IP
addresses for the chosen sites in the time pool, and they were further
"queried" by htpdate. No other activity was detected, in particular no
Tor activity, so ReachableAddresses did exactly what we wanted. All good.
When I added a bridge through Vidalia (5), Tor started bootstrapping
with the Tor network within seconds and got connected (so it seems we
didn't hit the dreaded bug #1247[1] despite not restarting Tor, but this
may be a coincidence, or not). Since I didn't remove ReachbleAddresses
and SIGHUP:ed Tor, it seems bridges ignores ReachableAddresses, which is
a possible bug (?) that we may want to report. However, this behaviour
makes it very easy for us as no further action is necessary -- Vidalia
Just Makes It Work™. Nice.
Additionally, I verified that all further Internet traffic (7) went
through the bridge. Sweet.
When I replugged the network (8) in order to check robustness of this
approach, there was a problem, unfortunately. This time Tor got stuck at
"Bootstrapping 85%", complaining that:
Notice: no known bridge descriptors running yet; stalling
and
Notice: Our directory information is no longer up-to-date
enough to build circuits: No live bridge descriptors.
I checked Vidalia's options, and the bridge were still there and
enabled. I thought that if I disabled and then re-enabled the option,
things would get rolling again. So, I unticked the option that enables
bridges, clicked OK to have the change applied by Vidalia, but even
before I had time to open Vidalia's network options again I noticed that
Tor connected on its own. I checked the network dump, and sadly Tor did
this by connecting _directly_ to the Tor network, ignoring
ReachableAddresses in torrc completely. This is not good. Did Vidalia
reset ReachableAddresses or something?
To make things even worse, after (8) I continued my plan, re-adding the
bridge, but further connections were still done without the bridge, i.e.
directly to the Tor network, and the two notices quoted above reappeared
in the log.
In an attempt to recover, I disabled bridges again in Vidalia, unplugged
the network and re-plugged it. My thought was that this essentially
would reproduce the original situation at point (4) (only difference was
that Tor has some cached descriptors etc. in its data dir), but it
failed like above.
My next approach was to keep Vidalia's bridge settings, and instead
clear Tor's data dir (rm /var/lib/tor/*). Lo and behold, that worked
exactly as in (5) through (7). I guess this clears Vidalia from being
the culprit?
My reading of the ReachableAddresses option in the man page is that it
should do exactly what we want -- it should apply to _all_ connections
Tor tries to make (including bridges) and at all times. The contents of
data dir shouldn't interfere, but from my experiments it seems they do.
Or does any one has another explanation?
My conclusion of all this is that either ReachableAddresses is buggy, or
it is incorrectly documented in the man page. I hope it is the former,
and that this can be fixed quickly after reporting it to the Tor bug
tracker. If it is the latter we need to get back to the drawing board.
Thoughts?
Cheers!
[1]
https://trac.torproject.org/projects/tor/ticket/1247
PS. Sorry for always writing gargantuan emails. I wish I had the ability
to be more concise.
