Based on my observations it seems Tor Browser 13.5.1 is the first version to include some sort of weird pre-emptive kill switch. I’m not sure what else to call it. I don’t mean it as a nasty accusation. But as an average user who noticed negative changes. Please note I don’t see this as a User Interface problem.
A few versions ago, I forget the exact one, I was taken by surprise when I opened Tor Browser after an update and a binary embedded in the Tor Browser package called “lyrebird” wanted to connect to the www[.]phpMyAdmin[.]net domain. I told my personal firewall to not allow it, Tor Browser hung for awhile, then connected normally; at that point I could browse using DNS, as well as onion sites.
But as of Tor Browser 13.5.1 (pretty sure) it will immediately fail to connect to both DNS sites and onion sites after I deny the lyrebird connection to the www[.]phpMyAdmin[.]net domain.
In the Tor Browser > Preferences (aka Settings) section called “Connection” it shows the Internet as Offline and Tor network as Not Connected. Pressing Test for the former just brings up another lyrebird attempt to connect to www[.]phpMyAdmin[.]net, which I deny. Pressing Connect to try the Tor Network does the same.
I don’t want to connect to the www[.]phpMyAdmin[.]net domain in order to use Tor Browser.
This connection has so far never been needed. It seems like an opening to leak information. I’m not keen on it and don’t recall reading any blog posts about how Tor Browser wouldn’t work unless I first connected to a 3rd party site requiring DNS use first.
Fortunately at this point I don’t need a bridge. I understand some bridge mechanisms rely on domain fronting. I connect directly.
None of the other bridge/pluggable-transport binaries embedded within Tor Browser have prevented me from accessing the tor network.
Can Tor Browser be returned so pluggable-transports do not lock out those of us who don’t need them at that moment? Thank you.
Screen shot below of the alert. Initially it only shows the binary making the request and the domain it’s trying to reach. Pressing the “i” gives more information. The firewall software notes the IP and then does a reverse DNS look up on it.
I am seeing a variety of IP addresses.
One screenshot I took in late June shows 212.102.56.182, with a reverse DNS name of CDN: 290267245.fra.cdn77[.]com.
Just for fun I tried to test the connection again in Tor Browser settings and the alert showed 207.211.211.26 with a reverse DNS of: 607028803.fra.cdn77[.]com.
Still fairly similar.
When I run ping (not over tor):
$ ping www.phpmyadmin.net
PING 1115546720.rsc.cdn77.org (195.181.175.41): 56 data bytes
64 bytes from 195.181.175.41: icmp_seq=0 ttl=56 time=2544.953 ms
64 bytes from 195.181.175.41: icmp_seq=1 ttl=56 time=113.378 ms
64 bytes from 195.181.175.41: icmp_seq=2 ttl=56 time=111.733 ms
^C
--- 1115546720.rsc.cdn77.org ping statistics ---
Still the same CDN, but somewhere else. Not France I’m guessing.
Before posting this I tried the Tor Browser GUI connection test one more time: 169.150.255.184, reverse DNS 298300181.fra.cdn77[.]com.
Also, looking back through my collection of screenshots, I see the oldest one I took of this happening was 2024-05-16. So my guess is that’s the first time it happened, or near it. But like I noted above, the first (or perhaps first few) Tor Browser update which brought this alert to my attention, only just caused a 5-15 second hang. Now it totally blocks TB from working.
As another data point (bold since it seems important, not me shouting ;-), when I run the Expert Bundle it does not have this problem. i.e. lyrebird doesn’t try to make a connection.
I can confirm that pressing Test button initiates DNS request for www.phpmyadmin.net and when DNS is disabled test shows Offline status.
However, in my case, it did not prevented Tor Browser from making direct connections to relays.
I suspect Tor Browser may have different rules for making direct connections depending on user’s country. Needs checking however.
tor-browser-tor-browser-128.1.0esr-14.0-1/toolkit/content/pt_config.json
Where it sits in the bridges array for snowflake. fronts=www.cdn77.com,www.phpmyadmin.net
I can understand using a CDN and “big name” host for domain fronting, but…
In any case, that seems irrelevant.
What’s relevant is lyrebird (within Tor Browser) has a bug or been given or taken the power to completely stop Tor Browser from functioning. Something none of the other bridges/pluggable-transports do.
Lyrebird is a binary that includes some pluggable transports like meek, obfs4, WebTunnel. When Tor Browser is bootstrapping, it checks whether your Tor connection is blocked. If it detects a block, it will try to connect using one of these PTs. It uses domain fronting (cdn77) to fetch the latest configuration of Tor circumvention API.
Basically, part of Tor Browser’s connect-assist flow involves determining if the user has internet access. This check happens automatically as part of bootstrapping without any indication in the UX which is obviously less than ideal. This problem is unlikely to get fixed in the 14.0 release cycle which is ending in about a month, so you can potentially expect a fix sometime during the 14.5 release cycle.
As @gus mentioned, lyrebird is a pluggable-transport which implements obfs4 and moat (among othres) provided with Tor Browser and the tor-expert-bundle. It is built reproducibly along side all of our other stufff.
It sure feels like I stumbled into a moat versus being protect by one. But not just me, it now sounds like every TB user is making an unnecessary and easily seen connection to a domain that’s not exactly in everyone’s bookmarks, only a very tiny percent who manage databases with that cool open source project.
This problem is unlikely to get fixed in the 14.0 release cycle which is ending in about a month, so you can potentially expect a fix sometime during the 14.5 release cycle.
Due to Firefox ending support for older versions of Windows and macOS, Tor Browser 13.5 will be the final major version of Tor Browser to support Windows 8.1 and older, and macOS 10.14 and older.
I noticed this problem back in the middle of May. If I raised alarms back then, would that have solved this sooner so others and I could actually benefit from it?
In case my previous posts to this thread weren’t read, the introduction of this lyrebird issue didn’t completely stop Tor Browser from working, it just caused an annoying, albeit short, hang.
Am I dreaming the patch that brought this most recent change (which I mentioned in posts above—literally just this most recent version of TB) can be rolled back, updated, and reapplied?
I understand that there are many variables, but for me, this DNS request happens only when I press Test button.
When I connect to Tor normally, such request is not sent, Tor Browser connects to regular relays right away.
By the way, DNS requests can be hidden from ISP by switching to DNS over HTTPS (DoH). I’m using dnscrypt-proxy 2 for this task.
Hi all, the internet test can be disabled by going to about:config and adding torbrowser.bootstrap.allow_internet_test with value false.
However, if the connection fails, we still connect to our backend to fetch the list of countries/regions for which we have specific circumvention settings.
We forgot about adding a preference to avoid that, and I apologize for that.
Hi all, the internet test can be disabled by going to about:config and adding torbrowser.bootstrap.allow_internet_test with value false.
Hi @PieroV I’m afraid people can only do that on desktop versions of Tor Browser, but apparently the issue can be reproduced on Android too, where apparently one cannot access about:config. How can we fix or workaround the issue there?
I think many people would really appreciate to get access to about:config in TorBrowser for Android: maybe you could enable it in the next release, so that we can get back access to the Tor network from Android?
about:config was disabled by Mozilla on Android, and we decided not to change this.
Some users change preferences in about:config because they found some guide online that either is for Firefox, or doesn’t explain possible side effects.
For example, before we locked RFP, people suggested to turn off privacy.resistFingerprinting just to have the dark theme .
Now that the connection settings are stored there, we might think about unlocking it again, even though it’s a sort of chicken and egg problem: the URL bar isn’t shown until you bootstrap, so you’ll have to bootstrap successfully once to go to about:config.
Maybe we should think also about some hidden enough trick to bring about:config out before the bootstrap if we enable it.
This is good to know. I guess it’s easy to think all Tor Browser users are exactly the same since that’s kind of the mantra. But of course on the other hand it means it’s exposing a slice of users. (Which is why some of us sound cagey as to our country, what OS we use, etc.)
Customizing my system’s DNS is painful. In my dreams I setup OpenBSD on a tiny thing like RaspberryPi or smaller, and put the latest version of Alec Muffett’s DNS over HTTPS over Tor on it. But I’ve not yet been able to put that in front of me.
Many years ago I’m sure I ran dnscrypt proxy. Not sure what happened. System updates and compatibility stuff. I’d compile it from source if it was C with no, or simple, dependencies.
Trash the whole “TorBrowser-Data” folder in my home folder.
The next time I started Tor Browser it didn’t try to automatically connect to www.phpMyAdmin[.]net.
I don’t make a lot of customizations to Tor Browser, for obvious reasons. But I really have to customize the toolbar. So, dumping that folder comes with costs; not the first thought to a noob or first on a power user’s list.
As @Vortnoted, in Tor Browser’s Settings, the “Connection” section, pressing “Test” next to the Internet option, brings up a request through my OS (not over tor) to connect to the domain name www.phpMyAdmin[.]net which, no offense to their project, is not exactly a big name domain, and seems likely to leak to the network/ISP that tor is being used, or the person is a techie (uses phpMyAdmin) and worth putting on an accusatory list of people to spy on.
Before I mark this as solved, it would be nice to hear some convincing reason for using that domain for the connectivity test versus another domain which is far more likely to be accessed, even by the oppressors. Why does it have to be a domain at all? Or, what don’t I understand yet?
If the Tor network is connected then isn’t the Internet also, by default? Or is Internet more like a DNS-only test?
In my opinion, among the best things tor has going for it, is resiliency against attacks undermining the Domain Name System; using onion addresses instead.
Such a tragedy people are in the way of obtaining low-cost TLS certificates for onions.
Yes, the “Internet Test” button could be probably removed or reworked to ask Tor after we have bootstrapped. But it’s definitely low priority for now.
Also, we’d love to have a better domain to use .
The technical reason for which we need a name is called domain fronting.
TL; DR: we put a certain domain in TLS’s SNI, but then we put a service we control in the Host header of HTTP (you’re never actually downloading the www.phpmyadmin.net page, only censors think you are, instead you’re downloading data to evade censorship).
So, we need a cloud provider that “supports” this. CloudFlare, Fastly and Azure don’t allow this anymore alas, and actively block these requests. This prevents us from using bigger names such as Stack Overflow, Four Square, etc…
But not just me, it now sounds like every TB user is making an unnecessary and easily seen connection to a domain that’s not exactly in everyone’s bookmarks, only a very tiny percent who manage databases with that cool open source project.
.
.