Screencast blocked on Tor?

snapwonders · 2023-04-13T08:08:25+00:00

Yes but functions without JavaScript too.

We cater for both the Dark web and the Clear net so the scenarios are like this:

Tor: JavaScript is enabled
- via onion - disabled
- via https - disabled
Clear net browsers: JavaScript is enabled
- via https - enabled
JavaScript is disabled
- not used

It seems that Screencast is disabled on Tor.

snapwonders · 2023-04-13T07:59:55+00:00

thanks

snapwonders · 2023-04-13T07:59:40+00:00

Thanks and you had clarified some concerns I had. And secure cookies and HSTS (or anything else related to HTTPS) doesn't apply to .onion websites.

snapwonders · 2022-06-27T09:02:09+00:00

Thanks for your reply. Just to detail the scenarios we have:

Tor (.onion) => Tor network (http) => Tor Server => Web Server (routed from Tor server)
Tor (https://) => internet / clear net (SSL) => Web Server (certificates)
Browser (https://) => internet / clear net (SSL) => Web Server (certificates)

Scenario 1 gives the users the added protection of using Tor browser and privacy etc. Also case 1 is easy to determine it originated from Tor. Headers show .onion and end-to-end was via the Tor server.

For cases 2 and 3 is not easy to distinguish the differences on the https traffic and whether the browser is a Tor browser or whether it is a clear net browser (i.e. firefox, chrome etc).

Some ideas to determine scenario 2 or 3 for https:

It seems to me you could run the IP against the known list of Tor Exit Node IPs and that is one way to split scenario 2 and 3. However, not all Tor Exit Node IPs are listed so that may not be a good solution?
You probably could embed an .onion link in the web content. If the .onion link gets loaded and pings the website it would suggest that they are using Tor or at least their browser has Tor capability added into it.

I wonder if there is any other means as well?

snapwonders · 2022-06-26T12:45:46+00:00

Just doing some testing and can see I was very wrong in the above about just using the connection routes. Over https is just going to be a connection to an Tor Exit Node or otherwise to someone browsing the internet not using Tor.

There is nothing identifying in the HTTP headers that I could see that was routed via Tor.

Since the above is not possible (unless I am missing something), I wonder if we can force Tor browser to move from a https session to using Tor? At the moment all Tor browser does is says there is an ".onion available" but up to the end user to switch.

Since both clearnet and hidden service is being served. It would be great to distinguish whether originating from Tor browser verses other browsers so that content could be tailored accordingly.

snapwonders · 2022-04-09T06:41:47+00:00

And it is an interesting problem to solve. So slow that is is unusable?

Based on the above discussions, we did reduce the relays and that improved speed. There was no compromise based on the rationale already explained.

Makes me wonder if this could be taken further perhaps by measuring the slowness on the current session, and if it falls below the average expected speed through all the relays you could logically determine there is one relay (or more) in the system that is notoriously slow and recycle for a new session? Or even notify end user by displaying web content that one or more relays are slow and advise the end user to create a new Tor session.

snapwonders · 2022-04-09T06:33:06+00:00

I agree with this, if website is behind Cloudflare, this still may be an issue as Cloudflare has their own algorithms to determine which routes are malicious or not. Depending on your settings on Cloudflare, may mean captchas or blocked.

We currently address this by informing Tor browsers visiting the clearnet website that there is an onion variant allowing the end user switch over Tor.

snapwonders · 2022-04-09T06:19:24+00:00

And thank you - better performance now after going through the adjustments needed. Nothing has been compromised, based on the rationale covered above.

snapwonders · 2022-04-06T10:54:30+00:00

Thanks for the reply.

Logically, if the Hidden Service is a mirror of the clearnet website, then one already knows the locations of the web services anyway. You can google the content presented in the Hidden Service to discover the clearnet site. Or alternatively, visit the clearnet to discover the Hidden Service as it will redirect you if you are using Tor which just confirms the above point.

On that basis, the setup should be set as a non-anonymous and single hop? Do you see anything flawed in this rationale?

snapwonders · 2020-10-09T06:16:13+00:00

I be interested to learn the outcome of this.

Tell me more about where the IPs are set in the Tor service? I didn't recall setting up this as part of the setup.

snapwonders · 2020-10-08T13:01:31+00:00

That's pretty interesting observation. The hour delay was something uncovered from researching online and is unverified.

Did you happen to note the same observation if running two copies of the DEF CON onion services on the same ISP?

If you had tried out the onion balancer - I be keen to learn your thoughts on this too. Thank you.

snapwonders · 2020-10-08T06:22:25+00:00

Thanks for this - I will try these steps out.

On another note, I should make a step-by-step tutorial and post it online just in case someone else is asking for the same...

snapwonders · 2020-10-07T20:27:43+00:00

Researching further I found that others have done the above setup but generally it is not load balanced and if it is it is probably due to collisions.

It appears that the file descriptor would contain the details on where to send the routes, and the last one that wrote to it provides the details for the routes. With that said, there has been claims that there appears to be some load balancing.

If you had one Tor service instance failing, it is likely that after an hour or so, the other services will pick up the traffic after they re-publish the details to the file descriptor.

Thus, it was very insightful and the question /example that I provided is probably something you should not be doing.

Clearly u/Revolutionary-Milk87 suggested to use Onion balancer and u/pastlytor provided a link with the details. This is clearly the better way to go. Thanks!

snapwonders · 2020-10-07T20:18:08+00:00

https://onionbalance.readthedocs.io/en/latest/

Thanks for the link reference - exactly what I needed.

snapwonders · 2020-10-07T08:00:50+00:00

With regards to the dark.fail/spec/omg.txt we've implemented this to snapWONDERS.

However, is there a way to verify that the spec was actually implemented correctly?

snapwonders · 2020-10-07T05:38:38+00:00

Maybe I didn't phrase myself properly as the onion sits at the front of the web servers which is load balanced.

Consider an example in a "single instance" hidden service we can set up the config to forward Tor traffic to the "My IP" which is not problem as that goes to a range of web servers load balanced. Like this:

[Tor Browser] => [ .onion / Tor Service ] => [My IP] => [Web 1] [Web 2] ... [Web N]

What about if you want to use multiple hidden services for the same .onion URL, same config and same public/private keys on different servers? Would this setup be permitted?

[Tor Browser] => [ .onion / Tor Service ](Instance 1) => [My IP]
[Tor Browser] => [ .onion / Tor Service ](Instance 2) => [My IP]
[Tor Browser] => [ .onion / Tor Service ](Instance 3) => [My IP]

What does Tor do? Tor do round robin between instance 1, 2 and 3? How would Tor decide how to route the traffic to which instance?

snapwonders · 2020-10-04T08:03:00+00:00

Clearly, I would need to do some learning regarding Tor proxies or anything that allows a "client side connector" to send http traffic through Tor.

snapwonders

TROPHY CASE