Bridge Sanity Check

phabricator-migrator · February 19, 2024, 5:53pm

Information

ID: 56
PHID: PHID-TASK-irpdwjk34wfxhuol4nhb
Author: JasonJAyalaP
Status at Migration Time: open
Priority at Migration Time: Normal

Description

migrated from:
https://github.com/Whonix/Whonix/issues/316

There is an attack bridges can perform on first-time users. This involves feeding old consensus data (which can be up to a week old).

We could use anondate to parse Tor consensus from two sources:

downloaded by Tor
(multiple times) downloaded by python-stem

Treat the bridge’s consensus as untrusted and not factor it in.

sdwdate / sdwdate-gui has already a good infrastructure.

To inform the user about the state of network time synchronization. A progress indicator, telling them to wait until it’s done before using the internet. One more sanity check that adds up to the wait is negligible. Also this is very similar to the sanity check planned in T151.
sdwdate prerequisite would wait until this check could even be run - A standalone bridgesanitycheck cannot run before Tor starts serving anyhow.

Give it its own indicator. It shouldn’t wait for sdwdate.

Rely on Tor stem in all cases.

Let’s implement sdwdate Tor Consensus Time Sanity Check (T151) first, see how that goes and then get back to this one.

Comments

Patrick

2018-07-09 06:10:40 UTC

From #sdwdate log. Clock was right but I got this using a bridge.
2018-07-09 05:54 - sdwdate - INFO - Prerequisite check: The clock is sane.
Within build timestamp Fri Aug  5 01:41:02 UTC 2016 and expiration timestamp Tue May 17 10:00:00 UTC 2033.
2018-07-09 05:54 - sdwdate - INFO - Prerequisite check: The clock is fast. Clock is faster than consensus/valid-until 2018-07-09 02:00:00.
So actually the clock wasn’t fast but the Tor consensus was stale. Need to modify that #sdwdate message. Good reason to implement this ticket.