Replace check.tp.o with internal mapaddress + JSON/XML object
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.
Activity
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.
Trac:
Milestone: N/A to Tor: 0.2.4.x-final
Cc: mikeperry, nickm to mikeperry, nickm, weasel
Component: - Select a component to Tor Client
Summary: Replace check with network? to Replace check.tp.o with internal mapaddress + JSON/XML object
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.
-
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.
A couple points: (I'm relatively new so I apologize if any of this has been brought up before)
-
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).
-
People like pretty things, so keeping a status page of some sort is probably not a bad idea :)
-
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.
-
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.
And how will the user be informed about TBB updates if check.tpo gets replaced?
Trac:
Cc: mikeperry, nickm, weasel to mikeperry, nickm, weasel, adrelanos@riseup.netSome 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.
-
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
-
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...
-
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...
-
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
-
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.
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?
xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx xxx.xxx.xxx.xxx
Do you think people will miss that "your IP appears to be xx.xx.xx"?
-
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.
Trac:
Keywords: proposal-needed tbb-usability MikePerry201210d tor-client SponsorJ deleted, proposal-needed tbb-usability MikePerry201211d tor-client SponsorJ added -
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.
Trac:
Keywords: proposal-needed tbb-usability MikePerry201211d tor-client SponsorJ mumble-feature deleted, proposal-needed tbb-usability MikePerry201211d tor-client SponsorJ small-feature added Related to #7583 (moved) "Distribute Tor Browser version and other information through consensus and internal mapaddress + JSON/XML object".
Trac:
Cc: mikeperry, nickm, weasel, adrelanos@riseup.net to mikeperry, nickm, weasel, adrelanos@riseup.net, isis@torproject.org-
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.
Trac:
Keywords: proposal-needed tbb-usability MikePerry201212d tor-client SponsorJ small-feature deleted, proposal-needed tbb-usability tor-client SponsorJ small-feature added 
Trac:
Cc: mikeperry, nickm, weasel, adrelanos@riseup.net, isis@torproject.org to mikeperry, nickm, weasel, adrelanos@riseup.net, isis@torproject.org, mcs, brade-
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.
Trac:
Keywords: proposal-needed tbb-usability tor-client SponsorJ small-feature deleted, proposal-needed tor-client SponsorJ small-feature added mentioned in issue #6821 (moved)
mentioned in issue #7494 (closed)
mentioned in issue #7583 (moved)
mentioned in issue #8472 (closed)
mentioned in issue #8640 (closed)
moved to tpo/core/tor#6546 (closed)
mentioned in issue tpo/applications/tor-browser#7583 (closed)
