Uniquely Random Access URL

[fpietrosanti]

Following the draft specification for "networked tor2web" as a work in progress on #24 to distribute responsibility between nodes that provide access to the content and node that provide link to access the content (on other server), this feature implement the Unique Random Access URL logic.

In a typical scenario, a user will click on a blahblah.tor2web.org and will get presented with Access Disclaimer as defined on #15 and after acceptance will get redirected to a Uniquely Random Access URL, specific for that client on that server for that period.

This feature represent the foundation for future "networked tor2web" .

This ticket must be better specified following #24 draft.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/14807269-uniquely-random-access-url?utm_campaign=plugin&utm_content=tracker%2F318575&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F318575&utm_medium=issues&utm_source=github).

[evilaliv3]

@virgil: with @fpietrosanti we came to the following idea, that would work like a charm.

1. when accessing http://onion/url the user get redirected to access.tor2web.org#randomsequence that embeds and iframe pointing to random generate url mapping randomsequence:oniondomain e.g. randomsequence.access.tor2web.org; the random mapping has a validity of 1hour if not refreshed.
2. the page access.tor2web.org#randomsequence shows a banner plus an iframe pointing to randomsequence.access.tor2web.org
3. the page at randomsequence.access.tor2web.org would serve the content directly without banner
4. given 1, 2, 3 tor2web should remove x-frame-options from proxified urls on randomsequence.access.tor2web.org in order to embed them into iframe
5. given 1, 2, 3,4 tor2web should add x-frame-options: deny into access.tor2web.org in order to not be embeddable itself in other sites iframes
6. given 1, 2, 3 tor2web could continue to apply the same exact url rewriting and i think schema 1, 2, 3 would be the only one with such an importat capability
7. given 1, 2 3 in order to allow crawling tor2web should eventually allow (if a boolean is set to true) to serve directly the content on current url and without banner to every crawler listed inside a user-agent list; obviously user changing user agent to GoogleBot would see the page without any banner but i do not see any criticism in doing this even from legal point of view because such an action would be identified clearly as an interest to see the page withouth the banner.

\cc @vecna / @hellais what is your thinking? for clarification the main problem we want to solve is to be able to embed a banner not overridable in style and most importan in the content by the owner of the onion url that currently is in possibility to even remove it.

[fpietrosanti]

I think that the randomsequence should: A) contain encoded a timestamp and the destination TorHS B) not be strictly endorced server side like a cookie (not stateful between client and server)

This in order to manage tor2web clusters made up of multiple nodes in DNS round robin where access.tor2web.org goes on Node-1 while randomtoken.access.tor2web.org is resolved to the IP of Node-2

[evilaliv3]

@fpietrosanti: i've mainly two concerns onf your statements A) and B). i got the general idea needed for making a cluster but: i do not get the point for the timestamp and i find it relevant for forensic. i do not find how the url should expire in a stateless approach.

[fpietrosanti]

@evilaliv3 Why it's problematic from the forensic point of view? a) A passive observer already know the timing b) In the browser history of the local PC there is the timing

So it should not be an issue from the forensic point of view, because the timing information should be already on the network and on the browser history.

To make it stateless we can just have the URL to be generated with https://base64(timestamp,torhs).basehost

That way, regardless the Tor2web server that will receive the request due to the DNS Roundrobin, it will be able un "decode" the URL, understand if it has been generated in "the past X hours/days" and which is the destination/target URL.

[evilaliv3]

fabio the url itself it's stateles ok, but what i me create urls valid for the future?

the protection would be to consider valid urls with timestamp<=1day but nothing would deny that a user forges them.

[fpietrosanti]

I don't think we need to enforce it strongly, it's not a problem if it get bypassed. A smart coder would be able to bypass any method that we implement, by automating it programmatically.

For that reason keeping it simpler it's better, the timeout <1day you suggested sounds like a strong enough solution to avoid people spreading on the internet "direct access url", because those would just become unusefull after 1day.

Additionallly we can implement the same check that we implemented to prevent hot linking of CP images from public internet forum, checking that the referral come from something.basehost .

With those two method in place, i think we would reach in a stateless way unique access url that are reasonably accessible only from within the iframe

Sent from mobile

On 08/giu/2015, at 12:51, Giovanni Pellerano notifications@github.com wrote:

fabio the url itself it's stateles ok, but what i me create urls valid for the future?

the protection would be to consider valid urls with timestamp<=1day but nothing would deny that a user forges them.

— Reply to this email directly or view it on GitHub.

[virgil]

As far as I can tell you don't need the random number. The easiest way to stop people from linking directly to the non-iframed version is simply to check the HTTP-Referer. And if the Referer is not *.tor2web.org, redirect to the iframed version.

My personal suggestion is to have two domains akin to what you suggested, call them:

• blah.tor2web.org
• blah.raw.tor2web.org

-- blah.raw.tor2web.org returns the raw page contents, no changes. -- blah.tor2web.org opens an iframe to blah.raw.tor2web.org, injects the banner, and does whatever else you want it to do (rewrite URLs, etc.)

-- if there's a request to blah.raw.tor2web.org that doesn't have the HTTP-Referer of 'blah.tor2web.org', redirect to blah.tor2web.org (the iframed version).

I may be missing something, but this seems straight-forward.

[evilaliv3]

@fpietrosanti i think this would represent for sure the first step as i also find it really straightforward to be implemented. what do you think?

it could represente the first developement step for testing if the iframe solution would really work with no drawbacks

[fpietrosanti]

@evilaliv3 form me it's fine, but it's not the unique-random-url feature of this ticket, but for #137 reported from penetration tests requiring iframe