Re: [tor-dev] Implement JSONP interface for check.torproject.org

[Arturo Filastà <art@xxxxxxxxxx>]

On 3/23/12 4:34 PM, Robert Ransom wrote:
> On 2012-03-23, Arturo Filastà <art@xxxxxxxxxx> 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.

_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev