Browser Confused With Forced Onions

Support
1

I have a long-standing issue with forced onions. With both Qubes-os.org and Whonix.org as forced onions, occasionally a visit to Qubes is overridden and instead goes to whonix’s site, keeping the path intended for Qubes. Naturally, this results in a not found error. Not only that, it’s a privacy leak.

Most recently this happened when trying to create a custom rule for dev.sik5nlgfc5qylnnsr57qrbm64zbdx6t4lreyhpon3ychmxmiem7tioad.onion/ (Qubes OS developer documentation, which may or may not be served via onion) Goes straight to Whonix Onion. Custom rulesets had already been applied for Qubes-os.org and Whonix.org

In the past, searching Qubes with its site-internal DuckDuckGo and clicking a link to travel back to Qubes’ site resulted in a visit to Whonix’s page instead. Forced onion for DDG in this case.

I’m not sure why Whonix site takes priority in these cases, does anyone have any suggestions? Does this happen to anyone else?

Thanks in advance!

2

Hi @9jnc7,

You’re correct that this issue is occurring, it’s a server thing, not a problem at your end.

The reason is there’s currently no configuration for the dev. subdomain on the Qubes Onion service.

The only Onionized Qubes addresses are for the main site, yum., qubes-yum., ftp., deb., qubes-deb.

For any subdomain that isn’t explicitly configured, this leads a complex evaluation of the request which ends up picking the ‘default’ site on the server, which happens to be the main whonix.org site.

The dev.qubes-os.org site is actually a third party service provided by readthedocs.io. If this were to be Onionized, it’s not ‘true’ Onion as the traffic would have to be proxied from the Onion Service out to the clearnet.

We’ll get back to you on whether we’ll get the dev docs site onionized. At the very least, I can probably do something to lead the request back to the Qubes onion rather than the clearnet whonix.org site.

The DuckDuckGo issue is probably because the DuckDuckGo site only sees the real IP of the server sending the request. Its ‘Back’ functionality may have just taken you back to that IP (and again hit the default whonix.org site), although I don’t reproduce it now.

2 Likes
3

FYI, for now I’ve added a wildcard for *.sik5nlgfc5qylnnsr57qrbm64zbdx6t4lreyhpon3ychmxmiem7tioad.onion so that at least a request to previously unaccounted-for subdomains like dev.sik5nlgfc5qylnnsr57qrbm64zbdx6t4lreyhpon3ychmxmiem7tioad.onion, will take you to the QubesOS front page - which is not great, but is better than loading the Whonix page.

We’ll need a discussion maybe with the Qubes devs if we want to somehow mirror the dev.qubes-os.org ReadtheDocs.io site - not sure if they’d want dev.sik5nlgfc5qylnnsr57qrbm64zbdx6t4lreyhpon3ychmxmiem7tioad.onion to proxy out of tor to https://dev.qubes-os.org even though it’s SSL… but maybe they think it’s fine to do so (and it’s certainly easy for me to implement, at least, assuming that ReadTheDocs doesn’t do anything to mess URL rewriting back to the .org domain!)

2 Likes
4

Actually, just tried testing it on a stage instance, and I can’t proxy to https://dev.qubes-os.org. CloudFlare (which sits in front of readthedocs.io) rejects it with a 403 forbidden.

Sorry! You’ll have to make an exception for the dev doc site.

1 Like
5

Huh. Actually, I managed to get it to work disbelief

http://dev.ak366nnj3zcj43ebdsfdkggenmktmzt4jzzomhfea4v5hjgdeqd7ftyd.onion/en/latest/

@Patrick, do you want to ask Marek if he wants us to host the ‘dev’ subdomain on the Qubes v3 onion, noting that it proxies out to https://dev.qubes-os.org/ e.g it’s not a purely Tor network solution? Just for the sake of peoples’ HTTPSEverywhere rules…

2 Likes
6

Thanks for the in-depth response, @mig5

I understand now, I forgot about hosting arrangements between the projects.

I appreciate it.

1 Like
7

It was news to me too!

At this stage for cost reasons it sounds like we are not going to implement the onion for the dev documentation. Besides, it is not ‘true’ onion since it has to pop out the otherside to the non-Tor network.

I’d recommend just excluding the dev subdomain from any HTTPSEverywhere rules.

In the meantime, at least the dev subdomain and any other unaccounted-for subdomains, will redirect to the Qubes onion, instead of the Whonix site.