|author||Tails developers <firstname.lastname@example.org>||2012-01-28 11:50:00 +0100|
|committer||Tails developers <email@example.com>||2012-01-28 11:50:00 +0100|
Update time sync' design doc, again.
1 files changed, 20 insertions, 18 deletions
diff --git a/wiki/src/contribute/design/Time_syncing.mdwn b/wiki/src/contribute/design/Time_syncing.mdwn
index ece186b..915d6f3 100644
@@ -3,12 +3,12 @@
Tor (and I2P) sometimes freaks out if they detect too large clock
-skews. It is therefore important for us to ensure that Tails some how
-automatically syncs the system time at start in a safe manner.
+skews. It is therefore important for us to ensure that Tails somehow
+automatically synchronizes the system time at start in a safe manner.
-We are worried about unauthenticated [[NTP]]. There probably is a
+There probably is a
whole bunch of fingerprinting attacks an attacker could mount if it
-could pose as the NTP server and mess with the user's time. We
+could pose as the time server and mess with the user's time. We
therefore want to be able to *authenticate* the servers that provide
us with supposedly accurate time information. Home-made research
[[demonstrated|todo/authenticate_time_servers]] that NTPv4's server
@@ -23,19 +23,21 @@ using Tor so we can make Tor usable.
In short this is how time syncing is performed when Tails starts:
-0. Start Tor in order to fetch a consensus.
-0. If Tor cannot verify the consensus we assume it is because the time
- is so badly off that the authority certificate are not valid any
- more so we set the system time to the Tails release date, which
- will guarantee that the certificates are valid. Then we restart Tor
- to get a new consensus, verifiable or not.
+0. Start Tor. If Tor is already working, skip to HTP step.
+0. Let Tor fetch a consensus (wait 150 seconds twice, restarting Tor
+ in between).
+0. If the time is too badly off, the authority certificate may not be
+ valid any more, so we set the system time to the Tails release date, which
+ will guarantee that the certificates are valid. Then we SIGHUP Tor
+ and wait for a new consensus again.
0. Set the system time to an initial "guess" based on the Tor
consensus validity period, no matter if the consensus was verifiable
0. Restart Tor, which now should be working.
0. Run HTP (see below) through Tor to get a more correct system time.
-A notification is shown while HTP is running informing the user that
+A notification is shown while the whole process is running,
+informing the user that
Tor may not function properly before it has finished (e.g. hidden
services running Tor prior to version 0.2.3.7-alpha requires clients
to have a time that is no more than 30 minutes incorrect).
@@ -47,12 +49,13 @@ Tor's consensus file to initially roughly set the time. The consensus
file contains such information:
valid-after 2010-12-27 16:00:00
+ fresh-until 2010-12-27 17:00:00
valid-until 2010-12-27 19:00:00
A consensus is valid for three hours. If the system time is in the
[valid-after, valid-after + 2.5 hours] range, `tordate` exits.
Else, it sets the system time to the middle of the [valid-after,
-valid-until] range and restarts Tor.
+fresh-until] range and restarts Tor.
The system time is then ensured to be correct enough to enable Tor to
successfully open a circuit, and HTP can then be used to more
@@ -160,16 +163,15 @@ The pools are listed in `/etc/default/htpdate`.
# Fingerprinting Tails users
-Tails will run HTP through Tor, so the fingerprintability should be
+Tails runs HTP through Tor, so the fingerprintability should be
limited to traffic flow only. It should be noted that HTP only fetches
the HTTP header, so fingerprinting based on the known traffic pattern
-when fetching the full page of any of the memers in Tails' HTP source
-pool is not possible.
+when fetching the full page of any of the members of Tails' HTP source
+pools is not possible.
Our initial time guess based on the Tor consensus is probably easier
-to fingerprint, though: A fresh Tor is started, (and possibly
-restarted again after a minute if the consensus couldn't be verified)
-and then restarted again right after the consensus has been
+to fingerprint, though: a fresh Tor is started,
+and restarted again right after the consensus has been
Tails developers still need to think thoroughly of these questions: