Opened 8 years ago

Closed 7 years ago

Last modified 7 years ago

#4663 closed defect (fixed)

Tor proxy settings bypassed when proxy is down/broken

Reported by: DasFox Owned by:
Priority: High Milestone: Tor: 0.2.3.x-final
Component: Core Tor/Tor Version:
Severity: Keywords: tor-client
Cc: arma, chiiph, nickm Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I'm using the latest Tor browser bundle for Linux 2.2.34-3 and I've noticed in Vidalia - Settings - Network, you check mark it, 'I use a proxy to access the internet', and place in your address, port and type, then I've had Tor by pass the proxy and get online, at times when there are proxy problems and they won't work to connect through them...

How do I know this happened? Because the message log told me the proxy wasn't able to be connected to, yet Tor still went online, by passing this and I have screen shots below to prove this...

To me the point of using the proxy is that you want or need this and Tor should not be able to just circumnavigate this and get online. If there is a problem with the proxy then Tor should be stopping and not getting online, also this should be designed to give you a popup message or some message/indication in Vidalia.

Also in the Message Log - Advanced, there is no indication, no messages about this connection occurring through the proxy when it's working correctly, it just connects with no indications about any proxy connectivity going on.

The message log is only showing me information when there's a problem, not when things are working correct and a log should be showing all activity and it's not, only when there's a problem. To me this makes me wonder, even if it seems to be working and I see no messages in the log, how do I really know without any indication? This is not good, the log is suppose to show us everything going on...

Here are two screen shots below...

This screen shot shows the connection refused yet it bootstraps and by passes the proxy settings, this should not be happening and getting online, which you see it does from the screen shot below;

http://i.imgur.com/NawOn.png

Now in this screen shot below, it keeps putting information in the log saying it's refused as long as we are connected to Tor, like every few minutes you'll see messages like this fill up in the log, but we still are able to stay online;

http://i.imgur.com/5eAMT.png

I hope the Tor developers can get this fixed soon, this is a critical bug, by passing proxy settings and still getting online...

These are the things that need to be done;

1.If the end-user has a proxy problem and can't connect to it, Vidalia gives you a warning and Tor is stopped and doesn't go online.

  1. The log should show when the proxy is working correctly, you see this connectivity occurring on all levels as a log should be showing you; 'Trying to make a connection' 'connection established', connection disconnected, and so on, besides seeing problems with a connection when those occur...

THANKS

Child Tickets

Attachments (2)

NawOn.png (331.8 KB) - added by rransom 8 years ago.
screenshot
5eAMT.png (327.9 KB) - added by rransom 8 years ago.
screenshot

Download all attachments as: .zip

Change History (29)

comment:1 Changed 8 years ago by rransom

Resolution: invalid
Status: newclosed

Nothing in those images indicates that Tor is bypassing your proxy settings.

It appears that you are trying to use an HTTP/HTTPS proxy which does not allow CONNECT requests to ports other than 443. Tor was able to download directory information from and connect to the Internet through some of the many relays which do listen on port 443; those relays didn't show up in Tor's log because Tor didn't have any trouble connecting to them.

If you had set the ‘FascistFirewall’ torrc option, your Tor client would have found relays which it can access rather more quickly, and without those annoying ‘can't connect’ warning messages. See https://www.torproject.org/docs/faq#FirewallPorts.

Changed 8 years ago by rransom

Attachment: NawOn.png added

screenshot

Changed 8 years ago by rransom

Attachment: 5eAMT.png added

screenshot

comment:2 Changed 8 years ago by DasFox

Hi,

I used a proxy for testing purposes that can't be used with Tor like this, sorry for not explaining this, looking back I thought I did, that is why I picked it to test and show this problem.

So the points now are;

  1. Proxy is not usable, so in Vidalia - Settings - Network, when you check mark it, 'I use a proxy to access the internet', and there's a problem with the proxy Tor should not be bypassing it.
  1. If you just placed something in the Vidalia - Settings - Network - I use a proxy to access the internet and have that check marked, but it's just to test this and make up anything you like and not even have an active proxy working like.

test.proxy.com 8080

And then start Tor, well guess what? Tor starts and this shouldn't be happening either is what I'm trying to point out.

Go ahead and try this, make up a fake proxy and watch Tor go online.

As I mentioned before when you are saying to Tor I want to access through a proxy and there's a problem Tor should stop, give you a popup message and not just go online...

Think about it like this, in Firefox if we use the 'Manual proxy configuration' and it doesn't work, is Firefox by passing this and going online? No...

I've never seen any network types of applications that have proxy settings and if there's a problem by pass it and still connect...

The whole point is, the end-user has a need for this and not to go online without it and by pass it...

I hope this is clear now and I hope the Tor team will fix this...

THANKS

comment:3 Changed 8 years ago by DasFox

Resolution: invalid
Status: closedreopened

Please reopen this and I hope this is fixed because if it's not and an end-user puts in a proxy they want to connect to and there's a problem, the way it is now, you won't know...

THANKS

comment:4 Changed 8 years ago by mikeperry

Cc: arma chiiph nickm added
Component: Tor BrowserTor Client
Keywords: Proxy removed
Priority: criticalmajor
Summary: Tor Browser Bundle Linux - Vidalia - Proxy Settings Getting By PassedTor proxy settings bypassed when proxy is down/broken

I can confirm that if you specify an invalid proxy (I tried a random IP+port) in Vidalia's settings, Tor seems to happily bypass it and connect directly as if nothing was wrong. I didn't even see any log lines at notice or above complaining.

This seems pretty darn bad, but not critical.

comment:5 Changed 8 years ago by DasFox

I just called it critical because people can't really place a value on someone's needs or values to their security and safety...

Many people do use Tor for their safety and security that is why I marked this critical...

Actually, think about some of those Chinese users out there, it's actually a matter of life for some...

It's critical for some and not others...

Cheers

comment:6 Changed 8 years ago by chiiph

Vidalia only issues the SETCONF for the proxy without probing anything, so I think this one is on the tor side.

comment:7 Changed 8 years ago by mikeperry

Hrmm.. I just left my tor client sit for a while with the bogus proxy settings, and then when I came back to it, it was properly failing to make connections through the proxy, but it still wasn't alerting me to this fact. It was just failing circuits.

Maybe there's just some delay before the SETCONF takes effect? Perhaps I still had non-proxied ORCONNs alive to my guard nodes that were being used for new circuits?

comment:8 Changed 8 years ago by nickm

Has anybody figured out _which_ proxy setting is at issue here? Tor has proxy options like this: HTTPSProxy, HTTPProxy, Socks4Proxy, and Socks5Proxy.

As documented in the manpage, HTTPProxy only applies to directory connections, so you would expect OR connections to not use it. HTTPSProxy, Socks4Proxy, and Socks5Proxy all seem to successfully stop Tor from bootstrapping when I specify a nonexistent proxy.

Which one is Vidalia setting here?

comment:9 Changed 8 years ago by 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?

All of my comments above apply to the Socks5 dropdown, though.

comment:10 Changed 8 years ago by DasFox

Ok my bad, so apologize, Socks 4/5 are stopping and it's not going online.

At the top of Vidalia when using Socks 4/5 it would say 'Connecting to Tor network failed (connection refused)

Ok, but there were a few times when I was testing it with Socks 5 that the message log didn't tell me anything, other then there had been no activity, but no other indications of what was going on and no message in Vidalia, so sometimes it's not telling you anything, it's just sitting there.

Ok, http & http/https these are the problems, you put a dummy proxy in those and it gets online...

THANKS

comment:11 Changed 8 years ago by nickm

Replying to 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.)

comment:12 Changed 8 years ago by DasFox

mikeperry I'm not sure what you're trying to say.

You think by passing the HTTP/HTTPS proxy and gettign online without it not a problem?

Or you don't believe this could a threat to someone? If you don't think this could ever pose a security problem, try telling that to the people in China who use Tor to do things their country considers illegal online and need this security and protection, otherwise they'd find themselves in jail. I consider that a real problem...

comment:13 Changed 8 years ago by mikeperry

DasFox: I think Nick is right. I think to support this use case, we need #2905 done.

However, I still think Vidalia should not provide an option for HTTP proxy support. It seems misleading. I have filed #4724 for this.

Nick: I am confused about your statements about HTTPProxy vs HTTPSProxy. It sounds like Tor should remove HTTPProxy from the manpage, and/or just alias it to HTTPSProxy. HTTPSProxy sounds like the only one of the two that will still do anything anymore.

comment:14 in reply to:  13 ; Changed 7 years ago by nickm

Replying to mikeperry:

Nick: I am confused about your statements about HTTPProxy vs HTTPSProxy. It sounds like Tor should remove HTTPProxy from the manpage, and/or just alias it to HTTPSProxy. HTTPSProxy sounds like the only one of the two that will still do anything anymore.

HTTPProxy does *something*; just not something useful to most people. So removing it probably isn't the answer. We should have the manual page emphasize more that it doesn't make all your traffic get proxied, and that it doesn't actually make your directory traffic get proxied if you have tunneled directory connections.

Also, I think we should try harder to detect the case where people configured only httpproxy, but not httpsproxy. I think that 90% of the time, this means that they think they are getting everything proxied when they are not.

Does that make sense?

comment:15 in reply to:  14 Changed 7 years ago by asn

Replying to nickm:

Replying to mikeperry:

Nick: I am confused about your statements about HTTPProxy vs HTTPSProxy. It sounds like Tor should remove HTTPProxy from the manpage, and/or just alias it to HTTPSProxy. HTTPSProxy sounds like the only one of the two that will still do anything anymore.

HTTPProxy does *something*; just not something useful to most people. So removing it probably isn't the answer. We should have the manual page emphasize more that it doesn't make all your traffic get proxied, and that it doesn't actually make your directory traffic get proxied if you have tunneled directory connections.

Also, I think we should try harder to detect the case where people configured only httpproxy, but not httpsproxy. I think that 90% of the time, this means that they think they are getting everything proxied when they are not.

Does that make sense?

Maybe it should also be renamed to DirectoryOnlyHTTPProxy or something? It doesn't seem to be very useful for real users, so renaming it to a lengthy-but-descriptive name shouldn't be too bad.

comment:16 Changed 7 years ago by asn

And if we don't want to lose backwards-compatibility (even though many people who currently use it, are probably using it wrongly), we can:
a) Keep the old name, HTTPProxy, and log an LOG_WARN.
b) Rename it, but log a LOG_WARN, explaining the situation, before dying, when a user attempts to still use HTTPProxy.

comment:17 Changed 7 years ago by mikeperry

Owner: mikeperry deleted
Status: reopenedassigned

comment:18 Changed 7 years ago by arma

Just to be clear, has anybody confirmed that setting the Httpsproxy torrc option does not allow any proxy bypass by Tor? We're all assuming that the original bug reporter just got confused by Vidalia's (bad) interface.

comment:19 in reply to:  18 ; Changed 7 years ago by cypherpunks

Replying to arma:

Just to be clear, has anybody confirmed that setting the Httpsproxy torrc option does not allow any proxy bypass by Tor? We're all assuming that the original bug reporter just got confused by Vidalia's (bad) interface.

I've replicated similar behaviour using Tor v0.2.2.35 and Vidalia 0.2.17 where Tor ignores the configured proxy settings entirely. This only seems to affect a Windows XP SP3 machine.

The XP machine is in front of a firewall which only permits a proxy access to the network. Therefore all attempts for this machine to download the directory are expected to fail. It must make results using the proxy for successful connection.

However when configuring a HTTP\HTTPS proxy - Tor simply ignores the settings and attempts to go direct. Logging doesn't seem to report anything suspicious. I think it's a Tor issue as configuring torrc with 'HTTPProxy' and running Tor direct also has the same issue.

Can confirm Tor goes direct since PCAP shows SYN packets to various directory IP's (unanswered of course). My question - how can force Tor to use its configured proxy?

Thanks :) John Payne

comment:20 in reply to:  19 ; Changed 7 years ago by cypherpunks

Replying to cypherpunks:

Replying to arma:

Just to be clear, has anybody confirmed that setting the Httpsproxy torrc option does not allow any proxy bypass by Tor? We're all assuming that the original bug reporter just got confused by Vidalia's (bad) interface.

I've replicated similar behaviour using Tor v0.2.2.35 and Vidalia 0.2.17 where Tor ignores the configured proxy settings entirely. This only seems to affect a Windows XP SP3 machine.

The XP machine is in front of a firewall which only permits a proxy access to the network. Therefore all attempts for this machine to download the directory are expected to fail. It must make results using the proxy for successful connection.

However when configuring a HTTP\HTTPS proxy - Tor simply ignores the settings and attempts to go direct. Logging doesn't seem to report anything suspicious. I think it's a Tor issue as configuring torrc with 'HTTPProxy' and running Tor direct also has the same issue.

Can confirm Tor goes direct since PCAP shows SYN packets to various directory IP's (unanswered of course). My question - how can force Tor to use its configured proxy?

Thanks :) John Payne

After re-reading, it seems adding 'HTTPSProxy' allows Tor to connect via the proxy, and everything seems tunnelled successfully (it's a Blue Coat ProxySG, so only accepting CONNECT methods on port 443, and SSL interception disabled). It seems if Vidalia wrote HTTPSProxy, that would solve the problem :)

comment:21 Changed 7 years ago by nickm

Milestone: Tor: 0.2.3.x-final

comment:22 in reply to:  20 Changed 7 years ago by arma

Replying to cypherpunks:

It seems if Vidalia wrote HTTPSProxy, that would solve the problem :)

Starting in Vidalia 0.2.16, it does this.

I think we can close this ticket (perhaps duping it to #4724).

comment:23 Changed 7 years ago by nickm

I'd like to try a little harder to keep people from shooting themselves in the foot, if we can. Can we at least say that if you specify HTTPProxy, but no other proxy, we warn you?

comment:24 Changed 7 years ago by nickm

Status: assignedneeds_review

Added the warning in branch "bug4663" in my public repo.

comment:25 Changed 7 years ago by nickm

Resolution: fixed
Status: needs_reviewclosed

Warning still looks trivially correct one day later. Merging it.

comment:26 Changed 7 years ago by nickm

Keywords: tor-client added

comment:27 Changed 7 years ago by nickm

Component: Tor ClientTor
Note: See TracTickets for help on using tickets.