Implement JSONP interface for check.torproject.org
I have made a patch to check.torproject.org to expose a JSONP interface that would allow people to have the user check client side if (s)he is using Tor. This would allow people to embed a badge on their website (privacybadge.html) that congratulates the user of using Tor or warns him of non Tor usage with a link to torproject.org. I can imagine privacy advocates having this deployed on their websites or systems that engourage users to connect to them anonymously. Compared to what check.torproject.org does at the moment the risk does not change, it is erogating exactly the same service, just making it more useful and flexible. Basically what it does is check if the ip doing the connection is connected through Tor. The web service will reply with a JSON encoded array that can be loaded from the user and display in the browser a nice looking badge. You can see how this works on the live demo hosted here: http://hellais.github.com/torcheck/privacybadge.html I still need to finish the styling of the badge to contain links to torproject.org and generally make it cooler. Also, the check.torproject repo should be moved to svn. - Art.
On 11/05/2011 06:26 PM, Arturo Filastò wrote:
I have made a patch to check.torproject.org to expose a JSONP interface that would allow people to have the user check client side if (s)he is using Tor.
This would allow people to embed a badge on their website (privacybadge.html) that congratulates the user of using Tor or warns him of non Tor usage with a link to torproject.org.
I can imagine privacy advocates having this deployed on their websites or systems that engourage users to connect to them anonymously.
Compared to what check.torproject.org does at the moment the risk does not change, it is erogating exactly the same service, just making it more useful and flexible.
Basically what it does is check if the ip doing the connection is connected through Tor. The web service will reply with a JSON encoded array that can be loaded from the user and display in the browser a nice looking badge.
I think this is a fine idea - it reminds me of the only IPv6 demo turtle. I think it's quite ironic to use these technologies to encourage people to deploy real privacy solutions.
You can see how this works on the live demo hosted here:
I'd suggest that it have an onion and say "You're using Tor" or something similar - it might also make sense to put it in the web 2.0 web badge format that many companies use.
I still need to finish the styling of the badge to contain links to torproject.org and generally make it cooler.
Also, the check.torproject repo should be moved to svn.
Isn't it already in svn? Shouldn't we move it to git? All the best, Jake
On 11/05/2011 06:26 PM, Arturo Filastò wrote:
I have made a patch to check.torproject.org to expose a JSONP interface that would allow people to have the user check client side if (s)he is using Tor.
This would allow people to embed a badge on their website (privacybadge.html) that congratulates the user of using Tor or warns him of non Tor usage with a link to torproject.org.
I can imagine privacy advocates having this deployed on their websites or systems that engourage users to connect to them anonymously.
Compared to what check.torproject.org does at the moment the risk does not change, it is erogating exactly the same service, just making it more useful and flexible.
Basically what it does is check if the ip doing the connection is connected through Tor. The web service will reply with a JSON encoded array that can be loaded from the user and display in the browser a nice looking badge.
I think this is a fine idea - it reminds me of the only IPv6 demo turtle.
I think it's quite ironic to use these technologies to encourage people to deploy real privacy solutions.
I also like the idea, but I immediately thought of nefarious uses for such an API. No more nefarious than what one can do with a proper list of exit nodes I suppose. Is there any general difference between having a queryable API to determine if a client is using Tor and the periodic fetching of the list of exit nodes? Apologies if this isn't a particularly -dev-like question, I'm still fresh on a lot of the Tor internals and I'm still not sure what data is public versus protected. Cheers.
On 11/08/2011 12:29 AM, warms0x wrote:
On 11/05/2011 06:26 PM, Arturo Filastò wrote:
I have made a patch to check.torproject.org to expose a JSONP interface that would allow people to have the user check client side if (s)he is using Tor.
This would allow people to embed a badge on their website (privacybadge.html) that congratulates the user of using Tor or warns him of non Tor usage with a link to torproject.org.
I can imagine privacy advocates having this deployed on their websites or systems that engourage users to connect to them anonymously.
Compared to what check.torproject.org does at the moment the risk does not change, it is erogating exactly the same service, just making it more useful and flexible.
Basically what it does is check if the ip doing the connection is connected through Tor. The web service will reply with a JSON encoded array that can be loaded from the user and display in the browser a nice looking badge.
I think this is a fine idea - it reminds me of the only IPv6 demo turtle.
I think it's quite ironic to use these technologies to encourage people to deploy real privacy solutions.
I also like the idea, but I immediately thought of nefarious uses for such an API. No more nefarious than what one can do with a proper list of exit nodes I suppose.
It is a real time version of this - powered by... a Tor client. :)
Is there any general difference between having a queryable API to determine if a client is using Tor and the periodic fetching of the list of exit nodes?
No, not for a user who is using Tor - the exiting from the network is generally considered "Tor" and we've supported this to help quash crappy attempts: https://check.torproject.org/cgi-bin/TorBulkExitList.py (note the svn link, it's actually code anyone may run) In other words, we'd like everyone to enter the Tor network - we won't help block _entry_ into Tor. But generally, it's OK if some people block Tor exits as the anonymous user can just go somewhere else...
Apologies if this isn't a particularly -dev-like question, I'm still fresh on a lot of the Tor internals and I'm still not sure what data is public versus protected
It's not private information. The biggest problem with this proposal is simply that many people may use it and it will generate a lot of load. All the best, Jacob
(Off-list reply to avoid unnecessary archive bits :)) Thanks for the clarification, I wasn't even aware of the bulk exit exporter! Cheers.
Resurrecting a thread from the grave!
I have made a patch to check.torproject.org to expose a JSONP interface that would allow people to have the user check client side if (s)he is using Tor.
This would allow people to embed a badge on their website (privacybadge.html) that congratulates the user of using Tor or warns him of non Tor usage with a link to torproject.org.
I can imagine privacy advocates having this deployed on their websites or systems that engourage users to connect to them anonymously.
Compared to what check.torproject.org does at the moment the risk does not change, it is erogating exactly the same service, just making it more useful and flexible.
Basically what it does is check if the ip doing the connection is connected through Tor. The web service will reply with a JSON encoded array that can be loaded from the user and display in the browser a nice looking badge.
Since I noticed that check.tpo was removed from the front page I was thinking it would be a good idea to bring back up the topic of migrating check.torproject.org to a JSONP based system. Such a system would also allow to have the "JSONP check nodes" distributed across multiple machines (avoiding the single point of failure that check currently is) and the client side software could be embedded inside of TBB directly. People could further promote the usage of Tor by placing an "Anonymity" badge on their website. A person wishing to setup such a node needs to simply install TorBel and a python based web app that runs this JSONP system. My threat model for this is very lax, so I don't see any purpose in bad actors telling a client when he is not using Tor that he is using it. If check.tpo tells the user is not using Tor it already means that TBB failed, the purpose of it is just to provide visual feedback to the user that all is did went well.
I still need to finish the styling of the badge to contain links to torproject.org and generally make it cooler.
Also, the check.torproject repo should be moved to svn.
Isn't it already in svn? Shouldn't we move it to git?
If check is moved to git and you think it is a good idea I can start working on this. - Art.
On 2012-03-23, Arturo Filastò <art@baculo.org> wrote:
Since I noticed that check.tpo was removed from the front page I was thinking it would be a good idea to bring back up the topic of migrating check.torproject.org to a JSONP based system.
JSONP gives the party which is expected to provide a piece of data the ability to run arbitrary JavaScript code in the security context of the website which requested the data. The Tor Project should never put itself in a position to have that level of control over other parties' websites.
Such a system would also allow to have the "JSONP check nodes" distributed across multiple machines (avoiding the single point of failure that check currently is) and the client side software could be embedded inside of TBB directly.
People could further promote the usage of Tor by placing an "Anonymity" badge on their website.
A person wishing to setup such a node needs to simply install TorBel and a python based web app that runs this JSONP system.
My threat model for this is very lax, so I don't see any purpose in bad actors telling a client when he is not using Tor that he is using it. If check.tpo tells the user is not using Tor it already means that TBB failed, the purpose of it is just to provide visual feedback to the user that all is did went well.
check.torproject.org is the only service which can warn Tor users that a security upgrade is available for the Tor Browser Bundle. It is also accessed by every Tor Browser Bundle as the first page shown after the user uses the ‘New Identity’ Torbutton command; any party which can impersonate check.torproject.org can plant user-tracking cookies in every TBB user's browser. check.torproject.org cannot ever be run by untrusted parties, and cannot ever use a JSONP service provided by untrusted parties.
If check is moved to git and you think it is a good idea I can start working on this.
It is a more horrible idea now than it was the first time you proposed it. Robert Ransom
On 3/23/12 4:34 PM, Robert Ransom wrote:
On 2012-03-23, Arturo Filastò <art@baculo.org> wrote:
Since I noticed that check.tpo was removed from the front page I was thinking it would be a good idea to bring back up the topic of migrating check.torproject.org to a JSONP based system. JSONP gives the party which is expected to provide a piece of data the ability to run arbitrary JavaScript code in the security context of the website which requested the data. The Tor Project should never put itself in a position to have that level of control over other parties' websites.
If this is a concern, and I don't think it is since Tor Project already has the ability to get users to run arbitrary code when they first start their browser, it could be managed by having the badge loaded on third party websites inside of an IFRAME. This would mean that the execution of anything is relative to that IFRAME. An alternative to using the JSONP object would be to do a XHR with "Access-Control-Allow-Origin: *". This is only supported since firefox 3.5, but I don't think it would be an issue for TBB. A XHR does not lead to any code execution and all that the rogue node can do is tell the client that he is not running Tor.
Such a system would also allow to have the "JSONP check nodes" distributed across multiple machines (avoiding the single point of failure that check currently is) and the client side software could be embedded inside of TBB directly.
People could further promote the usage of Tor by placing an "Anonymity" badge on their website.
A person wishing to setup such a node needs to simply install TorBel and a python based web app that runs this JSONP system.
My threat model for this is very lax, so I don't see any purpose in bad actors telling a client when he is not using Tor that he is using it. If check.tpo tells the user is not using Tor it already means that TBB failed, the purpose of it is just to provide visual feedback to the user that all is did went well. check.torproject.org is the only service which can warn Tor users that a security upgrade is available for the Tor Browser Bundle.
Good point. I had not considered this aspect. Though wouldn't this be replaced by thandy in the future? Are we sure the best way to inform users of updates is through check.tpo?
It is also accessed by every Tor Browser Bundle as the first page shown after the user uses the ‘New Identity’ Torbutton command; any party which can impersonate check.torproject.org can plant user-tracking cookies in every TBB user's browser.
With the XHR solution this would not be an issue anymore.
check.torproject.org cannot ever be run by untrusted parties, and cannot ever use a JSONP service provided by untrusted parties.
I disagree. If we properly define what the threat model is I am sure we can figure out a way to make a solution that fits it. The overall question is, currently check.tpo is a centralized single point of failure. Can we do better? Is there a way to run a distributed infrastructure of this kind?
If check is moved to git and you think it is a good idea I can start working on this. It is a more horrible idea now than it was the first time you proposed it.
Heh, I appreciate your comments, although you are often a bit rough :P. - Art.
On 2012-03-23, Arturo Filastò <art@baculo.org> wrote:
On 3/23/12 4:34 PM, Robert Ransom wrote:
On 2012-03-23, Arturo Filastò <art@baculo.org> wrote:
Since I noticed that check.tpo was removed from the front page I was thinking it would be a good idea to bring back up the topic of migrating check.torproject.org to a JSONP based system. JSONP gives the party which is expected to provide a piece of data the ability to run arbitrary JavaScript code in the security context of the website which requested the data. The Tor Project should never put itself in a position to have that level of control over other parties' websites.
If this is a concern, and I don't think it is since Tor Project already has the ability to get users to run arbitrary code when they first start their browser, it could be managed by having the badge loaded on third party websites inside of an IFRAME.
Not everyone who would visit a website which displays this ‘badge’ will use Tor Browser Bundle.
This would mean that the execution of anything is relative to that IFRAME.
An alternative to using the JSONP object would be to do a XHR with "Access-Control-Allow-Origin: *". This is only supported since firefox 3.5, but I don't think it would be an issue for TBB.
The ‘badge’ is intended to be seen by people who do not use Tor yet.
A XHR does not lead to any code execution and all that the rogue node can do is tell the client that he is not running Tor.
Such a system would also allow to have the "JSONP check nodes" distributed across multiple machines (avoiding the single point of failure that check currently is) and the client side software could be embedded inside of TBB directly.
People could further promote the usage of Tor by placing an "Anonymity" badge on their website.
A person wishing to setup such a node needs to simply install TorBel and a python based web app that runs this JSONP system.
My threat model for this is very lax, so I don't see any purpose in bad actors telling a client when he is not using Tor that he is using it. If check.tpo tells the user is not using Tor it already means that TBB failed, the purpose of it is just to provide visual feedback to the user that all is did went well. check.torproject.org is the only service which can warn Tor users that a security upgrade is available for the Tor Browser Bundle.
Good point. I had not considered this aspect. Though wouldn't this be replaced by thandy in the future?
Feel free to split up the TBB build process and prepare its configuration files to be automatically updated. Then feel free to audit Thandy and, at the very least, make it stop writing temporary files outside the TBB directory. Then feel free to audit Python and PyInstaller and, at the very least, make the Python interpreter stop trying to load and execute files in the current directory which happen to have the same name as a Python standard library module which the program the user is trying to run needs to load. I don't expect Python or any Python program to ever be safe to deploy.
Are we sure the best way to inform users of updates is through check.tpo?
The only service which can issue a warning to users of currently deployed versions of TBB is check.tpo, regardless of whether future versions of TBB also rely on a different single point of failure.
It is also accessed by every Tor Browser Bundle as the first page shown after the user uses the ‘New Identity’ Torbutton command; any party which can impersonate check.torproject.org can plant user-tracking cookies in every TBB user's browser.
With the XHR solution this would not be an issue anymore.
check.torproject.org cannot ever be run by untrusted parties, and cannot ever use a JSONP service provided by untrusted parties.
I disagree. If we properly define what the threat model is I am sure we can figure out a way to make a solution that fits it.
Oh, you want a threat model! I don't have a complete threat model for check.tpo, but here are some absolute requirements: * An attacker MUST NOT be able to falsely tell someone who is not connecting through Tor and who is not connecting from the same IP address as a Tor exit node that he/she/it is connecting through Tor. (Currently, a Chrome user's last hope of avoiding complete proxy bypass is that Chrome will connect to check.tpo over IPv6 *directly*, and be told either that he/she/it is not connecting through Tor or that check.tpo is not working.) * An attacker MUST NOT be able to trick users into downloading a malicious update by placing a link to a malicious website on check.tpo. * An attacker MUST NOT be able to plant tracking cookies in a user's TBB immediately after the user uses the ‘New Identity’ TorBrowserButton command. * An attacker MUST NOT be able to scare or endanger a user by sending malicious content to be displayed by the user's browser. (Some examples of content that would ‘scare’ are text claiming that the user's computer has a virus, text falsely claiming that Tor is unsafe to use, advertisements or images or text crafted to look like advertisements, and text claiming that the user has been identified and traced by <insert name of bogeyman here> and will soon be arrested. Some examples of content that would ‘endanger’ are text claiming that the user's computer has a virus and the user should download and run a particular program to remove it, images whose possession are illegal in most jurisdictions, videos with audio intended to draw attention to the user, videos with loud audio intended to damage the user's audio hardware or the user, JavaScript which flashes the screen rapidly in order to draw attention to the user, and JavaScript which flashes the screen at 4 Hz in order to kill vulnerable users.) (Note that the malicious texts are far more likely to be effective if they appear to originate from check.torproject.org.) Hmm. I suddenly have an urge to turn off JavaScript and HTML 5 video/audio support in my browser.
The overall question is, currently check.tpo is a centralized single point of failure. Can we do better? Is there a way to run a distributed infrastructure of this kind?
Tor clients could intercept connection attempts for http://check.torproject.org/ and handle them internally. They cannot do the same for HTTPS without horrible flaky scary hacks. I thought there was a Trac ticket for that feature, but I can't find it now. Robert Ransom
Oh, I forgot to mention one requirement: check.torproject.org must be usable by people who have turned off JavaScript in their browser (whether TBB or not). That rules out XmlHttpRequest. Robert Ransom
participants (4)
-
Arturo Filastò -
Jacob Appelbaum -
Robert Ransom -
warms0x