Opened 10 years ago

Last modified 17 months ago

#2628 new project

Be smarter about launching connections to authorities to learn about clock skew

Reported by: nickm Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-client clock-skew AffectsTails
Cc: ioerror, adrelanos@…, catalyst, intrigeri Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


While applying altf4's code related to bug1074, some possible enhancements came up. They wouldn't be too hard to do.

Right now, we notice clock skew for two reasons: a time from a netinfo cell is different from ours, and a time in an HTTP response header is different from ours. In the netinfo case, if the skew came from an authority, we believe it. If not, and we haven't gotten a netinfo from an authority, we launch an OR connection to an authority.

In fact, we should be a bit more sophisticated:

  • Any authenticated time from an authority should count as "hearing the time from an authority". This includes not only netinfo cells but also authenticated directory connections.
  • Maybe, skew information from regular HTTP responses should also count as "hearing that we are skewed from a non-authority".
  • Instead of keeping track of *whether* we've heard the correct time from an authority, we should keep track of *when* we heard from the authority. In other words, if we last heard about the correct time from an authority an hour ago and somebody else disagrees with them, the authority is probably right. But if we last heard about the correct time a week ago, we might want to ask again.

Child Tickets

Change History (15)

comment:1 Changed 10 years ago by Sebastian

Generally the way I think it should work is that if we learn from a certain fraction of sources of time we have access to (our bridges, our guards/directory guards) that our clock is skewed we should try to get an opinion with higher authority. This could be either a few more directory mirrors, or directory authorities (depending on how much we've learned so far). Once we're pretty sure our time is wrong we should warn the user.

Additionally, I think we should implement that config option that allows you to say "my clock is skewed by X seconds". To go along with it, there should be an option to automatically adjust that configuration value as we learn about clock skew from a reliable source (n directory authorities for example). This could be turned on for TBB and live CDs etc, basically for Tor setups that are supposed to work anywhere without the necessary admin rights/VM controls/etc required to change the system time.

A few more things to consider here are:

  • Bridge users: Making direct connections to the directory authorities is not only not feasible, but also actively harmful. Any solution that we come up with should take this into account by either special-casing bridge users or not requiring direct connections to the directory authority. Same goes for regular clients who picked directory guards (once we have them).
  • Directory authority load: If a bunch of relays have the wrong time and clients connect to directory authorities too often, this will be a big overhead (because we'd want the time data to be authenticated).
  • Implementation complexity: If we only do the first idea I presented above, the complexity is likely too high for not enough gain. If we do the latter however we need it.

comment:2 Changed 9 years ago by ioerror

Cc: ioerror added

comment:3 Changed 8 years ago by nickm

Keywords: tor-client added

comment:4 Changed 8 years ago by nickm

Component: Tor ClientTor

comment:5 Changed 8 years ago by karsten

Keywords: SponsorZ added; easy removed
Type: enhancementproject

Adding two ideas from Nick and Roger, turning this ticket into a sponsor Z project ticket, and taking away the "easy" tag, because this requires at least some design.

  • Nick says: "There's also a little coding challenge in that we'd need the ability to provisionally receive directory information and build circuits while our clock was skewed. Right now, we trust our clock, and reject information that's too far in the past or future. But we'd need a way to provisionally accept information instead, but not use it to build circuits for user traffic until we became convinced that it was still usable after correcting our clocks."
  • Roger says: "Also include plans to export the correct time via the controller interface so e.g. Tails LiveCD can use it to set its system time."

comment:6 Changed 6 years ago by proper

Cc: adrelanos@… added

comment:7 Changed 4 years ago by cass

Severity: Blocker

This ticket is tagged SponsorZ, but it looks like progress stalled a while ago. Is this still a thing that needs funding? Is it being addressed under other tickets?

comment:8 Changed 4 years ago by cass

Severity: BlockerNormal

comment:9 Changed 4 years ago by nickm

This is probably fundable under some broader heading, like "getting time right" or "better supporting clients that don't have a good view of the current time." But this specific item is probably not fundable per se.

comment:10 Changed 3 years ago by nickm

Also see #2178

comment:11 Changed 3 years ago by catalyst

Cc: catalyst added
Keywords: clock-skew added

comment:12 Changed 2 years ago by intrigeri

Cc: intrigeri added

comment:13 Changed 17 months ago by gaba

Keywords: tails added; SponsorZ removed

comment:14 Changed 17 months ago by gaba

Keywords: AffectTails added; tails removed

comment:15 Changed 17 months ago by gaba

Keywords: AffectsTails added; AffectTails removed
Note: See TracTickets for help on using tickets.