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

[Robert Ransom <rransom.8774@xxxxxxxxx>]

On 2012-03-23, Arturo Filastà <art@xxxxxxxxxx> wrote:
> 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.

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
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev