Adding webtunel bridges to whonix

Support
22

Could you add this to the wiki please?

Chapter lyrebird.

Note: Improve the Documentation / Edit the Whonix Wiki

2 Likes
23

Did anyone test it except me?

1 Like
24

Was able to narrow down the problem I have with the above implementation by @anon26447919

The error occurs when starting tor on the sys-whonix-webtunnel VM which is my cloned version of sys-whonix for testing.

The tor bootstrap process gives me this error when being at 2%:

[err] Managed proxy “/usr/bin/lyrebird”: Error dialing: error dialing [bridge-host].onion-equivalent:443: dial tcp: lookup [bridge-host] on [::1]:53: read udp [::1]:xxxxx->[::1]:53: read: connection refused

(IP address and URL anonymized)

To me it looks like lyrebird is trying to resolve the bridge hostname via normal system DNS, but Whonix blocks all Clearnet DNS requests except through Tor’s DNSPort. (which is a feature).

I think lyrebird runs as an external pluggable transport before Tor is fully up, it cannot use Tor’s DNS resolver and fails with “connection refused” on localhost:53.

Am I right?

My questions:
Has anyone successfully solved the Clearnet DNS issue for pluggable transports like lyrebird in Whonix? Or am I misguided here?

Would it be better to run lyrebird + Tor in a separate custom ProxyVM and let the Whonix-Gateway connect via Socks5Proxy instead?

Any hints or workarounds would be greatly appreciated.

Thanks in advance!

2 Likes
25

Yes, if you’re on Qubes, then it should be the whonix-gateway-18 template-vm there.

Yeah, it looks like the dns isn’t getting resolved. That may be because of the sys-firewall Qubes hardening, since sys-whonix already has some rules, maybe your cloned version doesn’t - in sys-net?
You can try adding the addr feature, which caches the dns to your webtunnel bridge, you can do that by making a space after the bridge and adding this in the custom torrc:
addr=0.0.0.0:443, or addr=[ipv6]:443 for IPv6.

Won’t it get very complicated? The Socks proxy in the Tor Control Panel is intended for a Tor bootstrap, unless you mean something else.

It technically should use the system dns by default.

2 Likes
26

I’ll look into it. I first want to polish out the guide and see if there are any missed or unnecessary steps.
In example, you aren’t required to install Go for lyrebird to work. I can’t edit the message on the forum anymore.

2 Likes
27

Thanks for pointing me to the workaround:

Resolve the domain from the bridge URL in another VM:

getent ahosts example-bridge-domain.net

Then take one of the returned IPs and add it directly to the bridge line via addr=.

Example:

UseBridges 1
ClientTransportPlugin webtunnel exec /usr/bin/lyrebird managed
Bridge webtunnel [IPv6]:443 FINGERPRINT url=https://example-bridge-domain.net/... addr=IP:443

After that, Tor bootstraps normally and the bridge works.

IP might change over time, so this is a manual workaround

1 Like
28

I ran into an issue when adding a second WebTunnel bridge.

The error is clearly a TLS/SNI mismatch:

lyrebird uses the hostname from url= as SNI (e.g. example-bridge.net)
the server presents a certificate for a completely different internal hostname (e.g. something like randomstring.proxy.internal)

So the hostname and certificate don’t match, and the connection fails as expected.

In practice this means:

the bridge endpoint is misconfigured on the server side and not usable at all.

Just a heads up in case others see similar errors when adding WebTunnel bridges.

2 Likes
31

@Patrick I submitted a change.

Should there be separate instructions depending on your Whonix configuration? (Qubes-Whonix, VirtualBox, i.e.)

I think the instructions are pretty universal.

1 Like
32

Can you elaborate on that? I thought a clone is a 100% copy so where might be the difference?

1 Like
33

The dns resolution failure doesn’t happen in the default sys-whonix.

1 Like
34

ok, but why? what is different? I don’t get it. Sorry for bothering you guys, but I’d like to understand.

I cloned the standard template whonix-gateway-18 to whonix-gateway-18-webtunnel. There I copied the lyrebird binary to /usr/bin and did add the apparmor entry for lyrebird, as you suggested.

then I created the new gateway sys-whonix-webtunnel on this exact template. There I just configured /usr/local/etc/torrc.d/50_user.conf again as you suggested.

That basically was it.

So why should the handling of DNS be different in this new"webtunnel enabled" gateway than in the standard sys-whonix gateway qubes / Whonix provided?

Are there additional settings like firewall etc. in dom0? If so, why don’t we just “transfer” those to the new gateway?

Thanks for taking the time to answer. I don’t like the idea to touch a running system like sys-whonix, when I can have another cloned (=identical) gateway for testing.

2 Likes
35

This is also somewhat curious to me despite being a developer, so you’re not alone in being confused :stuck_out_tongue:

4 Likes
36

Difference depends whether a Tor bridge:

  • A) is an IP (= no Whonix-Gateway system DNS required); or
  • B) is a DNS hostname (= Whonix-Gateway system DNS required)?

Wiki changes accepted and wiki improved. Untested by me.

Probably also superfluous command. if the source file is executable. so will be the target file after copying it.

Unsuitable Connectivity Troubleshooting Tools

Tor Control Panel should have no role in this.

  1. Use text configuration files.
  2. Ignore graphical user interface (GUI) tools.
  3. Done.

No. Not separate. The difference should be pretty minimal.

4 Likes
37

Wow, thanks for the work on the wiki-guide!

I have an update regarding the dns resolution stuff in qubes. The default sys-whonix has the same “dns resolving errors”, so modifying the whonix dns would fix the problem.

As I understand it, enabling the Whonix “system dns” does not override traffic resolving to Tor (then it gets routed to Tor’s dns proxy), like what happens with the dns requests when you try to update the Whonix-Gateway? Do they still get routed through Tor? And in “the guide”, should there not be any mention of caching bridge dns’s using /etc/hosts or directly using the addr feature? (other than directly changing Whonix’s dns servers to system dns)

System DNS enables internal DNS resolution: Tor could always have resolved DNS for any internal purpose if it had DNS resolving capability built-in. Enabling system DNS on Whonix-Gateway grants Tor the ability to resolve DNS for any internal purpose.

I tried using it out of the box, and no, it doesn’t work without manually making it executable first. (permission denied error)

The Tor Expert Bundles are actually signed (this is about the step 1 (notices) on the wiki), if you visit this page:

(https://)dist.torproject.org/torbrowser/15.0.8/

(https)://dist.torproject.org/torbrowser/latest-stable-tor-browser-version/

Also, should there be a link to manually compile lyrebird, which can be found here? (but the recommended way still being to extract lyrebird from the Tor Expert Bundle because it’s an easier way)

2 Likes
38

Added just now to the wiki:

  • Whonix-Gateway system upgrades are unaffected: Whonix-Gateway is upgraded using APT, which requires administrative (“root”) rights and runs under the root account, which has no access to system DNS because APT is configured for Stream Isolation using a uwt wrapper, which essentially redirects calls to apt / apt-get to torsocks, and because Whonix-Gateway Firewall does not permit the account root to use system DNS / UDP / TCP by default. Only the account debian-tor is permitted to use the system’s default networking.

No need to encode links. Your account is permitted to post links.
(Posting Links for New Users)

Optional. If someone thinks that’s a good idea, one more link will be alright.

2 Likes
39

tor webtunnel bridges contain both. An IP as well as a hostname.

IP is for tunneled traffic, domainname is for establishing a TLS based connection to the web server running on that bridge which has a “hidden entry”. Obviously this domainname has to be resolved which is not done properly under Whonix on Qubes. (see my posts above).

The workaround is to resolve the domain name manually in a non whonix qube and add this IP as addr=... in the Bridge line in torrc file.

2 Likes
40

In that case, either Whonix-Gateway system DNS required is required or the hostname must be converted to an IP address.

That should work in many “simple” cases such as this. [1]

[1] Optional informatiion, off-topic: What is a “non-simple” case where avoiding host names is non-trivial? In the web browser it’s not trivial to replace a hostname with an IP due to subdomains and TLS.

3 Likes
41

In the end, it’s an instruction on installing lyrebird, which would support webtunnel bridges.

There now is a section, which tells you how to “fix” the dns resolving for Tor bridges.

Shouldn’t that be the preferred way of dealing with dns resolving there?

Users who install lyrebird should be able to use all the features that it provides, meaning that they can “cache” the dns address of some bridge. It might not be the most stable configuration though and might make a bridge look “dead” if it’s ip got rotated or something similar, the user will also have to resolve the dns address manually, so recommending it by default doesn’t sound that well.

Or do you still think it’s worth to have a small note there?

Most webtunnel bridges aren’t provided with that addr feature, so usually there is only a hostname by default. The ipv6-looking part of it in it’s beginning is not related to the bridge’s dns resolving, just adding this as a note.

Made some more changes.

3 Likes
42

Thx for clarification and your efforts!

4 Likes
43

Something already difficult becoming even more difficult and fragile.

A note is fine.

3 Likes