summaryrefslogtreecommitdiffstats
path: root/wiki/src/blueprint/robust_time_syncing.mdwn
blob: 5c4547e637194041405433d0b87125624cfb279c (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
This is about [[!tails_ticket 5774]].

[[!toc levels=2]]

Introduction
============

tordate
-------

With *tordate* we're referring to the unholy mess found in
[[!tails_gitweb
config/chroot_local-includes/etc/NetworkManager/dispatcher.d/20-time.sh]],
whose design can be read in [[contribute/design/Time_syncing]]
(overview, steps 1-3, more or less).

tordate is a fragile pile of hacks, and it effectively makes it
possible for attackers to replay any old Tor network consensus to
Tails users. Also, in at least our current understanding of things, it
prevents us from making `/var/lib/tor persistent`, so Tails users has no
long-term Tor Entry Guards. I'm not sure more reasons need to be
stated why we must get rid of it.

The problem
-----------

When Tails boots on a system where the clock is incorrect, Tor will
not be able to bootstrap. With "incorrect" we specifically mean when
the time is outside the current Tor network consensus'
(`/var/lib/tor/cached-microdesc-consensus`) validity lifetime (e.g.
the `valid-after` and `valid-until` fields). When Tor fails to
bootstrap, Tails is effectively useless for networking.

It should be noted that the clock just has to be off by a few hours
for Tor to become completely unable to bootstrap, and that's not very
uncommon. Certain OSes (including Windows up to Windows 8 at least)
set the BIOS clock to the local time, and since Tails uses UTC (and
assumes the BIOS clock is UTC), this becomes a problem for every user
but those living in the GMT+0/UTC timezone. Hence this is a very
serious problem.

What we want
------------

We want a mechanism to avoid the above problem. This mechanism must not
have a network fingerprint unique to Tails. Some people may think NTP,
which is widely used, but NTP is unauthenticated, so a MitM attack
would let an attacker set the system time, which later may be used to
fingerprint the Tails user for applications/protocols that leak the
system time. And while authenticated NTP exists ([[!tails_ticket
6113]]), it's barely in use, so it'd become a great way to identify
Tails users.

In fact, we'd prefer if the sought after "mechanism" is part of Tor's
normal bootstrap process, with no extra packets sent, so the network
fingerprint becomes indistinguishable from a "normal" Tor bootstrap.
That would be a very handy fact when reasoning about how Tails users
can be fingerprinted.

Some other requirements about this mechanism:

* it has to avoid the security issues that current tordate has wrt.
  replayed Tor consensus;
* it has to be more robust that the current tordate;
* it has to be as safe as the current tordate + htpdate combination,
  e.g. wrt. failing closed when facing a replayed consensus and the
  time set by htpdate is out of the `valid-before`/`valid-until`
  interval (admitedly, the corresponding UX is totally miserable as of
  Tails 1.4, but at least we're failing closed);
* it has to work with pluggable transports;
* it has to work when not doing a full bootstrap, e.g.
  when `/var/lib/tor` is persistent;
* Tor is a bit fragile when it comes to time jumps during
  early bootstrap stages. For instance, in @tordate@ we have to restart Tor
  after setting the time according to the fetched consensus, otherwise
  it just idles, at least sometimes. This will have to be solved too;
* it should help improve the UX we provide while Tor is boostrapping
  and the time is being sync'ed, both on success and on various kinds
  of failures.

Possible solutions
==================

Ask the user what time it is
----------------------------

... when Tor fails to bootstrap for time-related reasons.

That's what ChromeOS does when the time is too wrong:

* <https://code.google.com/p/chromium/issues/detail?id=232066#c105>
* <https://codereview.chromium.org/247663003/>
* Sadly, most of their design docs, UI mockups etc. are apparently not
  accessible to non-Google employees or something, so it's not easy to
  understand why they did what. Still, the resulting code is there:
  <https://src.chromium.org/viewvc/chrome?revision=266431&view=revision>

### User story

	When I start Tails
	And I log into the Tails desktop with the default options
	And Tor fails to bootstrap for time-related reasons
	Then I am asked for the correct time
	And at the same time the corresponding UI lets me choose my preferred timezone
	And then, Tails Clock displays the current time with the chosen timezone
	And Tor bootstrap is attempted again

### Roadmap

#### First iteration

Relevant tickets: [[!tails_ticket 10819]], [[!tails_ticket 6284]],
[[!tails_ticket 12094]].

* What's called *Tails Clock* below is the widget that will display
  the current time within the GNOME desktop, in whatever timezone the
  user prefers, which we call the *display timezone*. The system
  timezone remains UTC in all cases.
* From current tordate, we keep only the mechanism that detects if Tor
  fails to bootstrap due to time-related reasons. Whenever this
  happens, we open a GUI that lets the user set the correct time and
  choose their preferred timezone, and then we restart Tor.
  - GNOME Date and Time interface is good -- according to sajolida "We
    could maybe reuse most of that UI"; however, it "looks like
    a geolocation tool" so it "should come with a clear message that
    this is only to set the 'clock display timezone' and not collected
    in any way"
* We keep htpdate as-is for now, in order to keep failing closed on
  replayed Tor consensus.
* We need Tails Clock: otherwise, we would let the user set the
  correct time in their preferred timezone, but then the feedback we
  would give them (in the GNOME clock display) would let them think the
  operation has failed, since it would still display time in UTC.
  We have to avoid making the UX worse this way, hence the need for
  Tails Clock. The config source for the timezone used by Tails
  Clock must be shared with the time input GUI, to provide
  a consistent UX. The interface used by Tails Clock and by the
  upcoming time input GUI could perhaps be shared; this raises
  privilege separation issues that need to be thought through.
* We need a persistence option for the display timezone: otherwise, it
  will be a pain for Windows users. If the new Greeter is ready in
  time for this, perfect; otherwise, we'll have to implement it in
  a different way, e.g. by allowing users to persist their chosen
  timezone when they set it from Tails Clock or from the
  aforementioned GUI.

#### Second iteration

We stop using htpdate to *set* the system clock, but we keep it around
as a way to *detect* a replayed Tor consensus: if the time delta
detected by htpdate is too big:

* we warn the user that something fishy may be going on, and try to
  make as actionable as realistically possible;
* we stop Tor, in order to keep failing closed in this situation.

And then, perhaps htpdate could be configured to query fewer servers,
because we maybe don't need to trust the info we get from htpdate as
much once we're there.

#### Integration with the new Greeter

We need to give the user will have the opportunity to choose their
preferred timezone in the Greeter ([[!tails_ticket 11645]]). And then,
most likely we'll want to provide them feedback about what Tails
thinks the resulting local time is. And in turn, the UI that provides
that feedback can as well allow users to set the system time if
it's wrong ([[!tails_ticket 11641]]).

The chosen timezone information should be re-used both by Tails Clock
and by the time input GUI that lets users correct the system time if
Tor has failed to bootstrap for time-related reasons.

	When I start Tails
	And I choose my preferred timezone in the Greeter
	Then I see the resulting system time in the chosen timezone
	And I am enabled to correct the system time
	And then, Tails Clock displays the current time with the chosen timezone
	And Tor has greater chances to bootstrap successfully on first try

Extend Tor some how
-------------------

E.g.:

* like [Roger
  suggested](https://lists.torproject.org/pipermail/tor-talk/2011-January/008551.html)
* [[!tor_bug 3652 desc="Export clock skew opinion as getinfo command"]]
  and its [[!tor_bug 6894 desc="answer network time requests"]] duplicate

Misc. resources
===============

* [tlsdate](https://github.com/ioerror/tlsdate)
  - Part of Debian Jessie.
  - Used by ChromeOS on every network up event => no longer easy to
    fingerprint due to low usage _iff_ we use it exactly in the same
    way (e.g. ask the very same HTTPS servers) as ChromeOS, and go on
    doing so forever.
    * their (outdated) [design
      doc](https://docs.google.com/a/chromium.org/document/d/1ylaCHabUIHoKRJQWhBxqQ5Vck270fX7XCWBdiJofHbU/edit)
    * their [tlsdate
      clone](http://git.chromium.org/gitweb/?p=chromiumos/third_party/tlsdate.git;a=summary)
    * their [upstart job](http://git.chromium.org/gitweb/?p=chromiumos/platform/init.git;a=blob;f=tlsdated.conf;h=d72d780c1f1d432bb7b7a06e787a745dbf5cdd46;hb=HEAD)
    * They query `clients3.google.com` only currently, but intend to
      use the multi-host feature some day.