Project

General

Profile

Bug #15548

Tails can't establish a connection with obfs4 bridges and a hardware clock >> UTC

Added by goupille 5 months ago. Updated 18 days ago.

Status:
Confirmed
Priority:
Elevated
Assignee:
Category:
Tor configuration
Target version:
Start date:
05/09/2018
Due date:
% Done:

0%

QA Check:
Info Needed
Feature Branch:
Type of work:
Research
Blueprint:
Starter:
Affected tool:

Description

Several users reported having issues with obfs4 since a few weeks. I tried with the following bridges


obfs4 76.74.178.195:9443 406A8B5869B72221036291407EC3688C69995F80 cert=FY2R16JOoE2VNCU2gVLWBj6Gg+YBP7mTLU5zl12Fz9iC5TQG6SqE71CFhD3zIuJcEFrcMQ iat-mode=0
obfs4 91.89.79.175:43099 681DD069768F8DF5C94284FFE8CEA600C6EAFB86 cert=Dux9bBro6xfxb7rUr8wdp0TephA7wMV0MjPMAcNqkU/r1Q+56EpHypOFZHRZFDukZNCHYg iat-mode=0
obfs4 34.203.58.40:9443 A3C8B95009DB61BE34B2628C9B9B4E66FCA32FA3 cert=etaJXxltJNQxJlKxVgGXWakop242cHNtzxG/GKroXYPTlzvmsYh818WrcIJ5cZ4DbZREJA iat-mode=0

and ended up with Tor launcher stuck on "Loading Network Consensus" for at least 15 minutes. I saw this behaviour two times on three trials.

I attached a whisperback report and the content of /var/log/tor/log, they are showing a weird jump back in the time :

Apr 20 14:17:56.000 [info] connection_edge_process_inbuf(): data from edge while in 'waiting for connect response' state. Sending it anyway. package_partial=1, buflen=214
Apr 20 14:17:56.000 [info] handle_control_authenticate(): Authenticated control connection (23)
Apr 20 11:30:00.000 [notice] Interrupt: exiting cleanly.
Apr 20 11:30:00.000 [info] or_state_save(): Saved state to "/var/lib/tor/state" 

bug report - obfs4 (554 KB) goupille, 04/20/2018 02:24 PM

journal.txt View (401 KB) mercedes508, 06/15/2018 12:22 PM

torlog.txt View (303 KB) mercedes508, 06/15/2018 12:22 PM


Subtasks

Feature #15599: Improve known issues about clock going backwardsIn Progresscbrownstein


Related issues

Related to Tails - Bug #15168: Improve UX when hardware clock is set to localtime in a timezone >> UTC In Progress 01/15/2018
Related to Tails - Bug #9268: obfs4 bridges often don't work (maybe MTU?) Confirmed 04/21/2015

History

#1 Updated by intrigeri 5 months ago

  • Subject changed from Tails can't establish a connection with obfs4 bridges to Tails can't establish a connection with obfs4 bridges and a hardware clock >> UTC
  • Category set to Tor configuration
  • Assignee changed from intrigeri to goupille
  • Target version set to Tails_3.7
  • QA Check set to Info Needed
Apr 20 14:17:55 amnesia time[16223]: Waiting for a Tor consensus file to contain a valid time interval
Apr 20 14:17:55 amnesia nm-dispatcher[7795]: /var/lib/tor/ CLOSE_WRITE,CLOSE cached-descriptors.new
Apr 20 14:17:56 amnesia nm-dispatcher[7795]: /var/lib/tor/ CLOSE_WRITE,CLOSE unverified-microdesc-consensus.tmp
Apr 20 14:17:56 amnesia time[16259]: A Tor consensus file now contains a valid time interval.
Apr 20 14:17:56 amnesia time[16262]: We do not have a Tor verified consensus, let's use the unverified one.
Apr 20 14:17:56 amnesia time[16263]: Waiting for the chosen Tor consensus file to contain a valid time interval...
Apr 20 14:17:56 amnesia time[16265]: The chosen Tor consensus now contains a valid time interval, let's use it.
Apr 20 14:17:56 amnesia time[16269]: Tor: valid-after=2018-04-20 10:00:00 | valid-until=2018-04-20 13:00:00
Apr 20 14:17:56 amnesia time[16272]: Current time is 2018-04-20 14:17:56
Apr 20 14:17:56 amnesia time[16277]: Current time is not in valid Tor range, setting to middle of this range: [2018-04-20 11:30:00]
Apr 20 11:30:00 amnesia systemd[1]: Stopping Anonymizing overlay network for TCP...
-- Subject: Unit tor@default.service has begun shutting down
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit tor@default.service has begun shutting down.
Apr 20 11:30:00 amnesia systemd[1]: Stopped Anonymizing overlay network for TCP.
-- Subject: Unit tor@default.service has finished shutting down
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit tor@default.service has finished shutting down.
Apr 20 11:30:00 amnesia systemd[1]: Starting Anonymizing overlay network for TCP...
-- Subject: Unit tor@default.service has begun start-up
-- Defined-By: systemd
-- Support: https://www.debian.org/support
-- 
-- Unit tor@default.service has begun starting up.

So there was a mismatch between the system clock (that we initialize to whatever the hardware clock says) and the Tor consensus we got.
To me this looks like "Problems when the system clock goes backwards" from https://tails.boum.org/support/known_issues/.

Could you please ensure the hardware clock is set to UTC (not local time) and retry?

#2 Updated by intrigeri 5 months ago

  • Related to Bug #15168: Improve UX when hardware clock is set to localtime in a timezone >> UTC added

#3 Updated by intrigeri 5 months ago

Assuming goupille confirms this was caused by a RTC set to localtime >> UTC: if we get something done on #15168 soon, great, this will fix this problem; otherwise, I'm starting to think we should notice when we would like to set the clock backwards and point the user to our doc that explains how they should set their RTC to UTC.

#4 Updated by goupille 5 months ago

  • Assignee changed from goupille to intrigeri

those logs are coming from a VM, I rebooted the VM three times and could reproduce the error the first and the third times. the lgos are coming from the last session. libvirt says that the VM clock is set to UTC.

jumping to 11:30:00 exactly seems really weird, iirc, gnome's time was set to paris time when the error occured, so UTC should have been 12:17:56, no ?

#5 Updated by intrigeri 5 months ago

  • Assignee changed from intrigeri to goupille

goupille wrote:

jumping to 11:30:00 exactly seems really weird,

That's not random, it's our time sync system in play: Current time is not in valid Tor range, setting to middle of this range: [2018-04-20 11:30:00]. This happens because "Current time is not in valid Tor range", which should never happen if the RTC is in UTC and the host system's clock is correct.

iirc, gnome's time was set to paris time when the error occured

My Tails VMs (with RTC in UTC) display UTC time before the Tails time sync' is done, as expected. So if you're seeing localtime instead, then it strongly suggests that either your VM actually has a RTC set to Paris time (and not to UTC) — which could be a configuration error or a libvirt/QEMU bug — or the host system has a wrong clock or timezone settings. In any case, the result is the same: Tails is given Paris time and believes it's UTC, which results in "Current time is not in valid Tor range".

Please share:

  • the content of /etc/timezone on the host system
  • the output of date && sudo hwclock on the host system; and check that the time is correct using whatever online clock service you want
  • the full clock section of your test VM's definition (virsh dumpxml $VM)

#6 Updated by intrigeri 5 months ago

Also, if you want to double check, start Tails, enable offline mode in the Greeter, and check the system time after login: it should be the correct UTC time; if it's not, then the underlying virtualization stack or host system is either buggy or badly configured.

#7 Updated by goupille 5 months ago

intrigeri wrote:

My Tails VMs (with RTC in UTC) display UTC time before the Tails time sync' is done, as expected.

my mistake, my VMs are displaying UTC time even before the time sync...

  • the content of /etc/timezone on the host system
  • the output of date && sudo hwclock on the host system; and check that the time is correct using whatever online clock service you want
  • the full clock section of your test VM's definition (virsh dumpxml $VM)

I sent you an email with those informations (ticket number in the subject)

#8 Updated by intrigeri 5 months ago

my mistake, my VMs are displaying UTC time even before the time sync...

OK, then please retry and upon failure, send me:

  • the content of the Journal
  • the Tor log
  • the accurate time (with timezone) from outside of Tails

Rationale: I want to check if the Tor consensus is OK of not.

#9 Updated by Mackpetrova 5 months ago

Set network proxy to manual and use those settings

#10 Updated by Anonymous 5 months ago

this has been a problem for soooo long.
time syncing has been failing for months if not years, whenever a bridge (obfs4) is selected right at the startup (non persistent mode).
would be great if this would fixed for good.

it is hilariously stupid to need to select "use a bridge" at startup, connected to a regular tor node until time syncing is done, disconnect again, open up the tor settings fast enough and THEN to insert the bridge info... (_)

#11 Updated by bertagaz 5 months ago

  • Target version changed from Tails_3.7 to Tails_3.8

#12 Updated by mercedes508 3 months ago

intrigeri wrote:

my mistake, my VMs are displaying UTC time even before the time sync...

OK, then please retry and upon failure, send me:

  • the content of the Journal
  • the Tor log
  • the accurate time (with timezone) from outside of Tails

Rationale: I want to check if the Tor consensus is OK of not.

I'm attaching these logs from a user experiencing this issue.
The timezone is UTC.

#13 Updated by intrigeri 3 months ago

I'm attaching these logs from a user experiencing this issue.

Could you reproduce it?

The timezone is UTC.

You mean the hardware clock?

#14 Updated by intrigeri 3 months ago

  • Target version changed from Tails_3.8 to Tails_3.9

#15 Updated by u about 1 month ago

Anonymous wrote:

it is hilariously stupid to need to select "use a bridge" at startup, connected to a regular tor node until time syncing is done, disconnect again, open up the tor settings fast enough and THEN to insert the bridge info... (_)

Please read our code of conduct: https://tails.boum.org/contribute/working_together/code_of_conduct/
We very much appreciate being excellent to each other, thank you.

#16 Updated by u about 1 month ago

hi goupille, is this still a thing?

#17 Updated by u about 1 month ago

  • Related to Bug #9268: obfs4 bridges often don't work (maybe MTU?) added

#18 Updated by intrigeri 18 days ago

  • Target version changed from Tails_3.9 to Tails_3.10

Also available in: Atom PDF