[HOME] [DOWNLOAD] [DOCS] [NEWS] [SUPPORT] [TIPS] [ISSUES] [CONTRIBUTE] [DONATE]

Whonix Gateway CLI-15.0.1.5.4 - meek-azure bridge "TLS_ERROR"

Hello,
I’m testing the bridge configuration starting from a fresh Whonix Gateway CLI and by using startx for executing anon-connection-wizard.

The “obfs4” transport type works correctly. The “meek-azure” transport type does not.
Step by step is shown this small test:

The machine is connected to TOR:
Tor_Status_CLI

The 50_user.conf file is empty
50_user-conf_file_fresh

I didn’t touch the 40_tor_control_panel.conf.

Then I start the bridge configuration:

When I click on “Next”, the bootstrapping will freeze at 10%
error_bridge3

and the messages produced by this process are:
error_bridge1
error_bridge2

So the errors that are triggered continuosly while the progress bar stucks at 10% are these "TLS_ERROR" where about each second the COUNT variable increase by 1.

When I stop the bootstrapping, the content of the 40_tor_control_panel.conf file is:
error_bridge4

Is it a known issue? Could be due to a TLS certificate error?

PS: sorry if I do not copy and paste directly the text but the copy and paste from the VM does not work, even though I installed the vbox addition guests by “upgrade-nonroot” command.

1 Like

Previously, no.

Now confirmed.

Please help fixing this.

  1. “forget” about ACW
  2. “forget” about Whonix
  3. reproduce on Debian
  4. use https://packages.debian.org/buster/obfs4proxy
  5. use https://packages.debian.org/buster/tor or newer tor package from https://www.torproject.org/docs/debian
  6. as per https://www.whonix.org/wiki/Free_Support_Principle
  7. add to /etc/tor/torrc
UseBridges 1
ClientTransportPlugin meek_lite exec /usr/bin/obfs4proxy
bridge meek_lite 0.0.2.0:3 97700DFE9F483596DDA6264C4D7DF7641E1E39CE url=https://meek.azureedge.net/ front=ajax.aspnetcdn.com

Then figure out if you can fix the config somehow. If not, report bugs to Debian and/or Tor Project. Don’t mention Whonix. Keep Whonix out from reproduction. Otherwise upstream might say “Whonix issue, not our issue”.

More background:

If you figure out what to change, how to make it work in Debian, then very most likely I’ll be able to apply the same with ACW / Whonix.

No problem.

Expected. VirtualBox does not have that feature as far as I know. Works only when a desktop environment is running.

Ok @Patrick
In the following reply, for tracing reason, I report my test on Debian 10.9 (buster). I used the debian-10.9.0-amd64-netinst image.

I installed obfs4proxy and tor by following the links on the 4) and 5) points. Then I added to /etc/tor/torrc file the following:

UseBridges 1
ClientTransportPlugin meek_lite exec /usr/bin/obfs4proxy
bridge meek_lite 0.0.2.0:3 97700DFE9F483596DDA6264C4D7DF7641E1E39CE url=https://meek.azureedge.net/ front=ajax.aspnetcdn.com

as reported above. So:

To test this configuration, I run:
sudo service tor restart
and I don’t get error.

In particular, if I move to the log file by using sudo journalctl -u tor@default I get:

Apr 06 07:43:16 debian Tor[523]: Interrupt: exiting cleanly.
Apr 06 07:43:16 debian systemd[1]: Stopping Anonymizing overlay network for TCP...
Apr 06 07:43:16 debian systemd[1]: tor@default.service: Succeeded.
Apr 06 07:43:16 debian systemd[1]: Stopped Anonymizing overlay network for TCP.
Apr 06 07:43:16 debian systemd[1]: Starting Anonymizing overlay network for TCP...
Apr 06 07:43:16 debian tor[2127]: Apr 06 07:43:16.775 [notice] Tor 0.3.5.14 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.8.
Apr 06 07:43:16 debian tor[2127]: Apr 06 07:43:16.776 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Apr 06 07:43:16 debian tor[2127]: Apr 06 07:43:16.776 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Apr 06 07:43:16 debian tor[2127]: Apr 06 07:43:16.776 [notice] Read configuration file "/etc/tor/torrc".
Apr 06 07:43:16 debian tor[2127]: Configuration was valid
Apr 06 07:43:16 debian tor[2128]: Apr 06 07:43:16.925 [notice] Tor 0.3.5.14 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.8.
Apr 06 07:43:16 debian tor[2128]: Apr 06 07:43:16.926 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Apr 06 07:43:16 debian tor[2128]: Apr 06 07:43:16.926 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Apr 06 07:43:16 debian tor[2128]: Apr 06 07:43:16.926 [notice] Read configuration file "/etc/tor/torrc".
Apr 06 07:43:16 debian tor[2128]: Apr 06 07:43:16.930 [notice] Opening Socks listener on 127.0.0.1:9050
Apr 06 07:43:16 debian tor[2128]: Apr 06 07:43:16.930 [notice] Opened Socks listener on 127.0.0.1:9050
Apr 06 07:43:16 debian Tor[2128]: We compiled with OpenSSL 1010104f: OpenSSL 1.1.1d  10 Sep 2019 and we are running with OpenSSL 1010104f: 1.1.1d. These two versions should be binary compatible.
Apr 06 07:43:16 debian Tor[2128]: Tor 0.3.5.14 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.8.
Apr 06 07:43:16 debian Tor[2128]: Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Apr 06 07:43:16 debian Tor[2128]: Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Apr 06 07:43:16 debian Tor[2128]: Read configuration file "/etc/tor/torrc".
Apr 06 07:43:16 debian Tor[2128]: Opening Socks listener on 127.0.0.1:9050
Apr 06 07:43:16 debian Tor[2128]: Opened Socks listener on 127.0.0.1:9050
Apr 06 07:43:16 debian Tor[2128]: Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Apr 06 07:43:17 debian Tor[2128]: Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Apr 06 07:43:17 debian Tor[2128]: Bootstrapped 0%: Starting
Apr 06 07:43:17 debian Tor[2128]: Starting with guard context "bridges"
Apr 06 07:43:17 debian Tor[2128]: new bridge descriptor 'cymrubridge02' (cached): $97700DFE9F483596DDA6264C4D7DF7641E1E39CE~cymrubridge02 at 0.0.2.0
Apr 06 07:43:17 debian Tor[2128]: Delaying directory fetches: Pluggable transport proxies still configuring
Apr 06 07:43:17 debian Tor[2128]: Signaled readiness to systemd
Apr 06 07:43:17 debian systemd[1]: Started Anonymizing overlay network for TCP.
Apr 06 07:43:18 debian Tor[2128]: Opening Socks listener on /run/tor/socks
Apr 06 07:43:18 debian Tor[2128]: Opened Socks listener on /run/tor/socks
Apr 06 07:43:18 debian Tor[2128]: Opening Control listener on /run/tor/control
Apr 06 07:43:18 debian Tor[2128]: Opened Control listener on /run/tor/control
Apr 06 07:43:18 debian Tor[2128]: Bootstrapped 5%: Connecting to directory server
Apr 06 07:43:18 debian Tor[2128]: Bootstrapped 10%: Finishing handshake with directory server
Apr 06 07:43:18 debian Tor[2128]: Bootstrapped 80%: Connecting to the Tor network
Apr 06 07:43:27 debian Tor[2128]: Bootstrapped 90%: Establishing a Tor circuit
Apr 06 07:43:33 debian Tor[2128]: Bootstrapped 100%: Done

It means that the configuration above works correctly.

I also did a “fault” test to be sure that the system referred correctly to the information inside the torrc file, indeed I chose to change certificate value substituting the final E with F:

UseBridges 1
ClientTransportPlugin meek_lite exec /usr/bin/obfs4proxy
bridge meek_lite 0.0.2.0:3 97700DFE9F483596DDA6264C4D7DF7641E1E39CF url=https://meek.azureedge.net/ front=ajax.aspnetcdn.com

Then, restarting tor by sudo service tor restart, if again I move to the log file by using sudo journalctl -u tor@default I get a stuck on the bootstrap:

Apr 06 07:50:38 debian Tor[2128]: Interrupt: exiting cleanly.
Apr 06 07:50:38 debian systemd[1]: Stopping Anonymizing overlay network for TCP...
Apr 06 07:50:38 debian systemd[1]: tor@default.service: Succeeded.
Apr 06 07:50:38 debian systemd[1]: Stopped Anonymizing overlay network for TCP.
Apr 06 07:50:38 debian systemd[1]: Starting Anonymizing overlay network for TCP...
Apr 06 07:50:38 debian tor[2162]: Apr 06 07:50:38.119 [notice] Tor 0.3.5.14 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.8.
Apr 06 07:50:38 debian tor[2162]: Apr 06 07:50:38.124 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Apr 06 07:50:38 debian tor[2162]: Apr 06 07:50:38.124 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Apr 06 07:50:38 debian tor[2162]: Apr 06 07:50:38.124 [notice] Read configuration file "/etc/tor/torrc".
Apr 06 07:50:38 debian tor[2162]: Configuration was valid
Apr 06 07:50:38 debian tor[2164]: Apr 06 07:50:38.273 [notice] Tor 0.3.5.14 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.8.
Apr 06 07:50:38 debian tor[2164]: Apr 06 07:50:38.273 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Apr 06 07:50:38 debian tor[2164]: Apr 06 07:50:38.273 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Apr 06 07:50:38 debian tor[2164]: Apr 06 07:50:38.273 [notice] Read configuration file "/etc/tor/torrc".
Apr 06 07:50:38 debian tor[2164]: Apr 06 07:50:38.278 [notice] Opening Socks listener on 127.0.0.1:9050
Apr 06 07:50:38 debian tor[2164]: Apr 06 07:50:38.278 [notice] Opened Socks listener on 127.0.0.1:9050
Apr 06 07:50:38 debian Tor[2164]: We compiled with OpenSSL 1010104f: OpenSSL 1.1.1d  10 Sep 2019 and we are running with OpenSSL 1010104f: 1.1.1d. These two versions should be binary compatible.
Apr 06 07:50:38 debian Tor[2164]: Tor 0.3.5.14 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.8.
Apr 06 07:50:38 debian Tor[2164]: Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Apr 06 07:50:38 debian Tor[2164]: Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Apr 06 07:50:38 debian Tor[2164]: Read configuration file "/etc/tor/torrc".
Apr 06 07:50:38 debian Tor[2164]: Opening Socks listener on 127.0.0.1:9050
Apr 06 07:50:38 debian Tor[2164]: Opened Socks listener on 127.0.0.1:9050
Apr 06 07:50:38 debian Tor[2164]: Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Apr 06 07:50:38 debian Tor[2164]: Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Apr 06 07:50:38 debian Tor[2164]: Bootstrapped 0%: Starting
Apr 06 07:50:39 debian Tor[2164]: Starting with guard context "bridges"
Apr 06 07:50:39 debian Tor[2164]: Delaying directory fetches: No running bridges
Apr 06 07:50:39 debian Tor[2164]: Signaled readiness to systemd
Apr 06 07:50:39 debian systemd[1]: Started Anonymizing overlay network for TCP.
Apr 06 07:50:39 debian Tor[2164]: Opening Socks listener on /run/tor/socks
Apr 06 07:50:39 debian Tor[2164]: Opened Socks listener on /run/tor/socks
Apr 06 07:50:39 debian Tor[2164]: Opening Control listener on /run/tor/control
Apr 06 07:50:39 debian Tor[2164]: Opened Control listener on /run/tor/control
Apr 06 07:50:40 debian Tor[2164]: Bootstrapped 5%: Connecting to directory server
Apr 06 07:50:40 debian Tor[2164]: Bootstrapped 10%: Finishing handshake with directory server
Apr 06 07:50:48 debian Tor[2164]: Tried connecting to router at 0.0.2.0:3, but RSA + ed25519 identity keys were not as expected: wanted 97700DFE9F483596DDA6264C4D7DF7641E1E39CF + no ed25519 key but got 97700DFE9F483596DDA6264C4D7DF7641E1E39CE + /LIpGKq6STgqkVJaKWDj92BCzGWbwqe3lBU+8hsQKP8.
Apr 06 07:50:48 debian Tor[2164]: Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (Unexpected identity in router certificate; IDENTITY; count 1; recommendation warn; host 97700DFE9F483596DDA6264C4D7DF7641E1E39CF at 0.0.2.0:3)
Apr 06 07:50:53 debian Tor[2164]: Tried connecting to router at 0.0.2.0:3, but RSA + ed25519 identity keys were not as expected: wanted 97700DFE9F483596DDA6264C4D7DF7641E1E39CF + no ed25519 key but got 97700DFE9F483596DDA6264C4D7DF7641E1E39CE + /LIpGKq6STgqkVJaKWDj92BCzGWbwqe3lBU+8hsQKP8.
Apr 06 07:50:53 debian Tor[2164]: Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (Unexpected identity in router certificate; IDENTITY; count 2; recommendation warn; host 97700DFE9F483596DDA6264C4D7DF7641E1E39CF at 0.0.2.0:3)
Apr 06 07:50:53 debian Tor[2164]: 1 connections have failed:
Apr 06 07:50:53 debian Tor[2164]:  1 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in OPEN
Apr 06 07:51:02 debian Tor[2164]: Tried connecting to router at 0.0.2.0:3, but RSA + ed25519 identity keys were not as expected: wanted 97700DFE9F483596DDA6264C4D7DF7641E1E39CF + no ed25519 key but got 97700DFE9F483596DDA6264C4D7DF7641E1E39CE + /LIpGKq6STgqkVJaKWDj92BCzGWbwqe3lBU+8hsQKP8.
Apr 06 07:51:02 debian Tor[2164]: Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (Unexpected identity in router certificate; IDENTITY; count 3; recommendation warn; host 97700DFE9F483596DDA6264C4D7DF7641E1E39CF at 0.0.2.0:3)
Apr 06 07:51:02 debian Tor[2164]: 2 connections have failed:
Apr 06 07:51:02 debian Tor[2164]:  2 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in OPEN
Apr 06 07:51:13 debian Tor[2164]: Tried connecting to router at 0.0.2.0:3, but RSA + ed25519 identity keys were not as expected: wanted 97700DFE9F483596DDA6264C4D7DF7641E1E39CF + no ed25519 key but got 97700DFE9F483596DDA6264C4D7DF7641E1E39CE + /LIpGKq6STgqkVJaKWDj92BCzGWbwqe3lBU+8hsQKP8.
Apr 06 07:51:13 debian Tor[2164]: Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (Unexpected identity in router certificate; IDENTITY; count 4; recommendation warn; host 97700DFE9F483596DDA6264C4D7DF7641E1E39CF at 0.0.2.0:3)
Apr 06 07:51:13 debian Tor[2164]: 3 connections have failed:
Apr 06 07:51:13 debian Tor[2164]:  3 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in OPEN
Apr 06 07:51:23 debian Tor[2164]: Tried connecting to router at 0.0.2.0:3, but RSA + ed25519 identity keys were not as expected: wanted 97700DFE9F483596DDA6264C4D7DF7641E1E39CF + no ed25519 key but got 97700DFE9F483596DDA6264C4D7DF7641E1E39CE + /LIpGKq6STgqkVJaKWDj92BCzGWbwqe3lBU+8hsQKP8.
Apr 06 07:51:23 debian Tor[2164]: Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (Unexpected identity in router certificate; IDENTITY; count 5; recommendation warn; host 97700DFE9F483596DDA6264C4D7DF7641E1E39CF at 0.0.2.0:3)
Apr 06 07:51:23 debian Tor[2164]: 4 connections have failed:
Apr 06 07:51:23 debian Tor[2164]:  4 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in OPEN
Apr 06 07:51:47 debian Tor[2164]: Tried connecting to router at 0.0.2.0:3, but RSA + ed25519 identity keys were not as expected: wanted 97700DFE9F483596DDA6264C4D7DF7641E1E39CF + no ed25519 key but got 97700DFE9F483596DDA6264C4D7DF7641E1E39CE + /LIpGKq6STgqkVJaKWDj92BCzGWbwqe3lBU+8hsQKP8.
Apr 06 07:51:47 debian Tor[2164]: Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (Unexpected identity in router certificate; IDENTITY; count 6; recommendation warn; host 97700DFE9F483596DDA6264C4D7DF7641E1E39CF at 0.0.2.0:3)
Apr 06 07:51:47 debian Tor[2164]: 5 connections have failed:
Apr 06 07:51:47 debian Tor[2164]:  5 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in OPEN
Apr 06 07:52:33 debian Tor[2164]: Tried connecting to router at 0.0.2.0:3, but RSA + ed25519 identity keys were not as expected: wanted 97700DFE9F483596DDA6264C4D7DF7641E1E39CF + no ed25519 key but got 97700DFE9F483596DDA6264C4D7DF7641E1E39CE + /LIpGKq6STgqkVJaKWDj92BCzGWbwqe3lBU+8hsQKP8.
Apr 06 07:52:33 debian Tor[2164]: Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (Unexpected identity in router certificate; IDENTITY; count 7; recommendation warn; host 97700DFE9F483596DDA6264C4D7DF7641E1E39CF at 0.0.2.0:3)
Apr 06 07:52:33 debian Tor[2164]: 6 connections have failed:
Apr 06 07:52:33 debian Tor[2164]:  6 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in OPEN
Apr 06 07:53:08 debian Tor[2164]: Tried connecting to router at 0.0.2.0:3, but RSA + ed25519 identity keys were not as expected: wanted 97700DFE9F483596DDA6264C4D7DF7641E1E39CF + no ed25519 key but got 97700DFE9F483596DDA6264C4D7DF7641E1E39CE + /LIpGKq6STgqkVJaKWDj92BCzGWbwqe3lBU+8hsQKP8.
Apr 06 07:53:08 debian Tor[2164]: Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (Unexpected identity in router certificate; IDENTITY; count 8; recommendation warn; host 97700DFE9F483596DDA6264C4D7DF7641E1E39CF at 0.0.2.0:3)
Apr 06 07:53:08 debian Tor[2164]: 7 connections have failed:
Apr 06 07:53:08 debian Tor[2164]:  7 connections died in state handshaking (Tor, v3 handshake) with SSL state SSL negotiation finished successfully in OPEN

Overall, this test shows that the configuration used in Whonix inside the 40_tor_control_panel.conf file for meek-azure is correct.

Maybe the cause we get that problem could It could mean that some process blocks the contact of Whonix to azure service.

Afterwards, I also did the same test with the same version of tor in both of OS (0.4.5.7) with the same versions of libraries (Tor 0.4.5.7 running on Linux with Libevent 2.1.12-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, Libzstd 1.4.8 and Glibc 2.31 as libc.) but I get the same issue on Whonix while on Debian works.

The difference between Debian and Whonix when Tor is connecting is that Debian reads only configuration files: /usr/share/tor/tor-service-defaults-torrc and /etc/tor/torrc. While Whonix reads (sudo journalctl -u tor@default):

Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Read configuration file "/etc/tor/torrc".
Including configuration file "/etc/torrc.d//60_network.conf".
Including configuration file "/etc/torrc.d//65_gateway.conf".
Including configuration file "/etc/torrc.d//65_leak_tests.conf".
Including configuration file "/etc/torrc.d//70_workstation.conf".
Including configuration file "/usr/share/tor/tor-service-defaults-torrc.anondist".
Including configuration file "/etc/torrc.d//95_whonix.conf".
Including configuration file "/usr/local/etc/torrc.d//40_tor_control_panel.conf".
Including configuration file "/usr/local/etc/torrc.d//50_user.conf".

The difference among the configuration files used on two OS:
/usr/share/tor/tor-service-defaults-torrc --> equal content on Whonix and Debian;
/etc/tor/torrc --> in Whonix the file refers to the /etc/torrc.d/ directory, in Debian we have the content that in Whonix is inside the 40_tor_control_panel.conf file;
The rest of the files is only in Whonix of course.
So, maybe the issue could be in one of these files that can generate some conflict? I don’t know.

PS: in the anon_connection_wizard.py file, at 1590 row, is there a “except selftem.connection.IncorrectCookieSize:” Maybe the correct form is not selftem but should be stem, right?
For the next Tor updates (as the 0.4.5.7) maybe you could get an error like “RuntimeError: dictionary keys changed during iteration”. If it happens, just edit the “/usr/lib/python3/dist-packages/stem/control.py” file by changing the 2273 row to “for key in list(reply):” (so, adding list()) Source: https://stackoverflow.com/questions/11941817/how-to-avoid-runtimeerror-dictionary-changed-size-during-iteration-error

A warn that I get in Whonix inside the tor logs when I connect to Tor network by anon-connection-wizard is:
Option 'DisableNetwork' used more than once; all but the last value will be ignored.
It does not generate issues (I think) but it could be a best practice to understand where is used two times: I’m seeing is used one time in 40_tor_control_panel.conf and on 60_network.conf. Since the warn message says that the “last value will be ignored” it means that the value in 40_tor_control_panel.conf will be always ignored so DisableNetwork is always set to 1?.

UPDATE: The problem is not related to the files shown above (60_x, 65_x and so on). I’m looking for obfs4proxy. I edited the content of configuration file as:

UseBridges 1
ClientTransportPlugin meek_lite exec /usr/bin/obfs4proxy --enableLogging --logLevel DEBUG
bridge meek_lite 0.0.2.0:3 97700DFE9F483596DDA6264C4D7DF7641E1E39CE url=https://meek.azureedge.net/ front=ajax.aspnetcdn.com

adding logging on obfs4proxy. The result of logs (/var/lib/tor/pt_state/obfs4proxy.log) shows the following:

2021/04/06 12:24:46 [NOTICE]: obfs4proxy-0.0.7 - launched
2021/04/06 12:24:46 [INFO]: obfs4proxy - initializing client transport listeners
2021/04/06 12:24:46 [INFO]: meek_lite - registered listener: 127.0.0.1:40147
2021/04/06 12:24:46 [INFO]: obfs4proxy - accepting connections
2021/04/06 12:24:47 [WARN]: meek_lite([scrubbed]:3) - closed connection: readfrom: io: read/write on closed pipe
2021/04/06 12:24:48 [WARN]: meek_lite([scrubbed]:3) - closed connection: readfrom: io: read/write on closed pipe
2021/04/06 12:24:49 [WARN]: meek_lite([scrubbed]:3) - closed connection: readfrom: io: read/write on closed pipe
2021/04/06 12:24:51 [WARN]: meek_lite([scrubbed]:3) - closed connection: readfrom: io: read/write on closed pipe
2021/04/06 12:24:52 [WARN]: meek_lite([scrubbed]:3) - closed connection: readfrom: io: read/write on closed pipe
2021/04/06 12:24:54 [WARN]: meek_lite([scrubbed]:3) - closed connection: readfrom: io: read/write on closed pipe
2021/04/06 12:24:57 [WARN]: meek_lite([scrubbed]:3) - closed connection: readfrom: io: read/write on closed pipe
2021/04/06 12:24:59 [WARN]: meek_lite([scrubbed]:3) - closed connection: readfrom: io: read/write on closed pipe
2021/04/06 12:25:02 [WARN]: meek_lite([scrubbed]:3) - closed connection: readfrom: io: read/write on closed pipe

The [WARN] logs are created when on the other side the anon-connection-wizard stucks at the 10% during the bootstrapping.

So, from this [WARN] it means that it is trying to do a read/write operations on a closed pipe… Maybe the requests are sent after a specific timeout after that the pipe will be closed… so I think this timeout should be increased.

I also checked the pipe connections by using sudo lsof | grep obfs4 on both machines and the only difference I get is that on Debian I have:

obfs4prox 15352 15353 obfs4prox debian-tor  cwd       DIR                8,1     4096          2 /
obfs4prox 15352 15353 obfs4prox debian-tor  rtd       DIR                8,1     4096          2 /
obfs4prox 15352 15353 obfs4prox debian-tor  txt       REG                8,1  5437776     291005 /usr/bin/obfs4proxy
obfs4prox 15352 15353 obfs4prox debian-tor  mem       REG                8,1  1839792     296277 /usr/lib/x86_64-linux-gnu/libc-2.31.so
obfs4prox 15352 15353 obfs4prox debian-tor  mem       REG                8,1   149520     296288 /usr/lib/x86_64-linux-gnu/libpthread-2.31.so
obfs4prox 15352 15353 obfs4prox debian-tor  mem       REG                8,1   177928     267663 /usr/lib/x86_64-linux-gnu/ld-2.31.so
obfs4prox 15352 15353 obfs4prox debian-tor    0r     FIFO               0,12      0t0     238331 pipe
obfs4prox 15352 15353 obfs4prox debian-tor    1w     FIFO               0,12      0t0     238332 pipe
obfs4prox 15352 15353 obfs4prox debian-tor    2w     FIFO               0,12      0t0     238333 pipe
obfs4prox 15352 15353 obfs4prox debian-tor    3w      REG                8,1      279    1314830 /var/lib/tor/pt_state/obfs4proxy.log
obfs4prox 15352 15353 obfs4prox debian-tor    4u  a_inode               0,13        0       8261 [eventpoll]
obfs4prox 15352 15353 obfs4prox debian-tor    5u     IPv4             237064      0t0        TCP localhost:41397 (LISTEN)
obfs4prox 15352 15353 obfs4prox debian-tor    6u     IPv4             237067      0t0        TCP localhost:41397->localhost:44970 (ESTABLISHED)
obfs4prox 15352 15353 obfs4prox debian-tor    7u     IPv4             234969      0t0        TCP debian:41908->152.199.19.160:https (ESTABLISHED)

and on Whonix I have:

obfs4prox 6427 6428 obfs4prox debian-tor  cwd       DIR                8,1     4096          2 /
obfs4prox 6427 6428 obfs4prox debian-tor  rtd       DIR                8,1     4096          2 /
obfs4prox 6427 6428 obfs4prox debian-tor  txt       REG                8,1  5516056     133634 /usr/bin/obfs4proxy
obfs4prox 6427 6428 obfs4prox debian-tor  mem       REG                8,1  1839792     532341 /lib/x86_64-linux-gnu/libc-2.31.so
obfs4prox 6427 6428 obfs4prox debian-tor  mem       REG                8,1   149520     532352 /lib/x86_64-linux-gnu/libpthread-2.31.so
obfs4prox 6427 6428 obfs4prox debian-tor  mem       REG                8,1   177928     524957 /lib/x86_64-linux-gnu/ld-2.31.so
obfs4prox 6427 6428 obfs4prox debian-tor    0r     FIFO               0,12      0t0      80980 pipe
obfs4prox 6427 6428 obfs4prox debian-tor    1w     FIFO               0,12      0t0      80981 pipe
obfs4prox 6427 6428 obfs4prox debian-tor    2w     FIFO               0,12      0t0      80982 pipe
obfs4prox 6427 6428 obfs4prox debian-tor    3w      REG                8,1     5086    5506010 /var/lib/tor/pt_state/obfs4proxy.log
obfs4prox 6427 6428 obfs4prox debian-tor    4u  a_inode               0,13        0       8261 [eventpoll]
obfs4prox 6427 6428 obfs4prox debian-tor    5r     FIFO               0,12      0t0      79794 pipe
obfs4prox 6427 6428 obfs4prox debian-tor    6w     FIFO               0,12      0t0      79794 pipe
obfs4prox 6427 6428 obfs4prox debian-tor    7u     IPv4              79795      0t0        TCP localhost:41231 (LISTEN)

So the main difference is that on Debian I have at the end of each cycle:

obfs4prox 15352 15353 obfs4prox debian-tor    5u     IPv4             237064      0t0        TCP localhost:41397 (LISTEN)
obfs4prox 15352 15353 obfs4prox debian-tor    6u     IPv4             237067      0t0        TCP localhost:41397->localhost:44970 (ESTABLISHED)
obfs4prox 15352 15353 obfs4prox debian-tor    7u     IPv4             234969      0t0        TCP debian:41908->152.199.19.160:https (ESTABLISHED)

while on Whonix I have only:

obfs4prox 6427 6428 obfs4prox debian-tor    7u     IPv4              79795      0t0        TCP localhost:41231 (LISTEN)

without establishing a connection to another socket.

Indeed, giving ss command on Debian I have:

tcp                  ESTAB                 0                     0                                                          127.0.0.1:44970                                        127.0.0.1:41397                 
tcp                  ESTAB                 0                     0                                                          127.0.0.1:41397                                        127.0.0.1:44970                 
tcp                  ESTAB                 0                     0                                                          10.0.2.15:45918                                   152.199.19.160:https 

Instead on Whonix I don’t have an output containing this similar information.

2nd UPDATE: I performed a test also on Kicksecure-XFCE-15.0.1.5.4 by inserting the rows related to meek-azure in /etc/tor/torrc and it works correctly as shown in the following logs:

Apr 06 19:45:42 localhost.localdomain systemd[1]: Stopping Anonymizing overlay network for TCP...
Apr 06 19:45:42 localhost.localdomain Tor[493]: Interrupt: exiting cleanly.
Apr 06 19:45:42 localhost.localdomain systemd[1]: tor@default.service: Succeeded.
Apr 06 19:45:42 localhost.localdomain systemd[1]: Stopped Anonymizing overlay network for TCP.
Apr 06 19:45:42 localhost.localdomain systemd[1]: Starting Anonymizing overlay network for TCP...
Apr 06 19:45:42 localhost.localdomain tor[2717]: Apr 06 19:45:42.513 [notice] Tor 0.4.4.6 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.8.
Apr 06 19:45:42 localhost.localdomain tor[2717]: Apr 06 19:45:42.513 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Apr 06 19:45:42 localhost.localdomain tor[2717]: Apr 06 19:45:42.513 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Apr 06 19:45:42 localhost.localdomain tor[2717]: Apr 06 19:45:42.513 [notice] Read configuration file "/etc/tor/torrc".
Apr 06 19:45:42 localhost.localdomain tor[2717]: Configuration was valid
Apr 06 19:45:42 localhost.localdomain tor[2718]: Apr 06 19:45:42.679 [notice] Tor 0.4.4.6 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.8.
Apr 06 19:45:42 localhost.localdomain tor[2718]: Apr 06 19:45:42.679 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Apr 06 19:45:42 localhost.localdomain tor[2718]: Apr 06 19:45:42.679 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Apr 06 19:45:42 localhost.localdomain tor[2718]: Apr 06 19:45:42.679 [notice] Read configuration file "/etc/tor/torrc".
Apr 06 19:45:42 localhost.localdomain tor[2718]: Apr 06 19:45:42.682 [notice] Opening Socks listener on 127.0.0.1:9050
Apr 06 19:45:42 localhost.localdomain tor[2718]: Apr 06 19:45:42.682 [notice] Opened Socks listener on 127.0.0.1:9050
Apr 06 19:45:42 localhost.localdomain Tor[2718]: Tor 0.4.4.6 running on Linux with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd 1.3.8.
Apr 06 19:45:42 localhost.localdomain Tor[2718]: Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Apr 06 19:45:42 localhost.localdomain Tor[2718]: Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Apr 06 19:45:42 localhost.localdomain Tor[2718]: Read configuration file "/etc/tor/torrc".
Apr 06 19:45:42 localhost.localdomain Tor[2718]: Opening Socks listener on 127.0.0.1:9050
Apr 06 19:45:42 localhost.localdomain Tor[2718]: Opened Socks listener on 127.0.0.1:9050
Apr 06 19:45:42 localhost.localdomain Tor[2718]: Bootstrapped 0% (starting): Starting
Apr 06 19:45:43 localhost.localdomain Tor[2718]: Starting with guard context "bridges"
Apr 06 19:45:43 localhost.localdomain Tor[2718]: Delaying directory fetches: No running bridges
Apr 06 19:45:43 localhost.localdomain Tor[2718]: Signaled readiness to systemd
Apr 06 19:45:43 localhost.localdomain systemd[1]: Started Anonymizing overlay network for TCP.
Apr 06 19:45:44 localhost.localdomain Tor[2718]: Opening Socks listener on /run/tor/socks
Apr 06 19:45:44 localhost.localdomain Tor[2718]: Opened Socks listener on /run/tor/socks
Apr 06 19:45:44 localhost.localdomain Tor[2718]: Opening Control listener on /run/tor/control
Apr 06 19:45:44 localhost.localdomain Tor[2718]: Opened Control listener on /run/tor/control
Apr 06 19:45:44 localhost.localdomain Tor[2718]: Bootstrapped 1% (conn_pt): Connecting to pluggable transport
Apr 06 19:45:44 localhost.localdomain Tor[2718]: Bootstrapped 2% (conn_done_pt): Connected to pluggable transport
Apr 06 19:45:44 localhost.localdomain Tor[2718]: Bootstrapped 10% (conn_done): Connected to a relay
Apr 06 19:45:48 localhost.localdomain Tor[2718]: Bootstrapped 14% (handshake): Handshaking with a relay
Apr 06 19:45:51 localhost.localdomain Tor[2718]: Bootstrapped 15% (handshake_done): Handshake with a relay done
Apr 06 19:45:51 localhost.localdomain Tor[2718]: Bootstrapped 20% (onehop_create): Establishing an encrypted directory connection
Apr 06 19:45:54 localhost.localdomain Tor[2718]: Bootstrapped 25% (requesting_status): Asking for networkstatus consensus
Apr 06 19:45:57 localhost.localdomain Tor[2718]: new bridge descriptor 'cymrubridge02' (fresh): $97700DFE9F483596DDA6264C4D7DF7641E1E39CE~cymrubridge02 at 0.0.2.0
Apr 06 19:45:57 localhost.localdomain Tor[2718]: Bootstrapped 75% (enough_dirinfo): Loaded enough directory info to build circuits
Apr 06 19:45:58 localhost.localdomain Tor[2718]: Bootstrapped 76% (ap_conn_pt): Connecting to pluggable transport to build circuits
Apr 06 19:45:58 localhost.localdomain Tor[2718]: Bootstrapped 77% (ap_conn_done_pt): Connected to pluggable transport to build circuits
Apr 06 19:45:58 localhost.localdomain Tor[2718]: Bootstrapped 85% (ap_conn_done): Connected to a relay to build circuits
Apr 06 19:46:02 localhost.localdomain Tor[2718]: Bootstrapped 89% (ap_handshake): Finishing handshake with a relay to build circuits
Apr 06 19:46:03 localhost.localdomain Tor[2718]: Bootstrapped 90% (ap_handshake_done): Handshake finished with a relay to build circuits
Apr 06 19:46:03 localhost.localdomain Tor[2718]: Bootstrapped 95% (circuit_create): Establishing a Tor circuit
Apr 06 19:46:15 localhost.localdomain Tor[2718]: Bootstrapped 100% (done): Done

Summarizing, meek-azure works correctly on Debian 10.9 and Kicksecure-XFCE-15.0.1.5.4, but not on Whonix Gateway (CLI and XFCE).

So the issue could be caused by a Whonix component. I tried also to access the whonix_firewall script (/usr/bin/whonix_firewall), commenting all the functions inside main(), renaming also its configuration files in the /etc/whonix_firewall.d/ directory as .OLD. I also used sudo service whonix-firewall stop and sudo service whonix-firewall-restart stop commands but I get always the same error reported ath the beginning.

1 Like

Issue found. Whonix-Gateway System DNS over Clearnet is required for meek lite. These instructions will make it work:

Reference:

Solution: add this feature to ACW. I’ll look into that now.

1 Like

@Patrick
Excellent. I confirm it works too. And your post answers also to my question: Whonix - Force traffic to clearnet with no Tor

Thank you.

@Patrick when the updated ACW will be released and in which feed I can get this update?

No ETA.

This is now in Whonix developers repository.

See also:
https://www.whonix.org/wiki/Reporting_Bugs#Package_Upgrade_Policy

[Imprint] [Privacy Policy] [Cookie Policy] [Terms of Use] [E-Sign Consent] [DMCA] [Contributors] [Investors] [Priority Support] [Professional Support]