[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #4663 [Tor Client]: Tor proxy settings bypassed when proxy is down/broken
#4663: Tor proxy settings bypassed when proxy is down/broken
---------------------------+------------------------------------------------
Reporter: DasFox | Owner: mikeperry
Type: defect | Status: reopened
Priority: major | Milestone:
Component: Tor Client | Version:
Resolution: | Keywords:
Parent: | Points:
Actualpoints: |
---------------------------+------------------------------------------------
Comment(by nickm):
Replying to [comment:9 mikeperry]:
> Vidalia has a dropdown for proxy type. It sounds like HTTPProxy should
not be an option in this dropdown, then. Aren't directory connections now
tunneled for all Tor clients > 0.2.1.x?
Seems like a good idea. (Vidalia issue.)
Additionally, if the user provides only HTTPSProxy but not HTTPProxy, we
might want to warn if they have configured Tor in such a way that it won't
try to tunnel directory connections. (Tor issue.)
> All of my comments above apply to the Socks5 dropdown, though.
Hm. When I start Tor with "Socks5Proxy 127.0.0.1:badport", Tor fails just
fine. So perhaps this is a Vidalia issue? Or perhaps the socks5proxy
only applies to new connections, and there are already old connections
around that have been built without it?
If it's the latter, I think you could ''maybe'' be able to make a case
that Tor clients ought to kill all currently built connections when the
proxy setting that would have been used to make them has changed. This
would be pretty bad for relays, though. We could mark them as unusable
for new circuits, which would make them die out quickly but avoid
disrupting traffic. (This would be a Tor issue.)
But either way, such a change wouldn't solve the original use case here,
where any non-proxied connection ever is a threat to the user's security.
There is no way that Tor can avoid making non-proxied connections if you
don't set its proxy settings until after it's started making connections.
For a real solution on *that* end, you'd need that UI to do the same trick
we've been discussing for bridges, where you start Tor with DisableNetwork
1, and don't turn off DisableNetwork until the user has had a chance to
set up bridges and proxies. (This would be a frontend issue.)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4663#comment:11>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs