Opened 7 years ago

Closed 6 years ago

Last modified 3 years ago

#6546 closed enhancement (wontfix)

Replace check.tp.o with internal mapaddress + JSON/XML object

Reported by: ioerror Owned by:
Priority: Medium Milestone:
Component: Core Tor/Tor Version:
Severity: Keywords: proposal-needed tor-client small-feature
Cc: mikeperry, nickm, weasel, adrelanos@…, isis@…, mcs, brade Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

We need to replace check.torproject.org with something that scales and something that fails closed. I propose that we create a special address that signals a given exit with a DirPort to return a status - like a TorCheck currently does.

Mike have some ideas. This would remove the need for check.torproject.org entirely in our software, at least.

Child Tickets

Change History (38)

comment:1 Changed 7 years ago by mikeperry

Cc: weasel added
Component: - Select a componentTor Client
Milestone: Tor: 0.2.4.x-final
Summary: Replace check with network?Replace check.tp.o with internal mapaddress + JSON/XML object

weasel suggested a fixed mapaddress for a magic IP + port. This would work better than a fixed localhost port I suspect, and yet should still fail closed without a DNS resolution attempt or routing any packets beyond the localhost.

The "page" that is returned could also provide basic status information in an XHTML attribute that would be easy for Torbutton and TorBirdy to read in an XMLHTTPRequest. Something like three states: "Tor is not connected to the Internet", "Tor is bootstrapping", "Tor has successfully created a circuit".

In fact, I don't see why this needs to be a full web page. It could just be a super-simple JSON or XML object that just has a couple attributes that indicate current Tor client state without the need for control port auth.

comment:2 Changed 7 years ago by hellais

I would also like this feature very much (the JSON object so that it can be retrieve via XHR) as we have had to create a middleware to do it for globaleaks.

comment:3 Changed 7 years ago by weasel

I suggested using two things: i) a fixed IP address and port, say 127.234.234.234:5432 or whatever, and ii) a fixed hostname in a namespace we control (something under .torproject.org) that tor would map to a random address in 127/8. Connecting to either would get you a status page.

Testing a connection to (i) would tell us whether we use Tor for our connections, trying (ii) would tell us whether we do DNS resolutions over Tor.

If (i) fails, we don't do (ii).

We could even map the hostname to a real-world static website telling users what went wrong. Since connections go over tor, just not DNS resolution, this shouldn't result in anybody connecting to us directly. If DNS resolutions are misconfigured that would still result in leaking the fact that they try tor onto the network, but I'm not sure if or how that could be fixed.

comment:4 in reply to:  3 Changed 7 years ago by weasel

Replying to weasel:

We could even map the hostname to a real-world static website telling users what went wrong. Since connections go over tor, just not DNS resolution, this shouldn't result in anybody connecting to us directly. If DNS resolutions are misconfigured that would still result in leaking the fact that they try tor onto the network, but I'm not sure if or how that could be fixed.

Not sure that's such a good idea after all. a) the goal is to make this machine usable - no point in having pretty pages that explain things. b) we could still make a static status page if we can't handle NXDOMAIN properly, but we just should. And c) if we are under attack by lying DNS, we can't trust a status page anyway.

For (c) the client that does the check could send a cookie to Tor when it goes to http://127.234.234.234:5432/ (Hi, I'm $name, cookie is $cookie), and when it goes to http://selftest.torproject.org/$name over tor it expects that page to prove it knows $cookie.

I don't know if the dns test is useful at all though.

comment:5 Changed 7 years ago by sysrqb

A couple points: (I'm relatively new so I apologize if any of this has been brought up before)

1) Tor returning a JSON object that contains its current status is a good idea. For TorButton/TorBirdy those three attributes may be the the only ones that are needed, but this could potentially also be a way to query Tor for an up-to-date status and/or statistics (This would obviously be secondary to the purpose of the ticket).

2) People like pretty things, so keeping a status page of some sort is probably not a bad idea :)

2) Going off of weasel's comment, what if every time Tor starts it adds a "first-use-only" mapping of a popular website (www.google.com, www.cnn.com, www.bbc.co.uk, etc) chosen from a static list that will redefined the address to resolve to the local address - this can be handled similar to how Automapping is handled currently. If DNS is being routed through Tor then after this address has been requested for the first time a flag is toggled to indicate that as such and the mapping is removed. If this flag is never flipped then we know Tor isn't being used for DNS resolution. This info can also be added to the JSON response so they can handle resolution differently if they want to.

With this test if anything leaks due to misconfiguration (or whatever else) it simply looks like a normal request instead of something to *.torproject.org which may peek some interest.

comment:6 Changed 7 years ago by nickm

Brief grumbly notes:

  • I'm against Tor-the-program serving HTML here. I'd like fewer orthogonal features crammed into Tor, not more.
  • This IMO needs a design proposal.
  • I'm concerned about cross-site and cross-protocol attacks. I'd like to see some analysis in the proposal about how we can prevent those with this.
  • Tor will export XML only over my dead body. JSON if you must, I guess, though anything that pushes us to the direction of having Tor need to *parse* JSON will make me a sad nickm.

comment:7 Changed 7 years ago by mikeperry

Keywords: proposal-needed added

comment:8 Changed 7 years ago by proper

Cc: adrelanos@… added

And how will the user be informed about TBB updates if check.tpo gets replaced?

comment:9 Changed 7 years ago by proper

Some people tunnel proxies or VPNs through Tor. (user -> Tor -> VPN) Check.tpo or the new replacement will say: "not connected through Tor".

If you implement this, please don't make it a show stopper. People should be allowed to use Tor Browser even if Tor could not be detected. Some about:config variable to override a block would suffice.

comment:10 Changed 7 years ago by mikeperry

Keywords: tbb-usability-SponsorI added

I think the load delay on check is probably actually a huge usability issue for TBB. Having a built-in local version would be a huge win.

comment:11 Changed 7 years ago by mikeperry

Keywords: tbb-usability MikePerry201210d added; tbb-usability-SponsorI removed

weasel: Do you think you'll have a chance to dump your ideas above into a proposal for the 0.2.4.x proposal deadline on Oct 10th? If not, I can give it a shot.

comment:12 in reply to:  11 Changed 7 years ago by weasel

Replying to mikeperry:

weasel: Do you think you'll have a chance to dump your ideas above into a proposal for the 0.2.4.x proposal deadline on Oct 10th? If not, I can give it a shot.

That's quite unlikely. It'd be great if you could do the proposal.

Thanks

comment:13 Changed 7 years ago by nickm

Keywords: tor-client added

comment:14 Changed 7 years ago by nickm

Component: Tor ClientTor

comment:15 Changed 7 years ago by phobos

Keywords: SponsorJ added

comment:16 Changed 7 years ago by mikeperry

Bleh. This article makes me think we can't safely include any cookies/nonces in the JSON output: http://www.hpenterprisesecurity.com/vulncat/en/vulncat/dotnet/javascript_hijacking_vulnerable_framework.html.

Therefore, XML seems to actually be a safer option than JSON for this reason, but we'd still need to be sure you can't access .text or .innerHTML of the content to manually read out the cookie for tracking purposes. Being sure here is tricky, as script tags aren't the only tags that can be cross-origin...

Also, if exits were to DNS rebind to the local 127.x.x.x IP address, they could read out any cookies we use there, too, even in XML.. Tor would need to properly parse Host: headers, at minimum, before handing out cookies, and/or it would need to make such cookies very short-lived...

I'll see if I can capture all of this in the proposal, but this is going to be a lot trickier than we'd hoped if we want to ensure we don't open up holes for tracking users...

comment:17 Changed 7 years ago by nickm

I didn't read the article too closely, but another possible interpretation is that the protocol shouldn't be HTTP. (And IMO it really shouldn't!)

comment:18 Changed 7 years ago by mikeperry

Hrmm, without HTTP, the use of this test is limited to applications where we can create pure sockets and specify the proxy settings for them. Moreover, even where full TCP socket support is provided, this makes testing harder, as you're no longer exercising the same codepaths that your application normally uses by default.

For example, XPCOM's TCP sockets in Firefox do not use your browser's actual proxy settings values. You have to explicitly specify the proxy you want for each TCP connection. While you can in theory pull the proxy settings values from about:config and explicitly specify them for the test connection, this will fail in cases where users have installed filter addons like FoxyProxy, which can alter proxy behavior for specific HTTP requests on the fly...

comment:19 Changed 7 years ago by mikeperry

Google Chrome does not appear to offer proxy support at all for its TCP Socket API for extensions: https://developer.chrome.com/apps/socket.html

comment:20 Changed 7 years ago by nickm

Ow; if it's only useful as http, then I am getting kinda worried about the security implications. I guess we'll know when we have a proposal to analyze, but right now I'm not sure how I'd specify something like this so as to be confident that it wouldn't open security holes.

comment:21 Changed 7 years ago by mikeperry

Yeah, I'm having a hard time. I'll try my best to bake in as much defense in depth into this thing as I can in a rough rough draft.

Forgive me if the draft seems totally sloppy and somewhat disorganized. I'm putting in effort into it proportional to the likelihood that we'll decide this idea is totally impossible to do right. A rough rough draft seems the best plan for this reason.

comment:23 Changed 7 years ago by proper

I like it. No control port connection is required, great, makes it usable in a lot more environments other than TBB. Also nice that no additional listener port is created, magic IP is better. Can't say anything about security.

Maybe adding the IPs of the current circuit should be added?

<entry>xxx.xxx.xxx.xxx</entry>
<middle>xxx.xxx.xxx.xxx</middle>
<exit>xxx.xxx.xxx.xxx</exit>

Do you think people will miss that "your IP appears to be xx.xx.xx"?

comment:24 Changed 7 years ago by mikeperry

Keywords: MikePerry201211d added; MikePerry201210d removed

We need to backpeddle from the DNS nonce and write another simpler proposal without it. Probably should be a separate document, in case we want to try to re-visit the DNS nonce later.

proper: I'm not sure how informational the IP address message will be, especially if we manage to make use of the stream isolation in Tor 0.2.3.x.

comment:25 Changed 7 years ago by mikeperry

Keywords: mumble-feature added

comment:26 Changed 7 years ago by nickm

Keywords: small-feature added; mumble-feature removed

I'm calling this a probable small-feature, with the understanding that the proposal revision needs to happen soon if this is going in 0.2.4.

comment:27 Changed 7 years ago by proper

Related to #7583 "Distribute Tor Browser version and other information through consensus and internal mapaddress + JSON/XML object".

comment:28 Changed 7 years ago by isis

Cc: isis@… added

comment:29 Changed 7 years ago by mikeperry

Keywords: MikePerry201212d added; MikePerry201211d removed

comment:30 Changed 7 years ago by mikeperry

Keywords: MikePerry201212d removed

I don't think it's realistic to expect that I get both Firefox 17-ESR out the door and this done this month, on top of everything else.

comment:31 Changed 7 years ago by nickm

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

comment:32 Changed 7 years ago by brade

Cc: mcs brade added

comment:33 Changed 6 years ago by mikeperry

Keywords: tbb-usability removed

This is no longer a tbb-usability issue. TBB now performs its own control port verification. We simply check that the socks port Tor says its on is the one Firefox is configured to use.

comment:34 Changed 6 years ago by mikeperry

Keywords: SponsorJ removed

comment:35 Changed 6 years ago by lunar

Can't we close that ticket now that TBB has “about:tor” which works nicely?

comment:36 Changed 6 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.???
Resolution: wontfix
Status: newclosed

Being bold and closing. Reopen if lunar is wrong. :)

comment:37 Changed 3 years ago by teor

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

Milestone renamed

comment:38 Changed 3 years ago by nickm

Milestone: Tor: 0.3.???

Milestone deleted

Note: See TracTickets for help on using tickets.