Opened 5 weeks ago

Last modified 4 weeks ago

#32439 new defect

tor can't bootstrap with obfs4 bridge and skewed clock

Reported by: intrigeri Owned by:
Priority: Medium Milestone:
Component: Circumvention/Obfs4 Version:
Severity: Normal Keywords: bootstrap, clock-skew, AffectsTails
Cc: phw Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Environment: Debian unstable, Tor Browser 9.0.1, system clock set 2h in the future.

Observed behavior: Tor Launcher says "Connected to bridge" but the progress bar is stuck at a very low percentage. After a while, the "Copy Tor Log To Clipboard" button appears.

Impact: Tails users whose hardware clock is set to local time, in a timezone that's not close enough to UTC, cannot use obfs4 bridges. Unfortunately, that's quite common, because:

  • Windows sets the hardware clock to local time by default (as opposed to Unix systems, that tend to assume the hardware clock is in UTC)
  • many places where one needs obfs4 to use Tor are 4-7 hours ahead of UTC
  • Tails can't guess whether the hardware clock is set to UTC time or to local time; it assumes it's UTC time

Corresponding tor log (actual obfs4 bridges IP & port redacted):

11/9/19, 16:39:11.903 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
11/9/19, 16:39:11.903 [NOTICE] Switching to guard context "bridges" (was using "default")
11/9/19, 16:39:11.903 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
11/9/19, 16:39:11.903 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
11/9/19, 16:39:11.903 [NOTICE] Opening Socks listener on 127.0.0.1:9150
11/9/19, 16:39:11.903 [NOTICE] Opened Socks listener on 127.0.0.1:9150
11/9/19, 16:39:11.903 [NOTICE] Renaming old configuration file to "/home/toto/tor-browser_en-US/Browser/TorBrowser/Data/Tor/torrc.orig.1"
11/9/19, 16:39:12.885 [NOTICE] Bootstrapped 1% (conn_pt): Connecting to pluggable transport
11/9/19, 16:39:12.887 [NOTICE] Bootstrapped 2% (conn_done_pt): Connected to pluggable transport
11/9/19, 16:40:06.330 [WARN] Proxy Client: unable to connect to $IP1:$PORT1 ("general SOCKS server failure")
11/9/19, 16:40:12.957 [WARN] Proxy Client: unable to connect to $IP2:$PORT2 ("general SOCKS server failure")
11/9/19, 16:40:13.120 [WARN] Proxy Client: unable to connect to $IP3:$PORT3 ("general SOCKS server failure")
11/9/19, 16:41:10.165 [WARN] Proxy Client: unable to connect to $IP1:$PORT1 ("general SOCKS server failure")
11/9/19, 16:41:14.240 [WARN] Proxy Client: unable to connect to $IP2:$PORT2 ("general SOCKS server failure")
11/9/19, 16:41:20.420 [WARN] Proxy Client: unable to connect to $IP3:$PORT3 ("general SOCKS server failure")

Child Tickets

Change History (2)

comment:1 Changed 5 weeks ago by intrigeri

Note that this behavior is inconsistent with the "direct connection to Tor" and "using regular bridges" use cases, that work just fine with a ±24 hours clock skew nowadays.

comment:2 Changed 4 weeks ago by yawning

This is not a defect, this is how the protocol is specified.

Servers should not respond to replayed handshakes. In order to limit the amount of history that each server needs to keep, the number of hours since the UNIX epoch is included as part of the handshake authentication digest.

As a concession to reality, per the specification, each server will tolerate a skew of up to +/- 1 hour. While it is not overly difficult to increase the amount of skew tolerated, this will result in increased resource consumption on the server side, and more expensive handshakes.

Note: See TracTickets for help on using tickets.