Drop tor2web traffic to prevent possible leaks

[dolanjs]

Drop the tor2web user-agent to prevent possible leaks.

[klpwired]

Dropping tor2web traffic entirely closes off sources who would leak from computers where they don't have admin rights, e.g., public library computers, where they can't install Tor or boot into Tails.

Instead, why not detect the user-agent and display a warning to tor2web users, advising them that using a clearnet Tor gateway does not give them the full anonymity benefits of the system? It's a more flexible and less paternal solution then blocking them For Their Own Good.

[Taipo]

"why not detect the user-agent"

Does the browsers user-agent differ in tor2web than using the tbb?

".....and display a warning to tor2web users"

I agree, to the point that a warning is issued and user is prevented from accessing the deaddrop functions. Allowing them access within any browser less than the TOR configured browser is too unsafe.

[garrettr]

Does the browsers user-agent differ in tor2web than using the tbb?

No (it is up to the proxy).

Dropping Tor2Web traffic can only be a best-effort feature. By default, the hidden service cannot distinguish between Tor2Web and non-Tor2Web requests, since it sees every request as coming from localhost (through Tor).

The new Tor2Web 3.0 makes this possible, by appending a header to all of the requests it proxies. The original Tor2Web does not do this, and so the user's safety in this case depends on the proxy operator.

It is probably best to actively discourage the use of Tor2Web. I expect savvy users that would be familiar with Tor2Web proxies in the first place would also know enough to recognize their limitations.

[Taipo]

No (it is up to the proxy).

I thought that was the case.

I expect savvy users that would be familiar with Tor2Web proxies in the first place would also know enough to recognize their limitations.

It's the 'not so savvy' users that are most at risk, who would opt for a proxy service to get access over installing and configuring TBB.

Tor2Web services can be run by anyone including adversaries, and as we have seen with recent raids on hidden_services hosts, any captured server can have malicious js installed by an adversary in a hostile takeover of, for example, a common popular Tor2Web server.

Secondly, X-tor2web could also be disabled by an adversary that by whatever method, controls a legitimate Tor2Web proxy thus allowing the transaction to still take place even though blocks were put in place to prevent access if the X-tor2web header was present.

So in my current thinking iff there is a way of progammically preventing connections to a hidden_service from a Tor2Web proxy then that really has to be the safest way, the last possible stop gap would be a warning sign on the journalists WWW website as well as the SecureDrop site to steer clear of them.

[garrettr]

iff there is a way of progammically preventing connections to a hidden_service from a Tor2Web proxy then that really has to be the safest way

There isn't, for the reasons discussed above. We can and should do a best-effort attempt based on X-tor2web, but that's all we can do.

I'm not sure if I agree that we should put warnings about not using Tor2Web on the site itself. Following that logic, you could plaster the site with warnings about best practices and potential compromises. This would reduce the usability of the site and could frighten off potential sources. It should certainly be mentioned in the User Guide. Since none of our documentation will encourage the use of Tor2Web, I am not overly concerned about it.

[Taipo]

I am not overly concerned about it.

I am. But in saying that, as long as the x-tor2web header is mandatory in versions >= 3.0, then its only a matter of time before that will be the common proxy header, but it is as you say, still a best effort. For every method that actually defeats surveillance ( like end-to-end encryption ), reduces down the list of available attack methods to to the more expensive ones and to security issues abated by best efforts of developers. In this case, adversary run Tor2Web nodes may not be their first line of attack at this stage, but once they figure it out, its just too big a temptation for mega-adveraries to eventually ignore. But I guess thats really a problem for the Tor2Web people to fix.

[fpietrosanti]

I'd suggest to consider using the same approach we've already used at GlobaLeaks Project where we also develop Tor2web:

• Enable configurability of denial/blocking of Tor2web
• If enabled, provide a forced-disclaimer to force the awareness

We already went under this kind of issue and the solution is that "some user" do need tor2web, so in that situation you must enable tor2web and the only mitigation solution is to enforce the whistleblower awareness. Have a look at http://demo.globaleaks.org to see how it does behave.

[garrettr]

I'm working on this.

[Taipo]

@garrettr

if 'X-tor2web' not in request.headers
        flash('<strong>WARNING:</strong> You appear to be using Tor2Web. This <strong>does not</strong> provide anonymity. <a href="/tor2web-warning">Why is this dangeorus?</a>',
              "header-warning")

Wouldn't that do the opposite of what its intended to do?

[garrettr]

@Taipo Yes it would. That was my mistake (I had it flipped like that so it would always appear while I was tweaking the CSS, and accidentally committed it), and was fixed in the next commit: 608777a.

[Taipo]

Ah my bad. Missed the next commit...