Opened 7 years ago

Closed 2 years ago

#8170 closed enhancement (wontfix)

get independent from host clock time / insecure NTP

Reported by: proper Owned by:
Priority: High Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-client
Cc: Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

NTP server admins can willingly or if their server gets compromised and any man-in-the-middle can tamper with NTP replies and therefore introduce a unique clock skew.

Almost no one is using authenticated NTP, because there are no instructions in a forum or blog how to enable NTP authentication. Therefore almost everyone uses standard configuration and is at risk.

Also due to a clock defect, low battery, clock can skew without tampering with NTP.

Since the browser 1 and other applications transmit time stamps, it can be used to track individual users. For example, a clock skew of +/-30 minutes may not worry the user ("That damn clock is wrong again. I use my watch instead.") but could identify the user even when using Tor.

Also adversaries who didn't introduce the clock skew could use it to identify users. If the user visits a website under adversary control 2 without Tor for some non-anonymous activity, it knows the clock skew. Later, if the user visits another website under adversary control, it can see the same clock skew, which is at least a strong anonymity set reduction.


1 Also #1517 "Provide JS with reduced time precision" wouldn't help much, since it wouldn't do something about bigger clock skews.
2 Nowadays with services like google analytics and facebook like button, there are servers which are present on a high percentage of all websites.

Child Tickets

Change History (13)

comment:1 Changed 7 years ago by proper

Parent ID: #3059

comment:2 Changed 7 years ago by nickm

Milestone: Tor: 0.2.5.x-final

comment:3 Changed 6 years ago by nickm

Keywords: tor-client added
Type: defectenhancement

comment:4 Changed 6 years ago by proper

Summary: get independent from host clock / insecure NTPget independent from host clock time / insecure NTP

I don't think it's a good idea to hold ones breath for more NTP autokey servers and operating systems to use it - NTP autokey does not support NAT, thus it won't be a solution for most users until NAT dies. (Not sure if NAT will die when IPv6 is established, can imagine, it will be sold as "feature".)

comment:5 Changed 6 years ago by proper

How could this be solved? Some thoughts... (Also known as, "how Tor fixes the mess, if operating systems and NTP messed up".)

  • torclock is the hypothetical name of a time synchronization mechanism and package to be invented which fits in to the threat model of Tor.
  • Tor deb/rpm packages recommends [1] torclock.
  • torclock deb/rpm packages should conflict [2] NTP, rdate and other insecure similar packages.
  • torclock dep/rpm packages depend on Tor.
  • torclock uses #6894 to securely get the time.
  • Once torclock used #6894 to get the system time, it sets the system time.
    • I am quite sure, that this will require installation (root) on most systems, hence it will be difficult to use in the portable TBB package, so perhaps TBB has to use #6894 directly.
  • Tor waits until torclock has set the system time. (Unless told, not to care using torrc or control protocol.)

Feedback?

Better ideas?


Footnotes:
[1] Recommends: This declares a strong, but not absolute, dependency. The Recommends field should list packages that would be found together with this one in all but unusual installations.
[2] Conflicts: When one binary package declares a conflict with another using a Conflicts field, dpkg will refuse to allow them to be unpacked on the system at the same time.

comment:6 Changed 6 years ago by nickm

Milestone: Tor: 0.2.5.x-finalTor: 0.2.???

comment:7 Changed 5 years ago by mikeperry

Parent ID: #3059

comment:9 Changed 4 years ago by teor

Severity: Normal

See also #17739 and #17728 for changes to how we warn about clock skew.

comment:10 Changed 3 years ago by teor

Milestone: Tor: 0.2.???Tor: 0.3.???

Milestone renamed

comment:11 Changed 3 years ago by nickm

Keywords: tor-03-unspecified-201612 added
Milestone: Tor: 0.3.???Tor: unspecified

Finally admitting that 0.3.??? was a euphemism for Tor: unspecified all along.

comment:12 Changed 2 years ago by nickm

Keywords: tor-03-unspecified-201612 removed

Remove an old triaging keyword.

comment:13 Changed 2 years ago by nickm

Resolution: wontfix
Status: newclosed

This is important, but it's not something to do inside Tor. Rather than do our own secure NTP replacement as part of Tor, we should just recommend other people's secure NTP replacements as part of a Tor deployment. Roughtime, anyone?

Note: See TracTickets for help on using tickets.