[tor-bugs] #5011 [Pluggable transport]: Discuss possible designs for an external program that discovers bridge addresses to tell Tor about them
Tor Bug Tracker & Wiki
torproject-admin at torproject.org
Tue Mar 13 03:59:25 UTC 2012
#5011: Discuss possible designs for an external program that discovers bridge
addresses to tell Tor about them
---------------------------------+------------------------------------------
Reporter: karsten | Owner: mikeperry
Type: task | Status: new
Priority: normal | Milestone:
Component: Pluggable transport | Version:
Keywords: MikePerry201203 | Parent: #5010
Points: | Actualpoints:
---------------------------------+------------------------------------------
Comment(by mikeperry):
Replying to [comment:11 nickm]:
> That sounds initially plausible to me. I wonder about the
unauthenticated aspect of the "dumb IPC" attribute, though. Historically,
every security feature on control ports turned out to be necessary, and
then some. If an attacker can remotely inject hostile bridges, they could
use that to deanonymize a user.
Yeah, I was sweeping this under the "robust to arbitrary input" rug. I was
thinking that the main risk exposure was that anything automatic could
happen at all. That's why I tried to make sure the confirmation request
came from Vidalia/Orbot..
> So it's important to make sure that this kind of attack won't work.
Yeah, you're right. For best practice, BridgeFinder should create a way
for BridgeFinderHelper to authenticate. I was hoping not to have to solve
that.. What's the best option? Some sort of filesystem-based cookie
authentication? BridgeFinder's simple control port barfs a file path for
BridgeFinderHelper to read from? What about BridgeFinderHelpers that can't
read arbitrary file paths? (I think Chrome extensions fall into this
category).
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5011#comment:12>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list