Re: [Tails-dev] What do we miss to replace Vidalia [was: Get…

Borrar esta mensaxe

Responder a esta mensaxe
Autor: Alan
Data:  
Para: tails-dev
Asunto: Re: [Tails-dev] What do we miss to replace Vidalia [was: Getting rid of Vidalia]
Hi,

intrigeri <intrigeri@???> wrote:
> Alan wrote (15 Feb 2015 00:42:34 GMT) :
> > intrigeri <intrigeri@???> wrote:
> >> I'd love to understand why this would be more useful than some
> >> existing GNOME network monitor that we don't have to maintain, and so
> >> far I fail to. You find it desirable, so there's probably a good
> >> reason.
>
> > As an example, when using a poor connection, I like to see if there is
> > Tor traffic going on or not. I must admit I never tried to use GNOME
> > System Monitor for that and that it may very well work (or not).
>
> On Tails/Jessie, "Applications -> Utilities -> System Monitor ->
> Ressources" seems to address the need you're expressing. We ship it
> already. Please try it out before writing code that duplicates this
> existing functionality :)
>

I'll try.

> >> And now, I'll add another candidate feature:
> >>
> >> - Can access the Tor control port via a tight filtering proxy
> >>
> >>    I'm curious what kind of access the new thing needs.

>
> > Tor monitor uses stem, and I didn't search about hidden things stem
> > might need. I use methods that directly call:
>
> > - GETINFO circuit-status
> > - GETINFO stream-status
> > - GETINFO ip-to-country
>
> I guess the only way to know is to actually run Tor Monitor behind our
> filtering proxy, have the latter log refused commands, append to the
> whitelist until everything works, and then report back what the
> whitelist is. Are you interested in doing this?
>

Couldn't this be a 2nd step? I might be interested but I'd like to see
this as a project mainly for fun. Currently I'm more into doing it good
enough to replace vidalia. Does this makes sense to you?

> >>    And forcibly keeping this access read-only tightens things a bit against
> >>    X11-based attacks.

> >>
> > We need at least to query Tor for its open circuits and streams if we
> > want to be able to start Tor Monitor after Tor. If we can ensure that
> > Tor Monitor connects to Tor before Tor has open any circuit or stream,
> > then it may be possible to have read only access if no command on the
> > control port is needed to be notified of circuit or stream changes.
>
> Everything that you're describing here sounds like read-only access to
> me, so I don't understand what you mean. Does "query[ing] Tor for its
> open circuits and streams" need anything else but read-only access?
>
> Just to clarify: I count retrieving info about the Tor state (GETINFO)
> as read-only access, even if technically this is wrong. Maybe that's
> where the misunderstanding was. The security feature I'm asking for is
> that Tor Monitor shouldn't be allowed to *configure* Tor, and it
> should only be allowed to *retrieve* the info it really needs via
> a GETINFO filter.
>

OK, then it has "read only" access in your sense of "read only".

> >> And a few more questions:
> >>
> >> - Why does Tor Monitor need to use a Tor SOCKS port? Just curious :)
>
> > To get details on a path. As Tor currently uses microdescriptors which
> > contains very few information, I use stem remote descriptor downloader,
> > which connects directly to Tor directory. Looking more deeply at what I
> > can get directly from Tor, I just found that I can get the IP and other
> > information missing in microdescriptors from Tor network status, so I'd
> > only miss platform and uptime - which are not visible in Vidalia
> > anymore.
>
> I definitely wouldn't miss it if the platform and uptime info
> disappeared, and we got tighter security as a result. Let's just do
> that and get rid of the SOCKS port access requirement, then?
>

Done in git.

> >>  - 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?

> >>
> > I was thinking about an application that an user would only launch from
> > the Applications menu/overview. I also thought about a button in the
> > "Tor is ready" notification.
>
> I like it this way.
>

Good. I'm up for doing that in Tails/Jessie as soon as we get a
consensus on the rest.

Cheers