Re: [tor-dev] Contents of tor-dev digest...

[Mike Guidry]

I didn't write the paper for this list specifically.  It requires
performing DDoS attacks.  Your the one trolling someone in reality.  I am
not going to go out of my way to spend time when realistically its quite
simple to perform.  If you don't want to use NTP, and other factors to
performing efficient timing attacks then you can just completely blackhole
networks.  If the connection dies, or an ACK storm persists then you have
found the culprit..

I am not releasing papers for recognition.  I don't care whether or not its
perfect.. Its because its a vulnerability, and I'm trying to ensure people
understand the possibilities...

I am sorry that I do not write papers as you wish I would...  I hope that
you enjoy my explanation of a solution more than you have about the issue
itself.

have a great week,
mike

On Mon, Apr 10, 2017 at 8:04 PM, dawuud  wrote:

>
> > I'm not presenting a scientific paper.  Its an actual method that works.
>
> You must learn how to articulate the idea without muddling it with all
> kinds
> of other irrelevant stuff. Nobody mentioned scientific papers. Are you
> saying
> that you don't read papers describing attacks on Tor? They are really fun
> to read.
>
> > You can DDoS various networks to compare against active connections on
> TOR,
> > and otherwise...
>
> What are the assumptions of the attack?
> What kind of capabilities must an attacker have?
>
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
>
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Contents of tor-dev digest...

[dawuud]

> I'm not presenting a scientific paper.  Its an actual method that works.

You must learn how to articulate the idea without muddling it with all kinds
of other irrelevant stuff. Nobody mentioned scientific papers. Are you saying
that you don't read papers describing attacks on Tor? They are really fun to 
read.

> You can DDoS various networks to compare against active connections on TOR,
> and otherwise...

What are the assumptions of the attack?
What kind of capabilities must an attacker have?


signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Tracing TCP Connections online..

[Mike Guidry]

re: grarpamp

I am writing a possible countermeasure which uses transactional requests.
You submit entire requests which are processed by the exit node.  Several
other situations can take place while routing to the exit node.  It would
also only require exit nodes to have updated to the newer feature.

I'll post as soon as I'm finished..

Thanks,
Mike Guidry

-


>This appears to describe an active network modulation attack (node DoS).
>Either hammer tree on nodes of the expected path and trace the modulation,
>or on all but the expected path to find unmodulated.
>It generally requires GPA, deploying nodes, or being one end of the path...
>in order to observe the results.
>And it's old news.
>As noted before, since Tor (and all other current anonymous overlays)
>nodes do not perform their own independant buffering, reclocking and
>contracting for expected hop parameters... this vulnerability will remain.

>Anyone wanting to research, code, deploy, and present on
>such countermeasures would certainly be welcomed.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Contents of tor-dev digest...

[Mike Guidry]

I'm not presenting a scientific paper.  Its an actual method that works.
You can DDoS various networks to compare against active connections on TOR,
and otherwise...


On Mon, Apr 10, 2017 at 12:22 PM, dawuud  wrote:

>
>
> Dear Mike Guidry,
>
> My reply here is snarky but I just cannot help it. Please consider me
> a friend that is snarky rather than an enemy or an asshole.
>
> I am finding it very hard to read. It is *extremely* annoying that you
> present your definition of "hacking" at the beginning and then go on to
> define TCP, UDP and other irrelavent things. it also buzzes and pops with
> wtf terms like "reflect lateral hacking movements". Is your target audience
> journalists who won't know what to look for in a good technical write up
> of an actual attack?
>
> Perhaps it would be helpful for you to review some of the vast academic
> literature
> about breaking Tor since you are interested in breaking Tor:
>
> https://www.freehaven.net/anonbib/
>
>
> Sincerely,
>
> David Stainton
>
>
> On Mon, Apr 10, 2017 at 11:17:13AM -0400, Mike Guidry wrote:
> > I am not trolling you.  I attached a PDF which explains how to trace TOR
> > connections over the internet.  It is not a joke.  I have some other
> > vulnerabilities at that URL I am releasing.
> >
> > I'll include here:
> >
> > Michael Guidry March 15, 2017
> >
> > Tracing connections online from the virtual landscape to the physical
> world
> >
> > Hacking is the intrusion of a computer by an unwanted guest, and is
> usually
> > used to express gaining access to corporate, or government networks. It
> > requires either installing using malware, phishing, or directly
> connecting
> > to machines and attacking their software with exploits. It is currently
> > impossible to accurately trace hackers online unless they use the same
> > software, and techniques for all their targets. It has become a major
> > problem within the last decade due to globalization, and corporate
> networks
> > directly connected to the Internet.
> >
> > Tracing Transmission Control Protocol (TCP) connections across the
> Internet
> > is inaccurate due to how routing is performed across global backbones.
> The
> > global routing table is modified constantly with nodes, and routes being
> > adjusted for optimization, or quality of service needs. TCP is the most
> > used protocol therefore it is the only protocol which really matters to
> > attempt to trace. User Datagram Protocol (UDP) is state less therefore
> less
> > reliable for tracking, however has the same vulnerability. UDP is usually
> > used by hackers for exfiltration, or remote control after other actions
> > have been performed.
> >
> > It is currently impossible to track connections over the Internet
> > accurately. Several cases relate to The Onion Router (TOR) sites aka
> “Dark
> > Web,” which were somehow uncovered using private technologies.
> Technologies
> > used for those cases do not work properly over regular hacking via
> proxies
> > online. Its an issue for the landscape of political hacking worldwide
> which
> > has been increasing annually across the globe.
> >
> > China, for example, has been having a lot of blame lately due to Internet
> > Protocol (IP) addresses assigned within its borders being used in massive
> > amounts of attacks. Some of these attacks have been supposedly verified,
> > however it is impossible for China to have performed them all. Proxy
> > servers being used in chains may just be victims themselves. The problem
> > arises due to possible evidence planting being similar to proxying
> through
> > their others networks, or borders. It is completely different comparing
> > cyber war to traditional conflicts due to evidence being traceable, and
> > soldiers physical evidence being easily recovered.
> >
> > Hacking back is a concept any government, or corporation is now detailing
> > within their playbook to understand how the liabilities may affect them.
> It
> > is the terminology used to attack the source of an intrusion by means of
> > hacking itself. Repercussions of hacking a country due to incorrectly
> > assuming an attack was originating there is highly possible. Cyber war
> > policies exists for a lot of nations, and it may easily escalate their
> > attention on whom they believe is performing the attacks. The same
> happens
> > with ‘proxy wars’ currently within the middle east, etc. Proxy wars
> > traditionally will have global evidence allowing verification of weapon
> > deliveries, or monetary exchanges to determine the origin of funding.
> > Soldiers training methods, and other strategies may be impossible to
> cloak.
> > It is generally accepted once verified, and escalation is directed
> towards
> > the proper perpetrator.
> >
> > Internet Service Providers (ISP) have the ability to perform various
> tasks
> > internally to determine the pathways through their networks which would
> > reflect lateral hacking movements. Connections leaving a 

Re: [tor-dev] Control-port filtering: can it have a reasonable threat model?

[Yawning Angel]

On Mon, 10 Apr 2017 19:35:24 +0400
meejah  wrote:
> Obviously as per my other post I agree with fragmented / limited views
> given to "real" applications of the control-port. However, personally
> I don't see the point of implementing this in 'tor' itself -- existing
> control-port filters are "fairly" limited code, typically in "safer
> than C" languages anyway. So then you have the situation where
> there's a single trusted application (the filter) conencted to the Tor
> control-port.

I agree with this, because it's basically required to do certain
things, and for certain adversarial models.

> Ultimately, it would probably be best if there was "a" robust
> control-port filter that shipped as part of a Tor release. So if that
> means "must implement it in C inside Tor" I guess so be it.

I moderately disagree with this.  It's not clear to me if a one size
fit's all solution (that supports all "first class platforms" and use
cases) would be easy to develop initially, and it will take continuous
love and care to support everything that people want to do.

By "first class" platforms in this context (since it's more client
facing) I'll start off with "Whatever Tor Browser happens to be
packaged for" as a first pass narrow definition.

Even if this was shipped, I'm trying to keep the external dependencies
required for correct sandbox functionality to a minimum, and something
that's part of the bundle it downloads/auto updates doesn't feel great
to me.

> Maybe this would be a good target for "experiment with Rust" if
> anyone's excited about writing control-port code in Rust...?

I disagree with this, but since it'll never be used by the sandbox, my
disagreement shouldn't stop anyone.

-- 
Yawning Angel


pgpEwYYfnw948.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Tracing TCP Connections online..

[dawuud]

hella old news. oh look here's POC for end to end correlation
https://var.thejh.net/git/?p=detour.git;a=blob;f=README

but why bother chatting about this since it's explicitly not
in Tor's threat model to protect against a global passive adversary?
if you want to protect against that then look into the vast mixnet literature.

anyway for breaking tor you can read lots of good papers such as
(note that none of these papers present their definition of "hacking" or
define well known terms like TCP and UDP ;-)
:

The Sniper Attack: Anonymously Deanonymizing and Disabling the Tor Network
https://www.freehaven.net/anonbib/cache/sniper14.pdf

Spying in the Dark: TCP and Tor Traffic Analysis
http://freehaven.net/anonbib/papers/pets2012/paper_57.pdf

A Practical Congestion Attack on Tor Using Long Paths
http://freehaven.net/anonbib/papers/congestion-longpaths.pdf

Trawling for Tor Hidden Services: Detection, Measurement, Deanonymization
https://www.freehaven.net/anonbib/cache/oakland2013-trawling.pdf


On Mon, Apr 10, 2017 at 01:21:05PM -0400, grarpamp wrote:
> re: "tcp_tracing_internet.pdf"
> 
> This appears to describe an active network modulation attack (node DoS).
> Either hammer tree on nodes of the expected path and trace the modulation,
> or on all but the expected path to find unmodulated.
> It generally requires GPA, deploying nodes, or being one end of the path...
> in order to observe the results.
> And it's old news.
> As noted before, since Tor (and all other current anonymous overlays)
> nodes do not perform their own independant buffering, reclocking and
> contracting for expected hop parameters... this vulnerability will remain.
> 
> Anyone wanting to research, code, deploy, and present on
> such countermeasures would certainly be welcomed.
> ___
> tor-dev mailing list
> tor-dev@lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev


signature.asc
Description: PGP signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Tracing TCP Connections online..

[grarpamp]

re: "tcp_tracing_internet.pdf"

This appears to describe an active network modulation attack (node DoS).
Either hammer tree on nodes of the expected path and trace the modulation,
or on all but the expected path to find unmodulated.
It generally requires GPA, deploying nodes, or being one end of the path...
in order to observe the results.
And it's old news.
As noted before, since Tor (and all other current anonymous overlays)
nodes do not perform their own independant buffering, reclocking and
contracting for expected hop parameters... this vulnerability will remain.

Anyone wanting to research, code, deploy, and present on
such countermeasures would certainly be welcomed.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Contents of tor-dev digest...

[dawuud]

Dear Mike Guidry,

My reply here is snarky but I just cannot help it. Please consider me
a friend that is snarky rather than an enemy or an asshole.

I am finding it very hard to read. It is *extremely* annoying that you
present your definition of "hacking" at the beginning and then go on to
define TCP, UDP and other irrelavent things. it also buzzes and pops with
wtf terms like "reflect lateral hacking movements". Is your target audience
journalists who won't know what to look for in a good technical write up
of an actual attack?

Perhaps it would be helpful for you to review some of the vast academic 
literature
about breaking Tor since you are interested in breaking Tor:

https://www.freehaven.net/anonbib/


Sincerely,

David Stainton


On Mon, Apr 10, 2017 at 11:17:13AM -0400, Mike Guidry wrote:
> I am not trolling you.  I attached a PDF which explains how to trace TOR
> connections over the internet.  It is not a joke.  I have some other
> vulnerabilities at that URL I am releasing.
> 
> I'll include here:
> 
> Michael Guidry March 15, 2017
> 
> Tracing connections online from the virtual landscape to the physical world
> 
> Hacking is the intrusion of a computer by an unwanted guest, and is usually
> used to express gaining access to corporate, or government networks. It
> requires either installing using malware, phishing, or directly connecting
> to machines and attacking their software with exploits. It is currently
> impossible to accurately trace hackers online unless they use the same
> software, and techniques for all their targets. It has become a major
> problem within the last decade due to globalization, and corporate networks
> directly connected to the Internet.
> 
> Tracing Transmission Control Protocol (TCP) connections across the Internet
> is inaccurate due to how routing is performed across global backbones. The
> global routing table is modified constantly with nodes, and routes being
> adjusted for optimization, or quality of service needs. TCP is the most
> used protocol therefore it is the only protocol which really matters to
> attempt to trace. User Datagram Protocol (UDP) is state less therefore less
> reliable for tracking, however has the same vulnerability. UDP is usually
> used by hackers for exfiltration, or remote control after other actions
> have been performed.
> 
> It is currently impossible to track connections over the Internet
> accurately. Several cases relate to The Onion Router (TOR) sites aka “Dark
> Web,” which were somehow uncovered using private technologies. Technologies
> used for those cases do not work properly over regular hacking via proxies
> online. Its an issue for the landscape of political hacking worldwide which
> has been increasing annually across the globe.
> 
> China, for example, has been having a lot of blame lately due to Internet
> Protocol (IP) addresses assigned within its borders being used in massive
> amounts of attacks. Some of these attacks have been supposedly verified,
> however it is impossible for China to have performed them all. Proxy
> servers being used in chains may just be victims themselves. The problem
> arises due to possible evidence planting being similar to proxying through
> their others networks, or borders. It is completely different comparing
> cyber war to traditional conflicts due to evidence being traceable, and
> soldiers physical evidence being easily recovered.
> 
> Hacking back is a concept any government, or corporation is now detailing
> within their playbook to understand how the liabilities may affect them. It
> is the terminology used to attack the source of an intrusion by means of
> hacking itself. Repercussions of hacking a country due to incorrectly
> assuming an attack was originating there is highly possible. Cyber war
> policies exists for a lot of nations, and it may easily escalate their
> attention on whom they believe is performing the attacks. The same happens
> with ‘proxy wars’ currently within the middle east, etc. Proxy wars
> traditionally will have global evidence allowing verification of weapon
> deliveries, or monetary exchanges to determine the origin of funding.
> Soldiers training methods, and other strategies may be impossible to cloak.
> It is generally accepted once verified, and escalation is directed towards
> the proper perpetrator.
> 
> Internet Service Providers (ISP) have the ability to perform various tasks
> internally to determine the pathways through their networks which would
> reflect lateral hacking movements. Connections leaving a single network
> that enter the realm of dynamic routing via Border Gateway Protocol (BGP)
> become a nightmare. The percentage of accuracy decreases
> 
> exponentially as each separate network is used to route the connection to
> its destination. It becomes nearly impossible to trace after just a few
> gateways at least publicly, or academically.
> 
> Unorthodox methods are required to allow tracing of connections under these
> 

Re: [tor-dev] Control-port filtering: can it have a reasonable threat model?

[meejah]

anonym  writes:

>> It allows "GETINFO onions/current", which can expose a list of every
>> onion service locally hosted, even those not launched through
>> onionshare.

> I think this can be disallowed; in fact, when looking at the
> onionshare and stem sources I don't see why this would ever be used by
> onionshare.

I may have said this already, but I think the original comment is wrong:
this only lists ephemeral onions created by the current control
connection so I don't believe there's any information leak here anyway.

> BTW, I guess a `restrict-onion-view` would also make sense for HS_DESC
> events [..]

Yes, I think this would be good. To determine if a control-connection
owns an onion or not, I think you could either use "GETINFO
onions/current" (to ask Tor) or just remember the answers from any
ADD_ONION on "this" connection (and then match against the args in the
HS_DESC event).

If the filter is re-started, all the control connections will be lost
at which point any non-"detached" onions will vanish anyway.

> Imagine that ControlPort can take a "RestrictedView" flag. When set,
> controllers will get a view of Tor's state (streams, circuits, onions
> etc) restricted to what "belongs" to them, e.g. it only sees streams
> for connections itself made via the SocksPort. Tor would then have to
> internally track who these things belong to, which could be done by
> PID, which is pretty weak, but I bet there are more convincing ways.

Obviously as per my other post I agree with fragmented / limited views
given to "real" applications of the control-port. However, personally I
don't see the point of implementing this in 'tor' itself -- existing
control-port filters are "fairly" limited code, typically in "safer than
C" languages anyway. So then you have the situation where there's a
single trusted application (the filter) conencted to the Tor
control-port.

Ultimately, it would probably be best if there was "a" robust
control-port filter that shipped as part of a Tor release. So if that
means "must implement it in C inside Tor" I guess so be it.

Maybe this would be a good target for "experiment with Rust" if anyone's
excited about writing control-port code in Rust...?

-- 
meejah
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Contents of tor-dev digest...

[Mike Guidry]

I am not trolling you.  I attached a PDF which explains how to trace TOR
connections over the internet.  It is not a joke.  I have some other
vulnerabilities at that URL I am releasing.

I'll include here:

Michael Guidry March 15, 2017

Tracing connections online from the virtual landscape to the physical world

Hacking is the intrusion of a computer by an unwanted guest, and is usually
used to express gaining access to corporate, or government networks. It
requires either installing using malware, phishing, or directly connecting
to machines and attacking their software with exploits. It is currently
impossible to accurately trace hackers online unless they use the same
software, and techniques for all their targets. It has become a major
problem within the last decade due to globalization, and corporate networks
directly connected to the Internet.

Tracing Transmission Control Protocol (TCP) connections across the Internet
is inaccurate due to how routing is performed across global backbones. The
global routing table is modified constantly with nodes, and routes being
adjusted for optimization, or quality of service needs. TCP is the most
used protocol therefore it is the only protocol which really matters to
attempt to trace. User Datagram Protocol (UDP) is state less therefore less
reliable for tracking, however has the same vulnerability. UDP is usually
used by hackers for exfiltration, or remote control after other actions
have been performed.

It is currently impossible to track connections over the Internet
accurately. Several cases relate to The Onion Router (TOR) sites aka “Dark
Web,” which were somehow uncovered using private technologies. Technologies
used for those cases do not work properly over regular hacking via proxies
online. Its an issue for the landscape of political hacking worldwide which
has been increasing annually across the globe.

China, for example, has been having a lot of blame lately due to Internet
Protocol (IP) addresses assigned within its borders being used in massive
amounts of attacks. Some of these attacks have been supposedly verified,
however it is impossible for China to have performed them all. Proxy
servers being used in chains may just be victims themselves. The problem
arises due to possible evidence planting being similar to proxying through
their others networks, or borders. It is completely different comparing
cyber war to traditional conflicts due to evidence being traceable, and
soldiers physical evidence being easily recovered.

Hacking back is a concept any government, or corporation is now detailing
within their playbook to understand how the liabilities may affect them. It
is the terminology used to attack the source of an intrusion by means of
hacking itself. Repercussions of hacking a country due to incorrectly
assuming an attack was originating there is highly possible. Cyber war
policies exists for a lot of nations, and it may easily escalate their
attention on whom they believe is performing the attacks. The same happens
with ‘proxy wars’ currently within the middle east, etc. Proxy wars
traditionally will have global evidence allowing verification of weapon
deliveries, or monetary exchanges to determine the origin of funding.
Soldiers training methods, and other strategies may be impossible to cloak.
It is generally accepted once verified, and escalation is directed towards
the proper perpetrator.

Internet Service Providers (ISP) have the ability to perform various tasks
internally to determine the pathways through their networks which would
reflect lateral hacking movements. Connections leaving a single network
that enter the realm of dynamic routing via Border Gateway Protocol (BGP)
become a nightmare. The percentage of accuracy decreases

exponentially as each separate network is used to route the connection to
its destination. It becomes nearly impossible to trace after just a few
gateways at least publicly, or academically.

Unorthodox methods are required to allow tracing of connections under these
circumstances. Distributed Denial of Service (DDoS) is a solution that
allows you to turn the internet’s own packet distribution system into a
tracking mechanism. Most people do not consider performing DDoS attacks for
positive reasons. DDoS may have been used by targets to “quarantine” their
hacking source temporarily from the Internet. This strategy is beyond the
scope of this technique, and is literally only a bandaid for a single
attack originating from possibly just a proxy.

DDoS is also illegal in most nations which have advanced their cyber crime
laws. The fact that this technique requires many computers performing
attacks strategically placed across the globe also ensures that they will
be performed from countries where these laws are being enforced. The attack
requires attacking all networks that you wish to verify against therefore
you are immediately breaking laws on the destination side of most of the
world simultaneously. It 

Re: [tor-dev] Control-port filtering: can it have a reasonable threat model?

[anonym]

Nick Mathewson:
> Hi!
> 
> As you may know, the Tor control port assumes that if you can
> authenticate to it, you are completely trusted with respect to the Tor
> instance you have authenticated to.  But there are a few programs and
> tools that filter access to the Tor control port, in an attempt to
> provide more restricted access.
> 
> When I've been asked to think about including such a feature in Tor in
> the past, I've pointed out that while filtering commands is fairly
> easy, defining a safe subset of the Tor control protocol is not.  The
> problem is that many subsets of the control port protocol are
> sufficient for a hostile application to deanonymize users in
> surprising ways.
> 
> But I could be wrong!  Maybe there are subsets that are safer than others.
> 
> Let me try to illustrate. I'll be looking at a few filter sets for example.
[...]
> Filters from 
> https://git-tails.immerda.ch/tails/tree/config/chroot_local-includes/etc/tor-controlport-filter.d

Small note: we've renamed tor-controlport-filter to onion-grater, to not 
infringe on the Tor trademark. :) 

> 1. onioncircuits.yml
> 
> See onioncircuits.json above; it allows the same GETINFO stuff.

The whole point of onioncircuits is to present all Tor circuit/stream state to 
the users since they (IIRC) feel that Tor is too opaque without this (and I'm 
sure the Tor Browser added its per-tab circuit view for similar reasons). In 
other words, the point of onioncircuits *is* to expose this information. Hence 
I guess this all boils down balancing the security consequences of this (e.g. 
user compromise => full Tor state leak) vs the desired transparency.

As for Tails, my impression of our current threat model here is that we don't 
protect against the main user being compromised, so we certainly won't 
sacrifice the transparency desired by our users to block this leak -- there are 
probably equally bad leaks around already so that sacrifice would be pointless. 
But we are incrementally working towards this by limiting information leaks 
(e.g. control port filtering) and sandboxing applications to protect full user 
compromise so we *do* care about these things. At the point where we feel we 
can start caring about this for real we'll have to revisit this point.

> 2. onionshare.yml
> 
> As above, appears to allow HS_DESC events.

Explanation: modern (ADD_ONION instead of SETCONF HiddenService{Dir,Port}) 
onionshare uses stem's create_ephemeral_hidden_service() with 
`await_publication = True`, which means waiting for the corresponding HS_DESC 
event. I believe the roflcoptor filter was written for the "old" onionshare 
only. 

> It allows "GETINFO
> onions/current", which can expose a list of every onion service
> locally hosted, even those not launched through onionshare.

I think this can be disallowed; in fact, when looking at the onionshare and 
stem sources I don't see why this would ever be used by onionshare.

> 3. tor-browser.yml
> 
> As "tbb.json" above.

Not quite! As intrigeri pointed out, this filter sets `restrict-stream-events: 
true` which gives what meejah called a "limited view" of the STREAM events, 
namely only those "belonging" to the client/controller (implementation: for 
each event look up which PID that has opened the socket with the event's source 
address/port, then match PIDs to determine whether it should be suppressed or 
not).

So, how bad is "GETINFO circuit-status" with only the "limited" STREAM view)? 
Well, by knowing all circuits' exit nodes an attacker that also observes the 
traffic of these exit nodes knows a bit more than what we are comfortable with. 
:/

I guess treating "GETINFO circuit-status" specially with a 
`restrict-circuit-status` option that, when set, suppresses circuits that 
doesn't have any stream belonging to the client. But the same goes for CIRC 
events and "GETINFO stream-status", so, in fact, what about these options:

* restrict-circuit-view: when enabled:
  - "GETINFO circuit-status" will only show circuits that has some stream 
attached that belongs to the controller.
  - CIRC events are dropped unless some stream attached to the circuit in 
question belongs to the controller.
* restrict-stream-view (replacing the current `restrict-stream-events`):
  - "GETINFO stream-status" will only show streams belonging to the controller.
  - STREAM events are dropped unless they belong to the controller.

Does this make sense? What other bits of sensitive internal Tor state 
accessible for controllers have I missed?

BTW, I guess a `restrict-onion-view` would also make sense for HS_DESC events 
and "GETINFO onions/current", but I see no general way to learn what 
application an onion "belongs" to. The filter could keep track of it, but such 
tracking would be lost if restarted (and not tracked at all if the onion was 
added before the filter started). A general solution would depend on little-t 
tor tracking this information, e.g. the PID of the controller that asked for an 
onion to 

Re: [tor-dev] Feedback Extension for Tor Browser

[Sukhbir Singh]

Hello,

> Is the project 'Feedback Extension for Tor Browser' still a part of GSoC
> 2017? I have already submitted a proposal and would like to work on it.
> Please help.

Yes, it is still a part of GSoC. We will let you know if we have any questions
or if there is any feedback on the proposal itself. 

(We can't comment on the status of the proposal during this period as per GSoC
guidelines.)

-- 
Sukhbir
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev