Page MenuHomePhabricator

Bridge Sanity Check
Open, NormalPublic


migrated from:

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.



Event Timeline

JasonJAyalaP raised the priority of this task from to Normal.
JasonJAyalaP updated the task description. (Show Details)
JasonJAyalaP added a subscriber: JasonJAyalaP.
Patrick set Impact to Normal.
Patrick renamed this task from Bridge Sanity Check (sdwdate plugin) to Bridge Sanity Check.Mar 5 2018, 9:28 PM
Patrick updated the task description. (Show Details)

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.