Opened 8 years ago

Closed 8 years ago

#4031 closed defect (fixed)

Firefox fails to find SOCKS proxy after tor is restarted through Vidalia

Reported by: rpw Owned by: chiiph
Priority: Medium Milestone:
Component: Archived/Vidalia Version:
Severity: Keywords:
Cc: chiiph, nickm, arma, erinn Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

The Tor Browser Bundle version 2.2.34-4 on Linux uses the SocksPort auto setting in torrc. After restarting tor through the Vidalia interface, a new control port and a new SOCKS port are chosen while Firefox still uses the old SOCKS port. This causes "Connection refused" errors in Firefox.

Steps to reproduce:

1) Start Tor browser bundle
2) Random browsing
2) Click "Stop Tor" button in Vidalia Control Panel
3) Click "Start Tor" button in Vidalia Control Panel
4) Open any URL

Expected result: URL can be opened normally
Actual result: "Connection refused" error message

Suggestion for the fix on #tor-dev was:

!00:42 < armadev> vidalia could also fix it by memorizing the socks and control port (it does this anyway so it can tell firefox when it launches it),
!00:42 < armadev> and restarting tor with the same ports it picked the first time

Child Tickets

Change History (15)

comment:1 Changed 8 years ago by rpw

My brain is a very leaky bucket. The error message of course was: "The proxy server is refusing connections" and not "Connection refused".

Also, for completeness a step 3.5) Wait until Vidalia shows "Connected to the Tor network!" should be added.

comment:2 Changed 8 years ago by erinn

Cc: chiiph nickm arma added
Component: Tor BrowserTor bundles/installation
Owner: changed from mikeperry to erinn

Changing the component since this is TBB (TorBrowser is our hax0red Firefox, the component name is confusing) and adding chiiph, nickm, and arma to this, because it isn't clear whether it should be fixed in Vidalia or Tor. Or TBB itself, somehow.

comment:3 Changed 8 years ago by chiiph

I think the reasonable fix for this given how things are intended to work would be in the Vidalia side.
But, may be this is something similar to the other issue of "try the usual ports first, if those fail, go random". Would it be too crazy for this to be in the tor side? I'm thinking something like: ControlPort auto:9050, will try 9050 first and if that fails it goes random (or ControlPort 9050,auto).

comment:4 Changed 8 years ago by mikeperry

Component: Tor bundles/installationTor Client
Owner: changed from erinn to nickm
Status: newassigned

nickm might not be getting trac Cc mails.. there are a few other tickets I've tried to add him as Cc on that have fallen into the abyss waiting for a response. I'm going to try assigning it to him so it shows up on his trac reports.

comment:5 Changed 8 years ago by nickm

It's not about CC; it's about component. I get *all* trac emails, and generally don't the ones that are for software I don't work on. If you label something as a vidalia bug, or a TBB bug, I will assume that chiiph or helix is taking care of it.

On to the bug:

If Tor can pick a new socks port when it restarts (and it is allowed to if you say "socksPort auto"), then it seems to me that vidalia or whatever restarts tor needs some way to tell firefox about it.

Now, there's a good argument that Tor should try harder to re-use the same port as it used last time... and that's something I'd like to implement. But with SocksPort auto, there is no way to guarantee that at all.

So if we're using socksport auto, and Tor restarts, we need to be able to tell everything that cares about the new socksport.

comment:6 Changed 8 years ago by nickm

BTW, it is not okay to guess what the control port is and connect to other stuff until you find the control port. Doing so will open you up to MITM, it would seem.

comment:7 Changed 8 years ago by rransom

Cc: erinn added
Component: Tor ClientTor bundles/installation

Erinn: You missed three comments.

comment:8 Changed 8 years ago by mikeperry

Component: Tor bundles/installationTor Client

nick - we have no persistent IPC channel between vidalia and Firefox in order to inform Torbutton of new port pairs. We're using environment variables for the purpose now..

I think having some way to have Tor either prefer ports, or be smarter about trying to reusing them is the least-effort most-gain for this particular issue. Alternatively, maybe Vidalia could be the one who tells Tor "this was your port from before the restart" using command line arguments for ControlPort and SocksPort to override the torrc auto options from disk. The tor manpage says this is possible. Is it a good idea? Is it the best idea (that doesn't involve new IPC)?

rransom - erinn normally reads Ccs. Also, I still think this is best solved in the Tor Client or Vidalia. I certainly don't think anything in the build/packaging is going to solve this.

comment:9 Changed 8 years ago by nickm

I think having some way to have Tor either prefer ports, or be smarter about trying to reusing them is the least-effort most-gain for this particular issue.

So, above I tried to explain why I don't think this is actually a fix here. My argument was that if Tor is allowed to change its ports, then other programs need to be able to handle it when Tor changes its ports. If we're telling Tor "Don't change your ports unless you really have to", then we have to handle the case where Tor decides that it really has to, right? Otherwise we're not fixing this bug; we're just making it less common.

Am I going wrong someplace in the above reasoning?

(Also, trying to make ports stable across Tor restarts is probably not an easy fix to implement, because of the fact that you can listen to more than one of them. If this needs to get fixed soon in 0.2.2.x, I'd be worried about destabilizing Tor to implement it.)

Alternatively, maybe Vidalia could be the one who tells Tor "this was your port from before the restart" using command line arguments for ControlPort and SocksPort to override the torrc auto options from disk.

This seems like a good idea to me. It's got the advantage that it means what it says: if Tor can't reuse the same port, Tor should fail to start up, since Firefox can't cope.

comment:10 in reply to:  8 ; Changed 8 years ago by rransom

Replying to mikeperry:

nick - we have no persistent IPC channel between vidalia and Firefox in order to inform Torbutton of new port pairs. We're using environment variables for the purpose now..

I think having some way to have Tor either prefer ports, or be smarter about trying to reusing them is the least-effort most-gain for this particular issue.

Not on 0.2.2.x.

Alternatively, maybe Vidalia could be the one who tells Tor "this was your port from before the restart" using command line arguments for ControlPort and SocksPort to override the torrc auto options from disk. The tor manpage says this is possible. Is it a good idea? Is it the best idea (that doesn't involve new IPC)?

If you do not add an IPC mechanism, an attacker could grab Tor's old SOCKS and control ports, and Torbutton would continue to connect to them.

It might be easier to teach Torbutton to launch and control a Tor instance on its own. Tomas has been working with QtScript for Vidalia's plugin system; how hard could it be for him to start hacking a Firefox extension?

rransom - erinn normally reads Ccs.

She was not on the CC list until I added her to it.

Also, I still think this is best solved in the Tor Client or Vidalia. I certainly don't think anything in the build/packaging is going to solve this.

It is a bundle integration problem. Once you and Tomas make Vidalia tell Torbutton Tor's new port numbers (or find some other solution), Erinn will need to configure your code to actually work in TBB (and nowhere else).

The Tor feature you think you want will not be added to Tor on the 0.2.2.x branch.

comment:11 in reply to:  10 Changed 8 years ago by nickm

Replying to rransom:

The Tor feature you think you want will not be added to Tor on the 0.2.2.x branch.

Make that, "will probably not."

It's a new feature, and I think it'll be tricky to do right, and it touches parts of the code that historically have broken in a subtle way for at least one or two releases every time I've tried to touch 'em, *and* it touches parts of the code that have started to diverge between 0.2.2.x and 0.2.3.x.

None of those is an absolute "we could never ever do this" marker, but individually and together they make me want to avoid trying to do this in Tor 0.2.2.x if there's any way we can avoid it.

comment:12 Changed 8 years ago by arma

I think the clear correct fix is for Vidalia to remember what ports it learned from Tor's ports file (it has to remember them anyway to tell Firefox), and if it finds itself starting Tor again, say those ports to Tor on the commandline rather than saying auto. It will do exactly what we want.

If Tor fails to bind to the ports, then you're in a position where the Firefox you've already launched cannot talk to the ports it must talk to. At that point you give up.

Now, rransom had an interesting point which is "if Tor goes away, some other evil thing could bind those ports in the mean time and now Firefox is talking to the evil thing". I'm actually not so worried about that. I mean, maybe it's a problem, but it's been a problem for a long time. If we are worried about it, the answer is that either Vidalia or Torbutton should kill Firefox when Tor goes away. There would be some usability issues here.

comment:13 Changed 8 years ago by mikeperry

Component: Tor ClientVidalia

chiiph - Looks like this one just fell in your lap.

comment:14 Changed 8 years ago by mikeperry

Owner: changed from nickm to chiiph

Trac... *sigh*

comment:15 Changed 8 years ago by chiiph

Resolution: fixed
Status: assignedclosed

A fix for this is in my branch chiiph/bug4031_rememberports, which has been merged to alpha and it'll go out with 0.3.1-alpha.

Note: See TracTickets for help on using tickets.