-
- View options
Activity
Trac:
Parent: N/A to #3059 (moved)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".)
Trac:
Summary: get independent from host clock / insecure NTP to get independent from host clock time / insecure NTPHow 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 (moved) to securely get the time.
- Once torclock used #6894 (moved) 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 (moved) 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.
Trac:
Parent: #3059 (moved) to N/ASee also #17739 (moved) and #17728 (moved) for changes to how we warn about clock skew.
Trac:
Severity: N/A to Normal
Sponsor: N/A to N/A
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?
Trac:
Reviewer: N/A to N/A
Status: new to closed
Resolution: N/A to wontfix
