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

このメッセージを削除

このメッセージに返信
著者: intrigeri
日付:  
To: The Tails public development discussion list
題目: Re: [Tails-dev] What do we miss to replace Vidalia [was: Getting rid of Vidalia]
Hi,

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 :)

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

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

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

>>    (The next question will be: what kind of data does it retrieve via
>>    this port, how is it used and parsed, but for that I can probably
>>    just look at the code.)

>>
> I use stem.descriptor.remote.DescriptorDownloader.


That's the kind of answer I was hoping to get!

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

Cheers,
--
intrigeri