Opened 9 years ago

Closed 2 years ago

#2106 closed enhancement (duplicate)

Controller can't unset httpsproxy if it doesn't resolve

Reported by: arma Owned by:
Priority: High Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-client, easy
Cc: chiiph, erinn Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

If you use Vidalia to setconf your httpsproxy, Tor will use that httpsproxy. If you're on a laptop though and you shutdown and start up Tor on a different network, where you don't want to be using that httpsproxy (and where it doesn't resolve), Tor won't start. There's no way for the controller to unset the httpsproxy, because the way the controller approach is designed you start up Tor and then setconf the new config choices.

The result: there's no way to stop using an httpsproxy if you're in an environment that can't resolve the one you configured earlier.

See also
https://trac.vidalia-project.net/ticket/303

Is this something that can be fixed inside Tor (e.g. by not failing)? Or do we need to change the controller recommendations to be able to edit your torrc for you before starting Tor? Poor options all around.

I'm not sure if this should be in the Tor Client component or the Vidalia component. Picking Tor for now.

Child Tickets

Change History (22)

comment:1 Changed 9 years ago by nickm

Milestone: Tor: 0.2.3.x-final

comment:2 Changed 8 years ago by arma

Priority: normalmajor

comment:3 Changed 8 years ago by arma

Cc: chiiph erinn added

Here's another instance:

1) Download vanilla TBB. Run it. Click sharing, become a relay, click ok. Great. Exit TBB.

2) nc -l -p 9001 (or whatever port your relay wants to use).

3) Run TBB again. It will launch Tor, which will try to bind to the port, and fail. Vidalia will pop up windows about not being able to connect to Tor. Fine. Check the advanced message log, see that it's because Tor couldn't bind to 9001. Click sharing, become a client, click ok. Exit and restart TBB. Same Vidalia popups, except now when you click sharing you're already a client! Vidalia thinks you're a client but Tor thinks you're a relay. Vidalia can't start Tor to change Tor's mind. You have to rm -rf the whole thing and start over.

This just bit a user on #tor.

comment:4 Changed 8 years ago by arma

We need to brainstorm about how to resolve this issue. I'm not sure what component (Vidalia, Tor, bundles) is best. It probably ties in all of them.

comment:5 Changed 8 years ago by arma

One near-term hack might be for Vidalia to recognize that Tor isn't starting, guess it's because of broken config options, and ask the user if she wants to reset Tor to its default torrc.

comment:6 Changed 8 years ago by chiiph

That hack might work, but what happens when Tor doesn't start for any of the other reasons? We may reset the user's super custom config, but it failed because the internet was down at that particular moment.
One idea would be to make it a "two strike" startup, if it fails after the reseting, then just fail as usual, but the above problem will remain.

Another possibility, but on the tor side, would be to signal tor (I'm not sure which signals aren't in use) for this special case... But this won't work on Windows, right?

I may be lacking some low level knowledge here, is Vidalia doing something wrong when changing from relay to client in terms of controport commands? Is this something that can be reproduced through a "plain" controlport connection?

comment:7 Changed 8 years ago by nickm

So, the simplest option here would probably be to do name lookup later when we're about to connect to the httpsproxy. Or, instead of calling the configuration unusable, treat it as having configured a magic https proxy that always fails.

Either way, these are feeling pretty big; unless somebody comes up with a simple isolated fix, it might be better off talking about design now and doing a well considered fix in 0.2.4.x

comment:8 Changed 7 years ago by nickm

treat it as having configured a magic https proxy that always fails.

Actually, these are not too bad! If the lookup for some option like this (HTTPProxy, HTTPSProxy,Socks4Proxy,Socks5Proxy) fails, we can just set it to some "doesn't work" value. Later, we can detect this value when we're about to connect, and reject any attempt to connect to that address. We can also set a "the network is down" field if any of those fails at configuration time.

Still, this feels like an 0.2.4.x thing. Can we let it slip till then?

comment:9 in reply to:  8 Changed 7 years ago by arma

Replying to nickm:

Still, this feels like an 0.2.4.x thing. Can we let it slip till then?

If we need to, yes. It's broken in 0.2.2 already, so it's not like it's a regression.

comment:10 Changed 7 years ago by nickm

Milestone: Tor: 0.2.3.x-finalTor: 0.2.4.x-final

comment:11 Changed 7 years ago by nickm

Keywords: tor-client added

comment:12 Changed 7 years ago by nickm

Component: Tor ClientTor

comment:13 Changed 7 years ago by nickm

Milestone: Tor: 0.2.4.x-finalTor: 0.2.5.x-final
Type: defectenhancement

comment:14 Changed 5 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.???

comment:15 in reply to:  8 Changed 4 years ago by arma

Severity: Normal

Replying to nickm:

treat it as having configured a magic https proxy that always fails.

Actually, these are not too bad! If the lookup for some option like this (HTTPProxy, HTTPSProxy,Socks4Proxy,Socks5Proxy) fails, we can just set it to some "doesn't work" value. Later, we can detect this value when we're about to connect, and reject any attempt to connect to that address. We can also set a "the network is down" field if any of those fails at configuration time.

This approach still looks a lot better than leaving it broken. It also looks like a bite-sized patch for somebody who wants to contribute. Anybody up for it? :)

comment:16 Changed 4 years ago by teor

Keywords: easy added

comment:17 Changed 3 years ago by arma

We just had a user on #tor who was bitten by this bug -- they configured a proxy for their tor browser, then took the laptop to another network, and now Tor Browser can't start Tor.

comment:18 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:19 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:20 Changed 3 years ago by neerajbattan

arma: I would like to work on this bug, where are the values for HTTPProxy, HTTPSProxy,Socks4Proxy,Socks5Proxy stored and what value should I change to when tor unable to connect to this proxy set?

comment:21 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:22 Changed 2 years ago by nickm

Resolution: duplicate
Status: newclosed

Duplicate of #449

Note: See TracTickets for help on using tickets.