Hi,
sajolida wrote (18 Feb 2015 11:32:17 GMT) :
> intrigeri:
>> Alan wrote (12 Feb 2015 15:32:15 GMT) :
>>>>> - Ability to close a circuit manually.
>>>>
>>>> No idea what are the use case for this feature that we would want to
>>>> support. If someone really wants it, better add it to arm IMO.
>>>>
>>> Tor Monitor doesn't provide this feature yet. It would be very easy to
>>> add, even though I'm not sure I find it desirable: currently we only
>>> *monitor* Tor. Do we also really want to *control* it?
>>
>> Rather not IMO, but I guess everybody got that already :)
>>
>> I'd love to see Tails run no X application, except Tor Launcher, that
>> is able to trivially deanonymize the user via the control port.
> Being able to close circuits could be useful to debug malicious exit
> nodes. For example, you get an unexpected HTTPS or SSH warning, write
> down the info about your exit node, and close that circuit to get a
> fresh one and confirm your suspicions.
Good catch!
> How important would that be given it doesn't happen that often?
> On the other hand I understand the importance of not doing into
> controlling Tor.
Indeed, I'm pretty sure that closing arbitrary circuits offers
excellent avenues for de-anonymization attacks. It *might* be possible
to mitigate this problem by strongly rate-limiting it, though. If it
works, then this might be the easiest way out, but it would need
a careful threat modeling and security discussion before I trust it.
I think that would be the most elegant way to solve this problem.
Everything that follows in this paragraph is just in case nobody works
on this potential solution early enough.
Do we think that the majority of users who can do this kind of
analysis would suffer from having to do it in arm? If not, then the
next step is to file a wishlist ticket about it in arm upstream.
If yes, then it gets harder, but maybe there are good enough ways out
for the users in the grey zone (skilled enough to conduct this
analysis, not Unixist enough to be at ease in a terminal-based UI):
* For HTTPS, one can already use Torbutton's New Identity feature to
achieve the same result. IIRC the upcoming Torbutton's per-tab
circuits viewer will have a "New circuit for this tab" feature,
that will make it even better.
* For other kinds of connections (ssh, imaps, pop3s, etc.) then there
are two ways:
- either using arm to trigger a New Identity, which is not *that*
crazy: close the software that initiated the connection, open
a root terminal (which may be a blocker in itself), run "arm",
type "m", "down arrow" then "enter"
- or restarting Tor, e.g. by disconnecting and reconnecting from
the network using the NM applet
=> seems like we can address this corner case in a good-enough way
without compromising security nor spending large amounts of energy on
this topic.
> To go back to the information we should provide about the circuits:
> 1. Be able to know the country of your exit node can be useful to
> understand some limitations it might have when trying to access some
> ressources (eg. YouTube in Germany).
Indeed, would be useful.
> 2. We should have a look at what Tor is planning to integrate to their
> browser as they are already solving a similar problem. I think.
Full ACK. It'll be in Tor Browser 4.5a4, due in ~1 week, if I got
it clearly.
>> - Has there been any thought put already into how Tor Monitor would
>> integrate into #7437 ("Add a progress indicator while establishing
>> a connection to Tor"), or live aside of it? I was kinda hoping that
>> removing Vidalia would help consolidating the sources of
>> information we provide to the user about the network bootstrap
>> process: I bet the variety of such sources participate in confusing
>> users. So if Tor Monitor is meant to be an independent tool,
>> perhaps it's better if it does *not* start by default. Anyway, I'm
>> wandering a bit off-topic here, but you don't want me to wait
>> 6 months before I ask this question, right?
> Right, there's definitely a UX side to this. The first thing I can think
> of is that people are going freak out if the green onion disappear as
> its currently the only indicator of the Tor state on the desktop. I'm
> not talking about the "Tor is ready" notification which is not an
> permanent indicator.
I'm not sure that this green onion is actually an "indicator of the
Tor state", see below.
> We developers know that nothing can do wrong and everything that is not
> Tor would be blocked. But in term of usable security, I think it's
> important to have a visual indicator saying "hey, everything is
> all-right".
OK. If all we need is to convey the message that everything is
configured to go through Tor, then we don't even need to talk to the
control port: we can just display a green onion (once Tor has
bootstrapped) and leave it there as long as the Tor service is
running. I'm half-joking, but seriously, given we *know* that
everything is alright, we can just say that in the way people want to
hear it, which is apparently that green onion (I'll trust you on that
one).
> And also how shall we let users know when their Internet
> connection is working but they loose their connection to Tor for some
> reason (say their bridge shuts down)?
I acknowledge this is (or would be, read on) a very useful
feature too.
Now... does Vidalia really do that? In other words, does Vidalia's
green onion really turn yellow or red or something whenever this
happens? I don't think so: I *believe* that Vidalia's onion indicator,
once it has turned green, only reflects the state of Vidalia's
connection to the Tor control port, not the state of the tor daemon's
connection to the Tor network. I don't remember seeing it change
colors unless I e.g. restarted Tor. I'd be happy to be proven wrong,
though :)
> You're going to hate me
No! <3
> but would it be conceivable to have Tor Monitor
> appear as green onion on the desktop as Vidalia does until now?
If we really have had the feature you're asking for (conveying the
status of the tor processs connection to the Tor network) since years,
then sure, it definitely makes sense to me to keep it.
If, however, we never had this feature, then IMO it can't suddenly
become important and a blocking missing feature in Tor Monitor.
So I think we need a clarification about what Vidalia actually does,
before answering this question.
I'm sorry I may sound like I'm pushing back hard on that one. Here are
my reasons to insist on first evaluating what Vidalia actually does:
* We're using the "users have been trained/used to $feature" argument
when building our list of specifications for Tor Monitor, which
totally makes sense to me. And then, I need to see a double-checked
assessment of what Tails users have been trained/used to until now;
that is, not only an assessment of what they *believe* the green
onion means, but also an assessment of what it *actually* means.
Sorry for my lack of faith, and very sorry if you have already
double-checked what I'm raising doubts about.
* I want to keep that spec as lightweight as possible, and not stuff
it with too many features, so that the next point is realistic:
* I'd like us to remove Vidalia ASAP, both for security reasons and
for maintainability ones (note that Vidalia is probably not going
to be part of Debian Jessie, so in practice we'll soon be the only
ones shipping and using this piece of software).
> And if Tor Monitor is always running in the background, then maybe it
> could also provide information while Tor is starting and be the right
> tool to solve #7437 in the future?
That's what I had hidden in the back of my head when asking this
question initially :)
The main problem I see with this approach is: if we go this way, then
either Tor Monitor stops being a generic tool, but becomes yet another
Tails-specific thing, which would make me sad. I thought about it
a bit harder, and now it's not obvious to me what we would gain by
merging the two tools we need into a single one:
* Tails could start the Tor bootstrap and time sync progress monitor.
Upon completion, this piece of software would either just
terminate, or (if we need a permanent indicator that's tight to the
actual Tor status) start Tor Monitor --hide-in-taskbar, that would
display some onion.
* Anyone else would just use Tor Monitor.
And then this topic becomes mostly orthogonal to the current
discussion, I think :)
> I hope that this will still allow us to simplify and make robust the Tor
> bootstrapping process (which is currently a bit messy if I remember
> correctly). We could have:
> - Tor Monitor always running, reading the Tor status, and providing the
> user visible side of things and replace the NM hooks
> "60-tor-ready-notification.sh" and "60-vidalia.sh".
... and some of 20-time.sh as well.
> - Network Manager doing only the starting and stopping without worrying
> about the visible side of things.
ACK.
(Off-topic: one problem we'll have in resolving #7437 is how it plays
with Tor Launcher in "bridge mode", that already provides *some*
feedback regarding Tor bootstrap.)
Cheers!
--
intrigeri
