{{toc}}

What’s described bellow was implemented in feature/tordate Git branch, merged into devel, released in Tails 0.9.

Introduction

We are now using in-the-clear HTP requests to set the system time before starting Tor:

• design document
• closed TODO

An alternative implementation could allow us to avoid doing such DNS and HTTPS requests in the clear by using time data retrieved from the Tor clients bootstrap phase somehow (see below for different approaches).

Pros

If we switch to such an operation mode we can:

1. Remove the htp user exceptions in the firewall (for the record, it is now allowed to do DNS and HTTPS requests in the clear). This would make Tails much closer from the advertised all outgoing connections to the Internet are forced to go through the Tor network. This also would make it harder to fingerprint Tails users for anyone sniffing the Internet connection in use; from the ExitNode and webservers used by HTP point-of-view, fingerprinting is still possible though.
2. Simplify our NetworkManager HTP hook script: no need to mess with /etc/hosts anymore, no need to do manual DNS resolution either.

Cons

The HTP full-page (stylesheets, images, etc.) requests would be far slower if going through Tor. If HTP is used in blocking mode (i.e. the user waits for HTP to finish and Vidalia to start before using the network) this would increase the boot time until the system is really usable (again). OTOH if HTP is used in non-blocking mode boot time would decrease so this actually might be a bonus point rather than a cons.

Integration

This mainly is a NetworkManager hooks ordering issue.

HTP is blocking

1. Start Tor.
2. Set the time, restart Tor if needed.
3. Notify the user the HTP time setting process has been started.
4. Use HTP to more accurately set the system time.
5. Start Vidalia.

HTP is not blocking

1. Start Tor.
2. Set the time, restart Tor if needed.
3. Start Vidalia.
4. In the background, use HTP to more accurately set the system time.

Do we need to notify the user in case the system time is changed by HTP? We would, if we need to restart Tor and Vidalia, but it seems we don’t need to do that since Tor allows small time changes and we know we already have a not-so-bad system time.

Time from Tor consensus

Liberte Linux uses Tor’s consensus file to initially roughly set the time thanks to their tordate script. The consensus file contains such information:

valid-after 2010-12-27 16: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.

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 accurately set time via Tor. The whole idea is that while Tor does not manage to open a circuit if the system time is too much wrong, it is supposed to always be able to retrieve its consensus file as soon as Internet connectivity is available.

See the liberte/src/usr/local/sbin/tordate file in Liberte Linux SVN repository for details.

Security discussion

This approach essentially removes the time skew check, which is used to prevent replay of consensus data. Let’s discuss this class of attacks.

First, replaying a consensus older than one week or so results in preventing access to the Tor network, and that’s all, because onion keys will be wrong. An attacker who is in a position to replay a consensus to you could anyway do this, unrelated to time, so the issue at hand boils down to replaying a consensus not older than one week or so.

Second, things are different depending on if you’re using a bridge or not.

If not using a bridge: Tails starts without a cached consensus, so its Tor client starts by connecting directly to a directory authority (and not to a directory mirror / entry guard), so feeding you an old consensus requires the attacker either to break SSL, or to control the directory authority your Tor client connects to. Not good, but probably a compromise we can make.

If using a bridge: your bridge can replay an old (one week old max.) consensus, which is used until HTP has fixed the time; not good, but probably a compromise we can make. If your bridge also can setup a SSL MitM attack against the HTP connections (e.g. the attacker also controls a SSL CA shipped by Debian), it can trick you into using this old consensus for max. one week, which is much worse.

As a conclusion, it seems this is would be a satisfying approach. Let’s do it!

Archive

NETINFO cell’s timestamp

See section 4.2 (NETINFO cells) of tor-spec.txt. NETINFO cells are exchanged between two parties wanting to establish a connection. Each NETINFO cell contains a timestamp (epoch time) that could be used to set a pretty accurate system time. Proposal 149 may also be of our interest.

This approach may also be vulnerable to consensus replay attacks unless we get NETINFO cells from several sources and compare them. Roger Dingledine suggests:

Also, ideally you want to get an opinion from more than one directory authority. One design that I could imagine would be to, if we find a directory mirror or entry guard whose time disagrees with us, connect to a directory authority to get a stronger opinion. If the directory authority also disagrees, connect to a threshold of directory authorities and then memorize our relative clock skew based on the majority vote.

Potential complications include "what threshold should you require" and "what if you can’t reach the directory authorities directly because you’re in a censored area". Maybe in the latter case you should just believe your bridge’s clock, because it’s the one giving you the directory information anyway — depends if the user wants her Tor to fail open (reachability) or fail closed (safety).

It remains to see how much changes are necessary in the Tor souces for this whole approach to be possible.