intrigeri:
> 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.
Fine with me. Still, we would need to have arm documented in the first
place. And since I propose it to go in "Advanced topics" anyway we can
explain the workaround there for now and create the upstream ticket that
you mentioned as well.
>>> - 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 :)
Same for me, I'm pretty sure that Vidalia stays green forever once Tor
is started. And I'm fine with mimicking this behavior for a start if
that's easier to implement (no regression), but I think this is buggy
(the onion shouldn't be green if Tor is not in a working state anymore).
I want to replace Vidalia to get rid of its bugs not to reimplement them :)
>> 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.
I don't think it's blocking either. I'm just trying to think in advance
about what Tor Monitor should be in its version 1.0, just to make sure
that we are taking the right architectural decisions from the beginning.
> * 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.
Of course, we analyze what Vidalia does to check for regressions, but
that should prevent us from planning to get better than Vidalia.
Otherwise we'd have pretty low quality standards :)
> * 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).
Yes, and if I understood correctly Tor Monitor currently needs Tails
Jessie. So an obvious roadmap would be to have a working replacement of
Vidalia with Tor Monitor (without regressions) in Tails Jessie. Does
that sound realistic? Then only we can work on making it better (eg.
smarter onion status icon, progress bar while starting Tor, etc.).
>> 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.
Let's try to make it generic straight away! I'd love to have it on my
regular Debian as well.
> 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 :)
That would work. It would cut the visible part of things into two: Tor
Monitor (with status icon) and progress bar (while starting Tor).
But couldn't the Tor progress bar be generic as well? I'm not sure but
it could make sense on my regular Debian when starting or restart Tor as
well. Then even the progress bar is in Debian and not Tails specific.
> (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.)
Yeah, I just thought about that while writing that email as well. Maybe
we could skip the Tor Launcher progress bar once we have our own. But
then what happen if Tor Launcher fails to start Tor because all the
bridges are unreachable?
